Security & Trust

Understand OpenClaw's Gateway trust model, DM pairing, shared-agent risk, tool policy, sandboxing, elevated access, secrets, and usage controls.

OpenClaw connects real chat surfaces to tools that can affect files, browsers, devices, and external services. Security starts with a clear trust model.

Core Trust Model

OpenClaw is best treated as a trusted operator gateway, not a hostile multi-tenant platform.

• The Gateway is the control plane.
• Authenticated operator access is powerful.
• Chat senders can steer the agent if policy allows them.
• Session keys route context; they are not authorization tokens.
• Nodes are remote execution or device surfaces once paired.
• Tool approvals are guardrails for operator intent, not a complete tenant isolation system.

If you need hostile-user isolation, split by OS user, host, or Gateway.

DM Pairing

DM pairing should stay enabled for public channels. Unknown senders should not directly control a tool-enabled agent.

openclaw pairing list
openclaw pairing approve <channel> <code>
openclaw doctor

Use explicit allowlists and access groups for teams. Avoid wildcard sender access unless the agent has minimal tools and no sensitive context.

Shared Channel Risk

The riskiest setup is a powerful agent in a shared chat room.

Risks include:

• prompt injection from any allowed sender
• accidental exfiltration through tools
• one sender steering work that affects shared state
• private browser or credential access used in a group context

For company-shared agents:

• run a dedicated Gateway or OS user
• use dedicated service accounts
• keep personal accounts out of the runtime
• limit tools
• require confirmation for side effects

Gateway Hardening

Use local binding and authenticated remote access:

• keep loopback binding for local-only setups
• use Tailscale or SSH tunnels for remote access
• require token, password, trusted proxy, or device auth as appropriate
• require explicit pairing for new browsers/devices where remote
• avoid public unauthenticated Gateway ports

Audit regularly:

openclaw security audit
openclaw security audit --fix
openclaw doctor

Tool Policy

Tool policy controls what the model can even see.

{
  "tools": {
    "profile": "messaging",
    "exec": { "security": "ask" },
    "fs": { "workspaceOnly": true },
    "deny": ["browser"],
    "allow": []
  }
}

Prefer small profiles for group rooms and external channels. Grant browser, exec, node, cron, or message-sending tools only when the agent actually needs them.

Sandboxing

Sandboxing reduces blast radius for tool execution. It can apply to all sessions or only non-main sessions.

{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "non-main",
        "backend": "docker",
        "scope": "session",
        "workspaceAccess": "rw"
      }
    }
  }
}

Supported backend patterns include Docker, SSH, and OpenShell where configured. Sandboxing does not sandbox the Gateway itself.

Elevated Access

Elevated execution bypasses ordinary sandbox boundaries by design. Treat it as a controlled escape hatch, not a convenience toggle.

Use it only for tasks that truly require host-level authority, and prefer explicit approval.

Secrets

Never put real API keys in AGENTS.md, SOUL.md, TOOLS.md, skills, or chat prompts.

Use env vars, files, auth profiles, or SecretRefs:

openclaw secrets audit
openclaw secrets reload

Review plugin credential handling before enabling a new plugin.

Cost and Usage

OpenClaw can surface usage, but provider dashboards remain the billing source of truth.

/usage tokens
/usage full
/usage off

openclaw status --usage
openclaw sessions list --usage

Control cost through:

• model choice
• output limits
• prompt compaction
• cron concurrency
• fewer always-on skills
• provider-side budgets

Hardened Baseline

1. Start with one trusted operator.
2. Keep Gateway local or tunneled.
3. Enable DM pairing.
4. Use narrow tool profiles.
5. Sandbox non-main or group sessions.
6. Keep secrets outside prompt files.
7. Review plugins before enabling.
8. Check usage and logs after automation changes.