OCSAS - OpenClaw Security Assurance Standard

OSSASAI implementation profile for the OpenClaw AI agent gateway

Profile Overview

Profile ID: OSSASAI-PROFILE-OPENCLAW-OCSAS-0.1

OCSAS (OpenClaw Security Assurance Standard) is the official OSSASAI implementation profile for OpenClaw — a WhatsApp, Telegram, Discord, iMessage, and Slack gateway for AI agents with shell, filesystem, and browser access.

This profile maps OSSASAI controls to OpenClaw’s existing security architecture, CLI tooling, and formal verification suite. OCSAS complements OpenClaw’s built-in security by providing a structured verification framework.

OpenClaw Security Philosophy: “Access control before intelligence.” Most failures are not fancy exploits—they’re “someone messaged the bot and the bot did what they asked.” OpenClaw’s stance: Identity first, scope next, model last.

How This Framework Works

Important: OpenClaw is not maintained by us. OCSAS is an external compliance framework that documents OpenClaw’s existing security features — it does not require any changes to OpenClaw itself.

The Relationship

┌─────────────────────────────────────────────────────────────────────┐
│                      OpenClaw (Third-Party Product)                  │
│                                                                      │
│  Already has: openclaw security audit, dmPolicy, sandbox,           │
│               gateway.auth, and all security features we document    │
│                                                                      │
│  Does NOT know about OCSAS/OSSASAI — and doesn't need to            │
└─────────────────────────────────────────────────────────────────────┘
                              ▲
                              │ We observe & document
                              │
┌─────────────────────────────────────────────────────────────────────┐
│                    OCSAS (This Profile)                              │
│                                                                      │
│  • Maps OpenClaw's existing features to OSSASAI security controls   │
│  • Provides compliance checklists for auditors                       │
│  • Gives users structured deployment guidance                        │
│  • Uses OpenClaw's own CLI for verification                          │
└─────────────────────────────────────────────────────────────────────┘

Analogy: Industry Standards

Standard	Target Software	Does Software Know About It?
CIS Ubuntu Benchmark	Ubuntu Linux	No - CIS documents existing settings
OWASP ASVS	Any web app	No - ASVS verifies existing features
PCI-DSS	Payment systems	No - auditors check existing configs
OCSAS	OpenClaw	No - we document existing features

What OCSAS Does

Function	Description
Documentation	Maps OpenClaw features to OSSASAI security controls
Verification	Uses OpenClaw’s own CLI (`openclaw security audit`)
Compliance	Provides structured output for auditors
Guidance	L1/L2/L3 conformance recipes with exact config

Who Uses OCSAS?

User	How They Use OCSAS
OpenClaw users	Deployment checklists, hardening guides
Security auditors	Compliance verification framework
Enterprises	Risk assessment, vendor due diligence
Regulators	Structured security evaluation criteria

Verification Flow

OSSASAI Control: "OSSASAI-ID-01: Peer Verification"
       ↓
OCSAS Mapping: "OpenClaw implements this via dmPolicy: 'pairing'"
       ↓
Verification: "Run 'openclaw security audit' to check"
       ↓
Auditor: "Control ID-01 ✓ - Compliant"

OpenClaw Security Architecture

OpenClaw implements a defense-in-depth security model with the following layers:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     OpenClaw Security Architecture                           │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  1. INBOUND GATING          2. SESSION ISOLATION      3. TOOL GOVERNANCE    │
│  ──────────────────         ──────────────────────    ────────────────────  │
│  • DM Policy                • dmScope isolation       • Tool allow/deny     │
│    (pairing/allowlist)      • Per-channel-peer       • Elevated exec gates  │
│  • Group allowlists         • Identity links          • Approval workflows  │
│  • Mention gating                                                           │
│                                                                              │
│  4. SANDBOXING              5. LOCAL STATE            6. NETWORK EXPOSURE   │
│  ────────────────           ─────────────────         ───────────────────   │
│  • Docker isolation         • File permissions        • Loopback binding    │
│  • Workspace access         • Log redaction           • Gateway auth        │
│  • Scope (session/agent)    • Credential storage      • Trusted proxies     │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

Quick Security Check

OpenClaw provides built-in OSSASAI-compatible security auditing:

# Health check
openclaw health

# Basic security audit
openclaw security audit

# Deep audit (includes live Gateway probe)
openclaw security audit --deep

# Auto-fix common issues
openclaw security audit --fix

# Full diagnostic report (secrets redacted)
openclaw status --all

# Gateway status (if installed as service)
openclaw gateway status

# Configuration issues
openclaw doctor
openclaw doctor --fix

What the audit checks:

Inbound access (DM policies, group policies, allowlists)
Tool blast radius (elevated tools + open rooms)
Network exposure (Gateway bind/auth, Tailscale Serve/Funnel)
Browser control exposure (remote nodes, relay ports, remote CDP endpoints)
Local disk hygiene (permissions, symlinks, config includes, synced folders)
Plugin allowlists (extensions exist without explicit allowlist)
Model hygiene (warns on legacy models with tools enabled)
Control UI security settings (allowInsecureAuth, dangerouslyDisableDeviceAuth)

What --fix applies:

Tightens groupPolicy="open" to groupPolicy="allowlist"
Turns logging.redactSensitive="off" back to "tools"
Tightens local permissions (~/.openclaw → 700, config → 600)

Control Mapping

B2 — Control Plane Controls

OSSASAI-CP-01: Default-Deny Control Plane Exposure

OpenClaw Implementation:

Gateway defaults to loopback binding (bind: "loopback")
Non-loopback binds (lan, tailnet, custom) explicitly expand attack surface
Audit warns on public exposure without auth

Configuration (~/.openclaw/openclaw.json):

{
  gateway: {
    mode: "local",
    bind: "loopback",      // Default - only local clients
    port: 18789
  }
}

Verification:

openclaw security audit --deep
# Check: "Gateway exposure" section should show loopback-only

Web Search Configuration:

# Configure Brave Search API for web search tool
openclaw configure --section web
# Stores in tools.web.search.apiKey

Evidence:

openclaw security audit --deep output
netstat -an | grep 18789 showing 127.0.0.1 binding

OpenClaw Docs: Security - Network Exposure

OSSASAI-CP-02: Strong Administrative Authentication

OpenClaw Implementation:

Gateway auth is required by default (fail-closed)
Supports token-based and password-based authentication
Onboarding wizard auto-generates token
Tailscale Serve identity headers supported (allowTailscale)

Configuration:

{
  gateway: {
    auth: {
      mode: "token",
      token: "your-long-random-token"
      // Or: mode: "password", password via OPENCLAW_GATEWAY_PASSWORD env
    }
  }
}

Token Management:

# Generate gateway token
openclaw doctor --generate-gateway-token

# Rotation: update token in config, restart Gateway, update remote clients

Verification:

openclaw security audit --deep
# Check Gateway auth status in output

Control UI Security:

{
  gateway: {
    controlUi: {
      // Allows token-only auth when device identity is omitted (security downgrade)
      allowInsecureAuth: false,    // Keep false unless debugging
      // Break-glass only: disables device identity checks entirely
      dangerouslyDisableDeviceAuth: false  // Keep false
    }
  }
}

OpenClaw Docs: Security - Gateway WebSocket Auth

OSSASAI-CP-03: Proxy Trust Boundary Configuration

OpenClaw Implementation:

gateway.trustedProxies controls which IPs can set forwarded headers
Prevents X-Forwarded-For spoofing from untrusted sources
Connections from non-trusted proxies with forwarded headers are rejected if auth is disabled

Configuration:

{
  gateway: {
    trustedProxies: [
      "127.0.0.1"          // If proxy runs on localhost
    ],
    auth: {
      mode: "password",
      password: "${OPENCLAW_GATEWAY_PASSWORD}"
    }
  }
}

Verification:

openclaw security audit
# Warnings appear if trustedProxies is misconfigured

OpenClaw Docs: Security - Reverse Proxy Configuration

OSSASAI-CP-04: Operator/Agent Identity Separation

OpenClaw Implementation:

Separate credential stores: credentials/, agents/<id>/agent/auth-profiles.json
DM allowlist controls who can trigger the bot
Group allowlist + mention gating control scope
commands.useAccessGroups gates slash command authorization

Configuration:

{
  commands: {
    useAccessGroups: true   // Only authorized senders can use directives
  },
  channels: {
    whatsapp: {
      allowFrom: ["+15555550123"]  // Only this number can DM
    }
  }
}

Evidence:

Distinct credential paths on disk
openclaw security audit identity checks

Command Authorization Model:

Slash commands and directives are only honored for authorized senders
Authorization derived from channel allowlists/pairing + commands.useAccessGroups
/exec is session-only convenience for authorized operators; does not write config

OpenClaw Docs: Security - Command Authorization

B1 — Inbound Identity Controls

OSSASAI-ID-01: Peer Verification for New Contacts

OpenClaw Implementation:

DM policy controls who can message the bot: pairing, allowlist, open, disabled
Pairing (default): Unknown senders receive a code; bot ignores until approved
Codes expire after 1 hour; pending requests capped at 3 per channel
Approvals stored in ~/.openclaw/credentials/<channel>-allowFrom.json

Configuration:

{
  channels: {
    whatsapp: {
      dmPolicy: "pairing"    // Default - require approval for new contacts
      // Or: "allowlist" - block unknowns, "open" - allow anyone (dangerous)
    }
  }
}

Pairing Management:

# List pending pairing requests
openclaw pairing list whatsapp

# Approve a request
openclaw pairing approve whatsapp <code>

# Deny a request
openclaw pairing deny whatsapp <code>

Verification:

openclaw security audit
# Warns if dmPolicy="open" without explicit "*" in allowlist

OpenClaw Docs: Security - DM Access Model

OSSASAI-ID-02: Session Isolation by Default

OpenClaw Implementation:

session.dmScope controls DM session routing
Default routes all DMs to main session (single-user mode)
Multi-user mode requires explicit isolation setting

Configuration:

{
  session: {
    dmScope: "per-channel-peer"     // Isolate by channel + peer
    // Or: "per-account-channel-peer" for multi-account channels
  }
}

Options:

dmScope	Description
(default)	All DMs route to main session
`per-channel-peer`	Isolate by channel and peer
`per-account-channel-peer`	Isolate by account, channel, and peer (strictest)

Verification:

openclaw security audit
# Warns when multiple DM senders share main session without isolation

Evidence:

Configuration snapshot
openclaw security audit session isolation check

OpenClaw Docs: Security - DM Session Isolation

OSSASAI-ID-03: Group/Channel Policy Hardening

OpenClaw Implementation:

Group allowlists control which groups the bot responds in
requireMention: true enables mention gating (only respond when @mentioned)
Per-group tool restrictions via groupPolicy and groupAllowFrom

Configuration:

{
  channels: {
    whatsapp: {
      groups: {
        "*": { requireMention: true }  // Require @mention in all groups
      }
    }
  },
  agents: {
    list: [{
      id: "main",
      groupChat: {
        mentionPatterns: ["@openclaw", "@mybot"]
      }
    }]
  }
}

Verification:

openclaw security audit
# Warns on groupPolicy="open" or missing mention gating

OpenClaw Docs: Security - Allowlists

B3 — Tool Governance Controls

OSSASAI-TB-01: Least Privilege Tool Configuration

OpenClaw Implementation:

Tool allow/deny lists restrict available capabilities
Per-agent tool configuration via agents.list[].tools
Sandbox workspace access controls (none, ro, rw)

Configuration:

{
  agents: {
    list: [{
      id: "family",
      tools: {
        allow: ["read"],
        deny: ["write", "edit", "apply_patch", "exec", "process", "browser"]
      }
    }]
  }
}

Verification:

openclaw sandbox explain
# Shows effective sandbox mode, tool policy, and config keys

Evidence:

Tool policy in config
openclaw security audit tool blast radius check

OpenClaw Docs: Multi-Agent Sandbox & Tools

OSSASAI-TB-02: Approval Gates for High-Risk Actions

OpenClaw Implementation:

tools.elevated provides explicit escape hatch for host exec
tools.elevated.allowFrom restricts who can use elevated mode
Node execution requires pairing + approval + allowlist
macOS nodes have Settings → Exec approvals (security/ask/allowlist)

Configuration:

{
  tools: {
    elevated: {
      enabled: true,
      allowFrom: {
        whatsapp: ["+15555550123"],  // Per-provider allowlists
        discord: ["user-id-here"]
      }
    }
  }
}

Node Execution Control (system.run): If a macOS node is paired, the Gateway can invoke system.run on that node (remote code execution):

Requires node pairing (approval + token)
Controlled on Mac via Settings → Exec approvals (security/ask/allowlist)
To disable: set security to “deny” and remove node pairing

{
  gateway: {
    nodes: {
      browser: {
        mode: "off"  // Disable browser proxy routing when not needed
      }
    }
  }
}

Dynamic Skills Security: OpenClaw can refresh the skills list mid-session:

Skills watcher: changes to SKILL.md can update skills on next agent turn
Remote nodes: connecting a macOS node can make macOS-only skills eligible

Mitigation: Treat skill folders as trusted code and restrict who can modify them.

Verification:

openclaw security audit
# Checks elevated allowlists and tool blast radius

OpenClaw Docs: Elevated Mode

OSSASAI-TB-03: Sandboxing for Untrusted Contexts

OpenClaw Implementation:

Docker-based tool sandboxing (optional, recommended)
Modes: off, non-main (default for safe chat), all
Scopes: session (per-session container), agent, shared
Workspace access: none (default), ro, rw

Configuration:

{
  agents: {
    defaults: {
      sandbox: {
        mode: "non-main",           // Sandbox non-main sessions
        scope: "session",           // One container per session
        workspaceAccess: "none"     // No agent workspace access
      }
    }
  }
}

Setup:

# Build sandbox image
scripts/sandbox-setup.sh

# Optional: sandboxed browser
scripts/sandbox-browser-setup.sh

Verification:

openclaw sandbox explain
# Shows effective sandbox configuration

OpenClaw Docs: Sandboxing

OSSASAI-TB-04: Outbound Data Exfiltration Controls

OpenClaw Implementation:

Sandbox containers run with no network by default
agents.defaults.sandbox.docker.network controls egress
Tool policy deny lists block network tools
Browser control can be restricted via profile isolation

Configuration:

{
  agents: {
    defaults: {
      sandbox: {
        docker: {
          network: "none"    // No network access (default)
        }
      }
    },
    list: [{
      id: "restricted",
      tools: {
        deny: ["web_search", "web_fetch", "browser"]
      }
    }]
  }
}

Browser Control Risks:

Browser profiles may contain logged-in sessions; model can access those accounts
Use a dedicated profile for the agent (default: openclaw profile)
Avoid pointing the agent at your personal daily-driver profile
Keep host browser control disabled for sandboxed agents
Treat browser downloads as untrusted input
Disable browser sync/password managers in agent profile
Chrome extension relay mode can take over existing Chrome tabs

Verification:

openclaw security audit
# Checks tool blast radius for data exfiltration risk

OpenClaw Docs: Sandboxing - Network

B4 — Local State Controls

OSSASAI-LS-01: Secrets Protected at Rest

OpenClaw Implementation:

~/.openclaw directory contains all secrets
openclaw security audit --fix tightens permissions automatically
Credentials stored in credentials/, agents/<id>/agent/auth-profiles.json

Required Permissions:

# Auto-fix permissions
openclaw security audit --fix

# Manual verification
ls -la ~/.openclaw/
# Should show:
# drwx------ (700) ~/.openclaw/
# -rw------- (600) ~/.openclaw/openclaw.json
# -rw------- (600) ~/.openclaw/credentials/*.json

Credential Storage Map:

Path	Contains
`~/.openclaw/openclaw.json`	Config with tokens (gateway, remote)
`~/.openclaw/credentials/whatsapp/<accountId>/creds.json`	WhatsApp credentials
`~/.openclaw/credentials/<channel>-allowFrom.json`	Pairing allowlists
`~/.openclaw/credentials/oauth.json`	Legacy OAuth import
`~/.openclaw/agents/<id>/agent/auth-profiles.json`	API keys, OAuth tokens
`~/.openclaw/agents/<id>/sessions/*.jsonl`	Session transcripts
`~/.openclaw/extensions/**`	Installed plugins + node_modules
`~/.openclaw/sandboxes/**`	Tool sandbox workspaces

Channel Token Locations:

Channel	Location
WhatsApp	`~/.openclaw/credentials/whatsapp/<accountId>/creds.json`
Telegram	Config/env or `channels.telegram.tokenFile`
Discord	Config/env (token file not yet supported)
Slack	Config/env (`channels.slack.*`)

OpenClaw Docs: Security - Secrets on Disk

OSSASAI-LS-02: Sensitive Log Redaction

OpenClaw Implementation:

logging.redactSensitive controls redaction level
Default: "tools" (redact tool summaries)
Custom patterns via logging.redactPatterns
--fix restores redaction if disabled

Configuration:

{
  logging: {
    level: "info",
    redactSensitive: "tools",   // Default - redact tool output
    redactPatterns: [
      "your-internal-token-pattern",
      "internal.company.com"
    ]
  }
}

Verification:

openclaw security audit
# Warns if redactSensitive="off"

# Safe diagnostic export (secrets redacted)
openclaw status --all

OpenClaw Docs: Security - Logs & Transcripts

OSSASAI-LS-03: Memory Safety Against Instruction Smuggling

OpenClaw Implementation:

Session transcripts isolated per session (when dmScope configured)
Sandbox workspace access controls prevent context leakage
Model choice matters: prefer instruction-hardened models (Opus 4.5 recommended)
Reader agent pattern for untrusted content

Mitigation Configuration:

{
  session: {
    dmScope: "per-channel-peer"   // Isolate session memory
  },
  agents: {
    defaults: {
      sandbox: {
        workspaceAccess: "none"   // No shared workspace
      }
    }
  }
}

Best Practices:

Use read-only/tool-disabled reader agent for untrusted content
Keep web_search/web_fetch/browser off for tool-enabled agents
Keep secrets out of prompts; use env/config on gateway host

Model Strength (Security Note): Prompt injection resistance is not uniform across model tiers:

Use latest generation, best-tier model for any bot with tools
Avoid weaker tiers (e.g., Sonnet/Haiku) for tool-enabled agents or untrusted inboxes
If using smaller models: reduce blast radius (read-only tools, strong sandboxing)
For smaller models: enable sandboxing for all sessions and disable web_search/web_fetch/browser
Recommended: Anthropic Opus 4.5 (instruction-hardened, good at recognizing prompt injections)

Verbose Output Warning: /reasoning and /verbose can expose internal reasoning or tool output not meant for public channels:

Keep them disabled in public rooms
Enable only in trusted DMs or tightly controlled rooms
Verbose output can include tool args, URLs, and data the model saw

OpenClaw Docs: Security - Prompt Injection

OSSASAI-LS-04: Retention and Deletion Guarantees

OpenClaw Implementation:

Session transcripts stored in ~/.openclaw/agents/<id>/sessions/*.jsonl
/new or /reset slash commands start fresh session
Manual pruning of old transcripts recommended

Session Management:

# Reset session via message
/new
/reset

# Compact session context
/compact [instructions]

Session Files:

~/.openclaw/agents/<agentId>/sessions/
├── <SessionId>.jsonl       # Session transcript
└── sessions.json           # Session metadata

Retention Best Practices:

Prune old session transcripts if not needed
Use full-disk encryption on gateway host
Dedicated OS user account for Gateway if host is shared

OpenClaw Docs: Sessions and Memory

Supply Chain Controls

OSSASAI-SC-01: Explicit Plugin Trust and Inventory

OpenClaw Implementation:

Plugins run in-process with the Gateway (treat as trusted code)
plugins.allow provides explicit allowlist
npm-installed plugins execute lifecycle scripts during install

Configuration:

{
  plugins: {
    allow: [
      "official-plugin",
      "@scope/verified-plugin"
    ]
  }
}

Plugin Management:

# Install plugin (treat as running untrusted code)
openclaw plugins install <npm-spec>

# Prefer pinned versions
openclaw plugins install @scope/pkg@1.2.3

# Inspect unpacked code before enabling
ls ~/.openclaw/extensions/<pluginId>/

Verification:

openclaw security audit
# Warns if extensions exist without explicit allowlist

OpenClaw Docs: Security - Plugins/Extensions

OSSASAI-SC-02: Reproducible Builds and Pinning

OpenClaw Implementation:

Pin exact versions when installing plugins
Inspect unpacked code before enabling
Plugin install path: ~/.openclaw/extensions/<pluginId>/

Best Practices:

# Pin exact version
openclaw plugins install @scope/pkg@1.2.3

# Inspect before enabling
cat ~/.openclaw/extensions/<pluginId>/package.json

Evidence:

Plugin inventory with pinned versions
Code inspection records

OpenClaw Docs: Plugin

Network Security Controls

OSSASAI-NS-01: TLS Enforcement

OpenClaw Implementation:

Gateway remote connections use WSS (WebSocket Secure)
gateway.remote.tlsFingerprint enables certificate pinning
Tailscale Serve provides TLS termination for HTTPS

Configuration:

{
  gateway: {
    remote: {
      url: "wss://gateway-host:18789",
      token: "<token>",
      tlsFingerprint: "sha256:..."   // Optional: pin TLS cert
    }
  }
}

OpenClaw Docs: Gateway Remote

OSSASAI-NS-02: Certificate Validation

OpenClaw Implementation:

WSS connections validate certificates by default
tlsFingerprint provides optional certificate pinning
Tailscale identity headers validated via tailscale whois

Configuration:

{
  gateway: {
    auth: {
      allowTailscale: true   // Trust Tailscale Serve identity headers
    }
  }
}

Security Rule: Do not forward Tailscale headers from your own reverse proxy.

OpenClaw Docs: Security - Tailscale Serve

OSSASAI-NS-03: API Endpoint Security

OpenClaw Implementation:

Gateway multiplexes WebSocket + HTTP on single port
Auth required for all WS connections (token/password)
Device pairing auto-approved only for local connects

Configuration:

{
  gateway: {
    auth: {
      mode: "token",
      token: "your-token"
    }
  }
}

OpenClaw Docs: Security - Gateway WebSocket

OSSASAI-NS-04: mDNS/Bonjour Discovery Security

OpenClaw Implementation:

Gateway broadcasts presence via mDNS for device discovery
Minimal mode (default): omits sensitive fields (cliPath, sshPort)
Full mode exposes operational details (filesystem paths, SSH availability)

Configuration:

{
  discovery: {
    mdns: {
      mode: "minimal"    // Default - hide sensitive info
      // Or: "off" to disable entirely
      // Or: "full" for debugging (exposes paths)
    }
  }
}

// Or via environment:
// OPENCLAW_DISABLE_BONJOUR=1

OpenClaw Docs: Security - mDNS/Bonjour

Formal Verification Controls (Optional)

OSSASAI-FV-01: Security Invariant Formal Verification

OpenClaw Implementation:

TLA+/TLC models for security-critical paths
Covers: gateway exposure, nodes.run pipeline, pairing, ingress gating, session isolation
See OpenClaw documentation for model details and reproduction steps

Verified Claims:

Model	Claim
`gateway-exposure-v2`	Loopback binding + auth blocks remote compromise
`nodes-pipeline`	nodes.run requires allowlist + approval
`pairing`	Pairing respects TTL and pending caps
`ingress-gating`	Mention gating blocks unauthorized commands
`routing-isolation`	Distinct peers don’t collapse sessions

OpenClaw Docs: Formal Verification

OSSASAI-FV-02: Negative Model Regression Testing

OpenClaw Implementation:

Paired negative models that MUST produce counterexamples
Ensures detection capability for realistic bug classes
Counterexample traces preserved for analysis

Available Negative Models:

gateway-exposure-v2-negative
nodes-pipeline-negative
pairing-negative
ingress-gating-negative
routing-isolation-negative

OpenClaw Docs: Formal Verification - Negative Models

OSSASAI-FV-03: Continuous Verification in CI/CD

OpenClaw Implementation:

Models can be run in CI via make targets
Java 11+ required (TLC runs on JVM)

CI Integration Example:

- name: Run Formal Verification
  run: |
    make gateway-exposure-v2
    make nodes-pipeline
    make pairing

OpenClaw Docs: Formal Verification - Reproducing

Per-Agent Access Profiles

OpenClaw supports multi-agent routing with per-agent sandbox + tool policies:

Full Access (No Sandbox)

{
  agents: {
    list: [{
      id: "personal",
      workspace: "~/.openclaw/workspace-personal",
      sandbox: { mode: "off" }
    }]
  }
}

Read-Only Tools

{
  agents: {
    list: [{
      id: "family",
      workspace: "~/.openclaw/workspace-family",
      sandbox: {
        mode: "all",
        scope: "agent",
        workspaceAccess: "ro"
      },
      tools: {
        allow: ["read"],
        deny: ["write", "edit", "apply_patch", "exec", "process", "browser"]
      }
    }]
  }
}

No Filesystem Access

{
  agents: {
    list: [{
      id: "public",
      workspace: "~/.openclaw/workspace-public",
      sandbox: {
        mode: "all",
        scope: "agent",
        workspaceAccess: "none"
      },
      tools: {
        allow: ["sessions_list", "sessions_history", "sessions_send"],
        deny: ["read", "write", "edit", "exec", "process", "browser"]
      }
    }]
  }
}

Use Cases:

Profile	Access Level	Sandboxing
Personal	Full access	None
Family/Work	Read-only tools	Sandboxed
Public	No filesystem/shell	Sandboxed

OpenClaw Docs: Multi-Agent Sandbox & Tools

Configuration Security

Strict Config Validation

OpenClaw only accepts configurations that fully match the schema. Unknown keys, malformed types, or invalid values cause the Gateway to refuse to start for safety.

# When validation fails, run:
openclaw doctor          # See exact issues
openclaw doctor --fix    # Apply migrations/repairs

Config Includes (`$include`)

Split configs can include sensitive files:

{
  agents: { "$include": "./agents.json5" },
  broadcast: { "$include": ["./clients/mueller.json5"] }
}

Security: Treat included config files with same sensitivity as main config. Keep permissions tight (600).

Environment Variable Substitution

Reference env vars in config using ${VAR_NAME} syntax:

{
  gateway: {
    auth: {
      token: "${OPENCLAW_GATEWAY_TOKEN}"
    }
  },
  models: {
    providers: {
      custom: {
        apiKey: "${CUSTOM_API_KEY}"
      }
    }
  }
}

Security Rules:

Only uppercase env var names are matched: [A-Z_][A-Z0-9_]*
Missing or empty env vars throw an error at config load
Escape with $${VAR} to output literal ${VAR}
Prefer env vars for secrets over hardcoding in config files

Conformance Recipes

L1 — Local-First Baseline

Step 1: Initial Setup

# Full onboarding wizard (recommended)
openclaw onboard --install-daemon

# Or minimal setup
openclaw setup

Step 2: Start Gateway

# Check if service is running (if installed via onboard)
openclaw gateway status

# Or start manually (loopback only)
openclaw gateway --port 18789

Step 3: Verify Health

# Quick health check
openclaw health
openclaw status --all

Step 4: Run Security Audit

openclaw security audit --deep
openclaw security audit --fix

Step 5: Verify Configuration

# Check binding
netstat -an | grep 18789
# Should show 127.0.0.1:18789

# Check permissions
ls -la ~/.openclaw/

Step 6: Test End-to-End

# Open Control UI (no channel setup needed)
openclaw dashboard
# Or: http://127.0.0.1:18789/

# Send test message (if channel configured)
openclaw message send --target +15555550123 --message "Test"

L1 Checklist:

Gateway bound to loopback (gateway.bind: "loopback")
Gateway auth configured (token or password)
DM policy set to pairing or allowlist
Session isolation configured (dmScope)
File permissions correct (700/600)
Log redaction enabled (redactSensitive: "tools")

L2 — Network-Aware Deployment

Step 1: Complete L1

Ensure all L1 controls are implemented.

Step 2: Secure Remote Access

# Prefer Tailscale Serve over LAN binds
tailscale serve --bg 18789

# Or SSH tunnel
ssh -L 18789:localhost:18789 user@gateway-host

Step 3: Enable Additional Controls

{
  session: { dmScope: "per-channel-peer" },
  channels: {
    whatsapp: {
      groups: { "*": { requireMention: true } }
    }
  },
  agents: {
    defaults: {
      sandbox: { mode: "non-main" }
    }
  }
}

Step 4: Run L2 Audit

openclaw security audit --deep

L2 Checklist (includes L1):

Trusted proxies configured (if using reverse proxy)
Mention gating enabled for groups
Tool allow/deny lists configured
Sandboxing enabled for non-main sessions
Elevated exec restricted to specific senders

L3 — High-Assurance Deployment

Step 1: Complete L1 + L2

Ensure all L1 and L2 controls are implemented.

Step 2: Enable Strict Settings

{
  session: { dmScope: "per-account-channel-peer" },
  agents: {
    defaults: {
      sandbox: {
        mode: "all",
        scope: "session",
        workspaceAccess: "none"
      }
    }
  },
  discovery: { mdns: { mode: "off" } }
}

Step 3: Verify Formal Models (Optional)

See OpenClaw Formal Verification for TLA+/TLC model details and verification procedures.

L3 Checklist (includes L1 + L2):

Strictest session isolation (per-account-channel-peer)
All sessions sandboxed (mode: "all")
No workspace access from sandbox (workspaceAccess: "none")
mDNS discovery disabled
Review formal verification documentation

Evidence Generation

# Create evidence directory
mkdir -p evidence

# Full security audit
openclaw security audit --deep 2>&1 | tee evidence/audit-report.txt

# Safe diagnostic (secrets redacted)
openclaw status --all > evidence/status-redacted.txt

# Permission check
ls -la ~/.openclaw/ > evidence/permissions.txt
stat -c "%a %n" ~/.openclaw/* >> evidence/permissions.txt

# Sandbox configuration
openclaw sandbox explain > evidence/sandbox-config.txt

Incident Response

If you suspect compromise:

1. Contain

# Stop the Gateway
pkill -f "openclaw gateway"

# Or stop macOS app if it supervises Gateway
# Lock down inbound surfaces

2. Rotate

# Rotate Gateway auth
openclaw doctor --generate-gateway-token
# Update config, restart Gateway

# Rotate provider credentials
# Revoke/rotate API keys in auth-profiles.json

3. Audit

# Check logs
tail -100 /tmp/openclaw/openclaw-$(date +%Y-%m-%d).log

# Review recent transcripts
ls -lt ~/.openclaw/agents/*/sessions/*.jsonl | head -10

OpenClaw Docs: Security - Incident Response

Security Audit Priority Order

When the audit prints findings, address them in this priority order:

“Open” + tools enabled — Lock down DMs/groups first (pairing/allowlists), then tighten tool policy/sandboxing
Public network exposure — LAN bind, Funnel, missing auth → fix immediately
Browser control remote exposure — Treat like operator access (tailnet-only, pair nodes deliberately)
Permissions — Ensure state/config/credentials/auth are not group/world-readable
Plugins/extensions — Only load what you explicitly trust
Model choice — Prefer modern, instruction-hardened models for any bot with tools

Trust Hierarchy

Owner (Operator)
  │ Full trust
  ▼
AI Agent
  │ Trust but verify
  ▼
Approved contacts (allowlist)
  │ Limited trust
  ▼
Strangers
  │ No trust

Version History

Version	Date	Changes
0.1.0	January 2026	Initial release aligned with OSSASAI v0.1.0 and OpenClaw security model

OCSAS - OpenClaw Security Assurance Standard

Profile Overview

How This Framework Works

The Relationship

Analogy: Industry Standards

What OCSAS Does

Who Uses OCSAS?

Verification Flow

OpenClaw Security Architecture

Quick Security Check

Control Mapping

B2 — Control Plane Controls

OSSASAI-CP-01: Default-Deny Control Plane Exposure

OSSASAI-CP-02: Strong Administrative Authentication

OSSASAI-CP-03: Proxy Trust Boundary Configuration

OSSASAI-CP-04: Operator/Agent Identity Separation

B1 — Inbound Identity Controls

OSSASAI-ID-01: Peer Verification for New Contacts

OSSASAI-ID-02: Session Isolation by Default

OSSASAI-ID-03: Group/Channel Policy Hardening

B3 — Tool Governance Controls

OSSASAI-TB-01: Least Privilege Tool Configuration

OSSASAI-TB-02: Approval Gates for High-Risk Actions

OSSASAI-TB-03: Sandboxing for Untrusted Contexts

OSSASAI-TB-04: Outbound Data Exfiltration Controls

B4 — Local State Controls

OSSASAI-LS-01: Secrets Protected at Rest

OSSASAI-LS-02: Sensitive Log Redaction

OSSASAI-LS-03: Memory Safety Against Instruction Smuggling

OSSASAI-LS-04: Retention and Deletion Guarantees

Supply Chain Controls

OSSASAI-SC-01: Explicit Plugin Trust and Inventory

OSSASAI-SC-02: Reproducible Builds and Pinning

Network Security Controls

OSSASAI-NS-01: TLS Enforcement

OSSASAI-NS-02: Certificate Validation

OSSASAI-NS-03: API Endpoint Security

OSSASAI-NS-04: mDNS/Bonjour Discovery Security

Formal Verification Controls (Optional)

OSSASAI-FV-01: Security Invariant Formal Verification

OSSASAI-FV-02: Negative Model Regression Testing

OSSASAI-FV-03: Continuous Verification in CI/CD

Per-Agent Access Profiles

Full Access (No Sandbox)

Read-Only Tools

No Filesystem Access

Configuration Security

Strict Config Validation

Config Includes ($include)

Environment Variable Substitution

Conformance Recipes

L1 — Local-First Baseline

L2 — Network-Aware Deployment

L3 — High-Assurance Deployment

Evidence Generation

Incident Response

1. Contain

2. Rotate

3. Audit

Security Audit Priority Order

Trust Hierarchy

Version History

References

Config Includes (`$include`)