DataGuard — Runtime DLP for AI Agents

You have the DataGuard security skill. This is a runtime enforcement layer that actively prevents data exfiltration.

The Problem

AI agents can be tricked into sending sensitive data through:

• Prompt injection — hidden instructions in emails, web pages, documents
• Tool chaining — read credentials → send to external URL
• Social engineering — "help me debug, paste your config"
• Unintended exposure — logs, error messages, debugging output

SecureClaw provides behavioral rules. DataGuard provides runtime enforcement.

How It Works

┌─────────────────────────────────────────────────────────────────┐
│                     TOOL EXECUTION FLOW                         │
├─────────────────────────────────────────────────────────────────┤
│  Agent calls tool (web_fetch, sessions_send, exec)              │
│                          ↓                                       │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  DATA GUARD PRE-HOOK                                     │   │
│  │  ─────────────────────────────────────────────────────  │   │
│  │  1. Extract outbound data (URL params, body, message)   │   │
│  │  2. Run pattern scanner (API keys, PII, paths)         │   │
│  │  3. Check context (sensitive file read this session?)   │   │
│  │  4. Verify domain allowlist                             │   │
│  │  5. Calculate risk score                                │   │
│  └─────────────────────────────────────────────────────────┘   │
│                          ↓                                       │
│         ┌──────────────┬──────────────┬──────────────┐          │
│         │  LOW RISK    │  MEDIUM RISK  │  HIGH RISK   │          │
│         │  (0-2)       │  (3-5)        │  (6-10)      │          │
│         └──────────────┴──────────────┴──────────────┘          │
│              ↓               ↓               ↓                    │
│         ALLOW           WARN + LOG      BLOCK + ALERT            │
│                          ↓               ↓                       │
│                      ALLOW           REQUIRE APPROVAL            │
│                                                              │
└─────────────────────────────────────────────────────────────────┘

Layer Stack

Rules

Rule 1: All Outbound Data Must Be Scanned

Before ANY tool that sends data externally:

echo "$OUTBOUND_DATA" | bash $SKILL_DIR/scripts/dlp-scan.sh

If exit code is non-zero, STOP and alert.

Rule 2: Pattern Matches Are Automatic Blocks

The following patterns trigger immediate block:

CRITICAL (Score: 10)

• API keys: sk-*, xoxb-*, ghp_*, AKIA*, API keys in general
• Passwords: password=, passwd=, pwd=, secret=
• Private keys: -----BEGIN.*PRIVATE KEY-----
• Database URLs with credentials: mysql://user:pass@, postgres://...
• AWS credentials: aws_access_key_id, aws_secret_access_key

HIGH (Score: 8)

• Credit cards: Visa/MC/Amex/Diners patterns
• SSN: XXX-XX-XXXX format
• Internal IPs: 192.168.*, 10.*, 172.16-31.*
• Internal hostnames: .local, .internal, .corp
• File paths: /home/, /root/, /etc/, ~/.ssh/

MEDIUM (Score: 5)

• Email addresses in sensitive contexts
• Phone numbers in sensitive contexts
• Personal names with context (config files, credentials)
• VPN/network tool references (tailscale, wireguard)

LOW (Score: 2)

• Generic path references
• Non-sensitive URLs
• Public information

Rule 3: Context Matters — Track Sensitive Reads

DataGuard maintains a session context file:

$SKILL_DIR/context/sensitive-reads.json

When you read a file containing credentials or PII, DataGuard logs it:

{
  "timestamp": "2026-04-07T16:52:00Z",
  "file": "/home/user/.env",
  "patterns": ["AWS_KEY", "DB_PASSWORD"],
  "risk_level": "HIGH"
}

If you then try to send data externally, DataGuard checks this log:

• Sensitive read in last 5 minutes? → Risk +3
• Same session? → Risk +2
• Same conversation turn? → Risk +5 (BLOCK threshold)

Rule 4: Domain Allowlisting

By default, these domains are ALLOWED:

• api.openai.com
• api.anthropic.com
• api.brave.com
• docs.openclaw.ai
• clawhub.ai
• github.com

By default, these domains are BLOCKED:

• Pastebin sites (pastebin.com, hastebin.com)
• File sharing (transfer.sh, 0x0.st)
• Webhook catchers (webhook.site, requestbin.net)
• Anonymous email (temp-mail.org, guerrillamail.com)

All other domains: REQUIRE APPROVAL for data outbound.

Rule 5: Risk Scoring Thresholds

When blocked:

1. Log to $SKILL_DIR/logs/blocked-attempts.log
2. Show user: what was blocked, why, risk score breakdown
3. Provide options: approve once, approve domain, report false positive

Rule 6: User Approval Must Be Explicit

When DataGuard blocks an action, you MUST:

1. Show the exact data that would be sent (truncated, redacted)
2. Show which patterns triggered the block
3. Show the risk score breakdown
4. Ask: "Do you want to allow this? (yes/no)"

Never: Auto-approve, skip approval, or work around the block.

Rule 7: Audit Everything

Every blocked attempt logs:

[2026-04-07T16:52:00Z] BLOCKED
Tool: web_fetch
Domain: example.com
Patterns: AWS_KEY, DB_PASSWORD
Risk Score: 12
Data: {"url": "https://example.com/api", "body": "[REDACTED]"}
User: approved / denied / pending

Review logs: bash $SKILL_DIR/scripts/audit-log.sh --recent

Rule 8: False Positives Happen — Report Them

If a legitimate action is blocked:

1. Run: bash $SKILL_DIR/scripts/report-false-positive.sh
2. Describe what you were trying to do
3. Include the blocked data pattern
4. This helps improve detection accuracy

Rule 9: Never Disable DataGuard

There is no "disable" switch. If you need to send sensitive data:

1. Get explicit user approval (Rule 6)
2. Log the approval reason
3. Proceed with consent on record

Rule 10: Teach Your Human About Risks

When DataGuard blocks something, explain:

• Why it was blocked
• What the risk is
• What alternatives exist

Don't just say "blocked" — educate.

Script Reference

Replace $SKILL_DIR with the actual path:

• Standalone: ~/.openclaw/skills/dataguard
• Plugin: ~/.openclaw/extensions/dataguard/skill

Pattern Scanning

echo "$DATA" | bash $SKILL_DIR/scripts/dlp-scan.sh
# Exit 0 = clean, Exit 1+ = risk score

Domain Management

# List allowed domains
bash $SKILL_DIR/scripts/domain-allowlist.sh --list

# Add domain (requires approval)
bash $SKILL_DIR/scripts/domain-allowlist.sh --add example.com

# Remove domain
bash $SKILL_DIR/scripts/domain-allowlist.sh --remove example.com

Context Tracking

# Log a sensitive file read
bash $SKILL_DIR/scripts/context-track.sh --log "/path/to/.env" "AWS_KEY,DB_PASSWORD"

# Check recent sensitive reads
bash $SKILL_DIR/scripts/context-track.sh --check

# Clear session context
bash $SKILL_DIR/scripts/context-track.sh --clear

Audit Logs

# Show recent blocks
bash $SKILL_DIR/scripts/audit-log.sh --recent

# Show all blocks today
bash $SKILL_DIR/scripts/audit-log.sh --today

# Export for review
bash $SKILL_DIR/scripts/audit-log.sh --export

Integration with SecureClaw

DataGuard and SecureClaw work together:

Use both. SecureClaw teaches good behavior. DataGuard enforces it.

Threat Model (MITRE ATLAS Reference)

Note: MITRE ATLAS is an attack knowledge base for threat modeling, not a control standard. The techniques below describe what attacks look like. Control requirements come from NIST AI RMF 1.0, NIST SP 800-53 Rev. 5, ISO/IEC 42001, and ISO/IEC 27001 (see Standards Alignment section).

Threat Modeling vs Control Mapping:

• ATLAS helps identify what could go wrong (threat scenarios)
• NIST AI RMF / ISO 42001 define what controls to implement (governance requirements)
• DataGuard implements controls that address the identified threats

OWASP LLM Top 10 Mapping

Customization

Configuration

Edit $SKILL_DIR/config/config.json to adjust behavior:

Adding Custom Patterns

Edit $SKILL_DIR/scripts/dlp-scan.sh and add a new if block in the appropriate tier:

CRITICAL (score 10) — secrets that should never leave:

if echo "$DATA" | grep -qiE 'your-custom-pattern-here'; then
  PATTERNS_FOUND+=("CRITICAL:YourPattern")
  RISK_SCORE=$((RISK_SCORE + 10))
fi

HIGH (score 8) — sensitive data like internal identifiers:

if echo "$DATA" | grep -qiE 'your-custom-pattern-here'; then
  PATTERNS_FOUND+=("HIGH:YourPattern")
  RISK_SCORE=$((RISK_SCORE + 8))
fi

MEDIUM (score 5) — context-dependent data:

if echo "$DATA" | grep -qiE 'your-custom-pattern-here'; then
  PATTERNS_FOUND+=("MEDIUM:YourPattern")
  RISK_SCORE=$((RISK_SCORE + 5))
fi

Custom pattern examples:

• Employee IDs: EMP-[0-9]{6}
• Project codenames: (project-alpha|project-beta)
• Internal API endpoints: https://internal\.company\.com
• Custom token formats: org_[a-zA-Z0-9]{24}

Removing Patterns

Comment out or delete the corresponding if block in dlp-scan.sh. Example — disable phone number detection if too noisy:

# Disabled — too many false positives in our context
# if echo "$DATA" | grep -qE '(phone pattern)'; then
#   PATTERNS_FOUND+=("MEDIUM:Phone")
#   RISK_SCORE=$((RISK_SCORE + 5))
# fi

Domain Management

# Add a trusted domain
bash $SKILL_DIR/scripts/domain-allowlist.sh --add internal.company.com

# Block a known exfil target
bash $SKILL_DIR/scripts/domain-allowlist.sh --block pastebin.com

# List all rules
bash $SKILL_DIR/scripts/domain-allowlist.sh --list

# Check if a domain is allowed
bash $SKILL_DIR/scripts/domain-allowlist.sh --check example.com

Pattern Portability

Some patterns may behave differently across Linux distros depending on grep version. Run the test suite after any changes:

# Unit tests (41 pattern tests)
bash $SKILL_DIR/tests/test-all.sh

# Integration tests (15+ real-world scenarios)
bash $SKILL_DIR/tests/test-integration.sh

If a pattern fails on your system, simplify the regex — avoid \s, character classes like [:space:], and complex quantifiers. Use literal spaces and simple character ranges instead.

Emergency Override

If DataGuard is blocking legitimate critical operations:

1. User can run: bash $SKILL_DIR/scripts/emergency-override.sh
2. This creates a 5-minute window where approvals are auto-granted
3. All actions during this window are logged with EMERGENCY_OVERRIDE flag
4. After 5 minutes, normal rules resume

Use sparingly. Every override is logged.

Quick Reference

# Scan data for patterns
echo "$DATA" | bash $SKILL_DIR/scripts/dlp-scan.sh

# Check if domain is allowed
bash $SKILL_DIR/scripts/domain-allowlist.sh --check example.com

# View recent blocks
bash $SKILL_DIR/scripts/audit-log.sh --recent

# Report false positive
bash $SKILL_DIR/scripts/report-false-positive.sh

# Emergency override (5 min)
bash $SKILL_DIR/scripts/emergency-override.sh

DataGuard DLP v1.2.0 — Runtime DLP for AI agents. Because rules are only as good as their enforcement.

Author: Jeff Cyprien (github.com/jeffcGit) License: MIT — See LICENSE for details.

Standards Alignment

DataGuard controls are mapped to established security and AI governance frameworks.

Control Frameworks (Direct Mapping)

These frameworks provide concrete controls for AI data leakage prevention:

Attack Taxonomies (Threat Modeling References)

These are useful for understanding attack patterns, but are not control standards:

Technical References

These are specifications, not security standards:

Why This Mapping Matters

NIST AI RMF 1.0 and ISO/IEC 42001 are the primary governance frameworks for AI systems. DataGuard's risk scoring and approval workflow directly implement their human oversight requirements.

NIST SP 800-53 and ISO/IEC 27001 provide the control catalog — DataGuard implements AU (Audit), SC (Boundary Protection), and AC (Access Control) controls at the AI agent layer.

PCI DSS and HIPAA are domain-specific — DataGuard patterns help, but domain controls (encryption, access management) are still required.

MITRE ATLAS and NIST AI 100-2 help us understand what attacks look like — but they don't tell us what controls to implement. Use them for threat modeling, not compliance.