AI Agent Threat Model

AI agents introduce a distinct security surface compared to traditional web applications. Unlike a deterministic API endpoint, an agent autonomously decides which tools to call, which files to read, and which commands to execute β€” based on LLM reasoning that can be manipulated via malicious input. The primary threats to OpenClaw deployments are:

ThreatDescriptionMitigation
Prompt InjectionMalicious text in external data (web pages, files, emails) tricks the agent into executing unintended commandsInput sanitization, output validation, sandbox mode
API Key LeakageLLM API keys exposed in logs, code, or environment dumpsSecrets manager, env-var only storage, key rotation
Privilege EscalationAgent with file-write permission is manipulated into modifying system filesGranular tool permissions, allowlist-only commands
Unintended Data ExfiltrationAgent sends sensitive internal data to external endpoints during normal task executionNetwork allowlisting, sandbox network restrictions
Runaway ExecutionInfinite agent loops consuming excessive tokens and incurring large billing chargesMax-steps limit, token budget, timeout configuration

OWASP LLM Top 10 Alignment

The OWASP Top 10 for LLM Applications identifies the most critical vulnerabilities in AI systems. OpenClaw’s security architecture directly addresses the top risks:

OWASP LLM RiskOpenClaw Control
LLM01: Prompt InjectionSandbox mode, input validation hooks, security.prompt_guard: strict config
LLM02: Insecure Output HandlingOutput schema validation, ToolResult type enforcement
LLM06: Sensitive Information DisclosureSecrets manager integration, PII scrubbing in audit logs
LLM08: Excessive AgencyGranular permission model, tool allowlisting, human-in-the-loop approvals
LLM09: OverrelianceAgent confidence scoring, mandatory human review for high-stakes actions

For a detailed implementation walkthrough, see the Security Overview page.

Sections

Security Checklist

ItemPriorityGuide
Store API keys as environment variables, never in codeπŸ”΄ CriticalAPI Keys
Enable sandbox mode for untrusted inputsπŸ”΄ CriticalSandboxing
Scope tool permissions to minimum required🟠 HighPermissions
Enable audit logging for all agent actions🟠 HighAudit Logs
Use a secrets manager for multi-agent deployments🟑 MediumSecrets
Rotate API keys quarterly🟑 MediumAPI Keys

Enabling Sandbox Mode

Sandbox mode restricts what the agent can do. Enable it in openclaw.yaml:

security:
  sandbox:
    enabled: true
    filesystem:
      read_paths: ["/app/data"]      # only these paths are readable
      write_paths: ["/app/output"]   # only these paths are writable
      deny_paths: ["/etc", "/root", "/sys"]  # explicitly denied
    network:
      allowed_hosts:                  # agent can only contact these
        - "api.openai.com"
        - "api.anthropic.com"
      deny_all_by_default: true
    commands:
      allowed: ["python3", "git", "curl"]
      deny_shell: true               # prevent shell injection
    resources:
      max_memory_mb: 512
      max_cpu_percent: 50
      max_execution_seconds: 120

Prompt Injection Defence

Prompt injection is the AI agent equivalent of SQL injection: malicious content in external sources (web pages, uploaded files, user inputs) tricks the agent into ignoring its system prompt and executing unintended commands. Mitigate it with these layers:

  • Enable security.prompt_guard: strict β€” OpenClaw scans tool outputs for known injection patterns before injecting them into the agent's context.
  • Separate instruction and data contexts β€” Use explicit delimiters in your system prompt: --- UNTRUSTED CONTENT BELOW ---. Tell the agent to never execute instructions found below this delimiter.
  • Validate tool outputs against a schema β€” If a web_search result should be a list of strings, reject results that contain function call syntax or instruction-like text.
  • Implement human-in-the-loop for high-stakes actions β€” Before the agent deletes files, sends emails, or executes code, require a human approval step via the HITL callback.
# openclaw.yaml β€” prompt injection defences
security:
  prompt_guard:
    enabled: true
    mode: strict          # permissive | moderate | strict
    block_on_detection: true
    log_detections: true
  hitl:
    enabled: true
    require_approval_for:
      - "write_file"
      - "run_bash"
      - "send_email"
      - "sql_query"

Audit Log Configuration

Audit logs capture every agent action β€” every tool call, every LLM request, every memory read/write β€” with a tamper-resistant hash chain. This is essential for compliance (SOC 2, GDPR) and incident investigation.

# openclaw.yaml
security:
  audit:
    enabled: true
    destination: file          # file | stdout | syslog | s3 | splunk
    file_path: /var/log/openclaw/audit.jsonl
    include_llm_output: false  # set false to avoid logging sensitive LLM content
    pii_scrubbing: true        # redacts common PII patterns (email, phone, SSN)
    hash_chain: true           # each entry includes hash of previous entry
    retention_days: 365        # auto-delete logs older than N days

Secrets Manager Integration

For production deployments, never store secrets in environment files. Integrate with a dedicated secrets manager:

# openclaw.yaml β€” HashiCorp Vault integration
secrets:
  provider: vault
  vault:
    address: https://vault.internal:8200
    auth_method: approle
    role_id_env: VAULT_ROLE_ID
    secret_id_env: VAULT_SECRET_ID
    mount_path: secret
    paths:
      openai_key: secret/data/openclaw/openai_api_key
      db_password: secret/data/openclaw/db_password

Reporting Security Vulnerabilities

If you discover a security vulnerability in OpenClaw, please report it responsibly. Do not file a public GitHub issue. Instead:

  1. Email security@openclaw.ai with a description of the vulnerability and steps to reproduce.
  2. Include your assessment of severity (CVSS score if possible) and potential impact.
  3. Our security team will acknowledge within 48 hours and provide a fix timeline.
  4. We credit all valid security reports in our security advisories and changelog.

We follow responsible disclosure: we request a 90-day window to patch the issue before public disclosure.