OpenClaw gateway security starts with a blunt question: who is allowed to make your agent do things?
That sounds obvious until the agent has shell access, files, browser control, message sending, cron, media tools, node commands, or credentials. At that point, “the model should refuse bad requests” is not a security plan. It is a hope. The plan has to live in the Gateway, the channel policy, the tool policy, the sandbox, the host account, and the way secrets are stored.
The OpenClaw docs take a practical stance here. OpenClaw is built for a trusted personal-assistant model: one operator boundary per Gateway. It is not meant to be one shared hostile multi-tenant security boundary where untrusted people all talk to the same powerful agent and magically stay isolated from each other.
That is not a weakness if you run it the way it is designed. It is a warning label. Treat the Gateway as delegated operator power, then decide exactly where that power can be reached from.
OpenClaw gateway security starts with the trust boundary
The first security decision is not the model. It is the boundary.
The Security docs say the supported model is one user or trust boundary per Gateway. If you have mutually untrusted users, separate the Gateways. Ideally, separate the OS users or hosts too. That is the part people skip when they try to turn a personal assistant into a shared service.
Inside one Gateway, authenticated operator access is a control-plane role. It is not a tenant role. A `sessionKey` is a routing selector, not an authorization token. If someone treats a session label like a secret capability, the design is already off track.
The easy mental model is this: if several people can message one tool-enabled agent, they share that agent’s delegated tool authority. The agent may keep separate conversations. That does not mean the host has separate security boundaries.
For a solo operator, this is workable. You can accept more convenience because you are the trust boundary. For a team, customer, or public bot, you need a different shape: one isolated Gateway cell per tenant or trust group, narrow tools, scoped credentials, and sandboxed non-main sessions.
Run openclaw security audit before you expose anything
The fastest way to catch bad assumptions is to run the audit before changing exposure.
openclaw security audit
openclaw security audit --deep
openclaw security audit --fix
openclaw security audit --jsonThe normal audit checks config and local posture. `–deep` attempts live Gateway probes and deeper plugin or skill checks. `–json` is useful if you want to wire the results into a report or CI-style review. `–fix` is intentionally narrow. It can flip open group policies to allowlists and tighten state, config, and include-file permissions. It is not a magic “make this deployment secure” button.
The checks cover the surfaces that actually hurt: inbound DM and group policy, tool blast radius, host exec posture, filesystem drift, Gateway bind and auth, Tailscale Serve or Funnel exposure, browser control, state directory permissions, plugin loading, sandbox settings that look configured but are off, and model hygiene warnings.
The triage order in the docs is right: fix anything open plus tools first, then public network exposure, then browser control exposure, then local disk hygiene, then plugins, then model choice. If strangers can trigger a bot with host tools, you do not have a “prompt injection problem.” You have an exposure problem.
Keep remote access narrow
The exposure runbook gives a simple rule: use the narrowest access pattern that fits the workflow.
For personal administration, loopback plus SSH tunnel is boring and good. Keep the Gateway on `127.0.0.1:18789`, then tunnel when you need access. For personal tailnet access, loopback plus Tailscale Serve is still narrower than binding the Gateway to a broad interface. Tailnet or LAN bind can make sense for known private devices, but it needs Gateway auth and firewall allowlists. A trusted reverse proxy can work for organization SSO, but then the proxy becomes the authentication boundary and must strip or overwrite identity headers.
Direct public port-forwarding to the Gateway should be treated as a last resort. The runbook is plain about this: avoid it. If public access is required, put an identity-aware proxy in front, use TLS, rate limits, strict allowlists, and keep the Gateway unreachable except through that proxy.
Before making a change, write down the basics: host, OS user, state directory, bind mode, auth mode, enabled channels, reachable agents, tool profile, sandbox mode, privileged-tool policy, and credentials available to those agents. This takes ten minutes and saves hours when you need to roll back.
Treat messaging channels as untrusted input
Messaging is the friendly-looking risk surface. A WhatsApp DM or Slack mention feels less serious than an open port, but for an agent with tools it can become the control path.
OpenClaw gives DM policies for that reason. Use `pairing` or an allowlist for normal deployments. Avoid `open` unless you have a very specific public-bot design and the tools are limited. In groups, require mentions unless the room is tightly controlled.
Also set DM scoping so multiple people do not share accidental context. The runbook recommends `session.dmScope: “per-channel-peer”` or `per-account-channel-peer` for multi-account channels. That is not the same as host isolation, but it prevents one person’s DM from quietly becoming another person’s working memory.
The key mistake is combining open access with broad tools. An open DM bot that can run shell commands, read files, spawn sessions, send messages, control browsers, or reach credentials is a loaded system. A good public-facing agent should start with messaging-only tools and no personal credentials. Add power only after you know who can trigger it.
Lock down tools before you worry about prompts
Prompt injection matters. OWASP describes it as a vulnerability where malicious input changes model behavior because instructions and data are processed together. The impacts include unauthorized data access, system prompt leakage, unauthorized tool or API actions, and persistent manipulation across sessions.
That maps directly to agents. A web page, email, document, code comment, or chat message can try to tell the model to ignore its rules and call a tool. You should assume some version of that will happen.
The OpenClaw security stance is the right order: identity first, scope next, model last. Decide who can talk to the bot. Decide which tools that requester can reach. Then rely on the model as one layer, not the foundation.
A hardened exposed agent should not start with host exec, filesystem write, automation, runtime, cron, gateway, session-spawn, browser, or node-control tools. Give it the smallest tool profile that supports the job. Require approval for risky actions. Disable privileged tools unless a known trusted sender needs them.
This is also where requester-scoped controls need sober expectations. Tools-by-sender and owner-only tool inventories reduce direct capability for the current requester. They do not sanitize every other piece of content in the prompt. Quoted chat history, fetched web pages, forwarded messages, attachments, and tool outputs can still influence an owner-triggered turn. Treat those controls as defense in depth, not hostile-user isolation.
Use sandboxing, but understand the line
OpenClaw sandboxing moves tool execution into a sandbox backend. The Gateway process stays on the host. That distinction matters.
Sandboxing is off by default. The modes are `off`, `non-main`, and `all`. `non-main` is useful because shared rooms and channel sessions are not the main session, so they can run sandboxed while the owner’s main session keeps more local power. `all` is stricter and easier to reason about.
The Docker backend defaults are conservative: no network egress, a read-only root filesystem, dropped Linux capabilities, and the `openclaw-sandbox:bookworm-slim` image. You can mount the workspace read-only, read-write, or not at all. For exposed agents, read-only or no workspace access is usually the saner starting point.
{
agents: {
defaults: {
sandbox: {
mode: "all",
backend: "docker",
scope: "session",
workspaceAccess: "ro",
docker: {
image: "openclaw-sandbox:bookworm-slim",
readOnlyRoot: true,
tmpfs: ["/tmp", "/var/tmp", "/run"],
network: "none",
capDrop: ["ALL"]
}
}
}
}
}Do not over-sell this to yourself. Sandboxing materially reduces filesystem and process damage when the model does something foolish. It does not move native plugins or the Gateway process into the sandbox. Tools explicitly allowed through privileged mode can bypass sandboxing. If your threat model includes adversarial users, use sandboxing plus separate Gateways or OS accounts, not sandboxing alone.
Move secrets out of readable files
SecretRefs are one of the more important hardening tools in OpenClaw because they reduce plaintext credentials in config and generated files. A supported credential can point at an environment variable, file provider, exec provider, or shared store instead of sitting directly in `openclaw.json`.
That said, SecretRefs are not a force field. The secrets docs warn that plaintext credentials remain agent-readable when they sit in files the agent can inspect: config files, `.env`, retired auth-profile archives, generated model catalogs, backups, and copied configs. If the agent has file or shell access to the path, API-level redaction does not save you.
For production-style deployments, treat migration as complete only when supported credentials use SecretRefs, old plaintext residue has been scrubbed, and `openclaw secrets audit –check` is clean. Unsupported or rotating credentials should live outside the agent-readable trust boundary or behind separate OS, container, or credential-proxy isolation.
The practical rule: do not mount your whole home directory into an exposed agent and then congratulate yourself for using a secret store. Scope the filesystem first. Then use SecretRefs to reduce what gets persisted.
A practical hardening baseline
If you are starting from a personal OpenClaw setup and want a safer baseline, begin with this posture:
- Keep the Gateway loopback-only unless there is a documented reason to widen it.
- Use token or password auth for any reachable Gateway surface.
- Use pairing or strict allowlists for DMs.
- Require mentions in groups unless the room is tightly controlled.
- Use messaging-only tools for open or semi-open channels.
- Deny host exec for exposed agents, or require approval for a tiny allowed set.
- Disable privileged tools by default.
- Run non-main sessions in a sandbox.
- Keep workspace mounts read-only unless write access is part of the job.
- Move supported credentials to SecretRefs and scrub plaintext leftovers.
- Load only plugins you explicitly trust.
- Run `openclaw security audit –deep` after each exposure change.
Here is the shape I would start from for a chat-driven agent that might receive messages from outside the host:
{
gateway: {
mode: "local",
bind: "loopback",
auth: { mode: "token", token: "replace-with-long-random-token" }
},
session: {
dmScope: "per-channel-peer"
},
agents: {
defaults: {
sandbox: { mode: "non-main" }
}
},
tools: {
profile: "messaging",
deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],
fs: { workspaceOnly: true },
exec: { security: "deny", ask: "always" },
elevated: { enabled: false }
}
}This is not the final config for every deployment. It is a sane starting line. Widen one control at a time and re-run the audit after each change.
Have a rollback plan before you need it
Security work gets much easier when rollback is already written down. If you suspect the Gateway is overexposed, the runbook’s direction is simple: return to loopback, disable inbound channel DMs, deny exec, disable privileged tools, stop public forwarding or Tailscale Funnel, rotate Gateway tokens and affected credentials, remove wildcard allowlists, review logs and tool calls, then re-run the deep audit.
Do not wait until something looks strange in logs to decide where credentials live or which channels should be disabled. The rollback path should be part of the deployment note.
For a personal VPS, the most useful drill is boring: bind back to loopback, turn off public routes, rotate the Gateway token, and prove you can still reach the Gateway through the narrow path you actually need. That exercise tells you more about your real security posture than another paragraph of prompt rules.
FAQ about OpenClaw gateway security
Is OpenClaw safe for multiple untrusted users on one Gateway?
No. The docs define OpenClaw’s supported model as one trusted operator boundary per Gateway. For untrusted users or tenants, run separate Gateways and ideally separate OS users or hosts.
Does sessionKey protect a session like a password?
No. `sessionKey` routes context. It is not an authorization token. Authentication belongs in Gateway auth, channel pairing, allowlists, proxy identity, and the host boundary.
Should I expose the Gateway directly to the internet?
Almost never. The exposure runbook recommends avoiding direct public port-forwarding. If public access is required, use an identity-aware proxy, TLS, rate limits, strict allowlists, and sandboxed agents with limited tools.
Does sandboxing protect the Gateway itself?
No. Sandboxing moves supported tool execution into a sandbox. The Gateway process stays on the host. Native plugins and privileged tools need separate review.
Are SecretRefs enough to protect API keys?
SecretRefs reduce plaintext persistence, but they do not protect secrets left in files the agent can read. Use SecretRefs, scrub old plaintext, scope file access, and isolate credentials by host or account when needed.
What should I fix first after an audit?
Fix open messaging access combined with powerful tools first. Then handle public network exposure, browser control exposure, disk permissions, plugin trust, and model hygiene.
Start with loopback, then widen one control at a time
The best OpenClaw gateway security setup is usually plain. Keep the Gateway local. Pair senders. Use allowlists. Deny host exec for exposed agents. Sandbox non-main sessions. Move secrets out of readable files. Audit after every exposure change.
That might sound less exciting than a clever prompt defense, but it is the part that holds when the model sees malicious text. Prompts can help the agent behave. Boundaries decide what damage is possible when it does not.
If you are running OpenClaw on a VPS today, do one thing before adding another channel: run `openclaw security audit –deep`, read the findings, and fix anything that combines open access with powerful tools. That is where the real risk usually lives.
