IOTXINGNotes
中文

OpenClawAI

OpenClaw Gateway Security in Practice: Chat, Code and the Strictest Configuration

PublishedWords 746Read 3 min
openclawaillmagentsecuritysandboxprompt-injection

In OpenClaw's security model the core question is not "is the model smart enough" but "are access control and execution boundaries defined up front". This post distills the most common and most practical measures from the official docs, and answers three questions that come up before almost every launch:

  1. For a chat bot, what is the minimum set of restrictions?
  2. For a code-handling scenario, how do you keep the blast radius under control?
  3. For public or untrusted input, what does the strictest configuration look like?

If you are just getting started, read the OpenClaw and AI topic pages first, then come back and apply this.

1. One principle first: boundaries before capabilities

The official docs keep repeating one operational fact: inside a single Gateway instance, every authenticated operator shares the same trust boundary. In other words, do not treat it as a "hard multi-tenant isolation bus".
The right posture is:

  1. Define who can trigger the bot (DM policy, group policy, allowlists).
  2. Define what the bot can call (tools allow/deny, disable control-plane tools).
  3. Define what the bot can touch (sandbox, workspaceAccess, network exposure, SSRF policy).

2. The four everyday OpenClaw security measures (do these before launch)

1) Entry control: tighten both DMs and group chats

  • For DMs, default to pairing so strangers cannot trigger the bot directly.
  • For group chats, set requireMention: true everywhere to avoid an "always-on auto-responder".
  • Avoid running dmPolicy="open" or groupPolicy="open" for any length of time.

2) Session isolation: keep multi-user DM context from leaking

When several people can DM the bot:

{
  "session": { "dmScope": "per-channel-peer" }
}

This lowers the risk of cross-user context leakage. Note that it is message context isolation, not host-level privilege isolation.

3) Least-privilege tools: dangerous tools off by default

At a minimum, restrict:

  • exec, process, browser, web_fetch, web_search
  • Control-plane tools that mutate persistent state: gateway, cron

The docs give a directly usable starting point:

{
  "tools": {
    "deny": ["gateway", "cron", "sessions_spawn", "sessions_send"]
  }
}

4) Sandbox and network exposure: lock "can execute" inside a container

  • The sandbox is recommended, not enforced by default.
  • With the sandbox off, exec may run directly on the gateway host.
  • Prefer gateway.bind: loopback; never expose an unauthenticated gateway on 0.0.0.0.

For chat assistants, especially in group chats, use "tight entry + minimal tools":

{
  "gateway": {
    "mode": "local",
    "bind": "loopback",
    "auth": { "mode": "token", "token": "your-long-random-token" }
  },
  "channels": {
    "whatsapp": {
      "dmPolicy": "pairing",
      "groups": { "*": { "requireMention": true } }
    }
  },
  "session": { "dmScope": "per-channel-peer" },
  "tools": {
    "profile": "messaging",
    "deny": ["gateway", "cron", "exec", "browser", "web_fetch", "web_search"]
  }
}

Also disable /reasoning and /verbose, or enable them only in controlled environments, because that output can leak tool arguments, URLs or context.

4. Restrictions for code scenarios (read a lot, write a little, start read-only)

If the bot needs to read code, analyze it and suggest patches, start in read-only mode:

{
  "agents": {
    "list": [
      {
        "id": "code-review",
        "sandbox": {
          "mode": "all",
          "scope": "agent",
          "workspaceAccess": "ro"
        },
        "tools": {
          "allow": ["read"],
          "deny": ["write", "edit", "apply_patch", "exec", "process", "browser"]
        }
      }
    ]
  }
}

This fits a "review first, change later" team workflow: the model identifies risks and proposes changes, a human applies them.

5. The strictest configuration (public or untrusted input)

When the agent faces a public entry point or routinely reads untrusted external content (web pages, attachments, email, logs), stack the strictest policies:

  1. workspaceAccess: "none" — no filesystem reads or writes.
  2. Disable the whole shell/execution chain: exec, process, apply_patch.
  3. Disable persistent control-plane changes: gateway, cron.
  4. Enable the strict SSRF policy for the browser (private networks blocked by default):
{
  "browser": {
    "ssrfPolicy": {
      "dangerouslyAllowPrivateNetwork": false,
      "hostnameAllowlist": ["*.example.com", "example.com"],
      "allowedHostnames": ["localhost"]
    }
  }
}
  1. Allowlist URL inputs to shorten the injection chain of "read malicious instructions, then call a tool".

6. Prompt injection: why both chat and code need defenses

Prompt injection does not only arrive through DMs from strangers; it can come through any external content carrier (web pages, attachments, pasted code, log snippets).
Do not treat the system prompt as a hard boundary. What actually works:

  1. Tighten channels (pairing / allowlist / mention gating).
  2. Minimize tool permissions (deny dangerous tools).
  3. Sandbox isolation plus workspace access limits (ro / none).
  4. Keep secrets out of prompts; manage sensitive values in host environment configuration.

7. Pre-release checklist (60 seconds)

Run at least once before going live:

openclaw security audit

After larger changes, add:

openclaw security audit --deep

You can also browse the security-related posts under Tags and turn these settings into a team baseline.

References

FAQ

Q1: What is the minimum security configuration for an OpenClaw chat bot?

At least three things: dmPolicy=pairing, requireMention=true for group chats, and a tools deny list covering the dangerous execution chain (exec/process/browser/web_fetch/web_search).

Q2: Why start read-only for code review?

A read-only sandbox (workspaceAccess=ro plus denying write/edit/apply_patch/exec) sharply reduces accidental edits and supply-chain risk, which suits an "assess first, apply later" engineering flow.

Q3: What is the core of the strictest configuration for a public agent?

"No file access + no execution + no control plane + strict SSRF policy + URL allowlist". Lock the boundary down first, then grant permissions back one at a time as needed.

Related posts