An AI agent with access to your shell, your files, your messaging channels, and your APIs is genuinely powerful. It's also a real attack surface. Before you give your agent tool access, you should understand exactly how OpenClaw keeps it from going sideways — and where the limits are.
This post covers OpenClaw's actual security architecture: what it protects, what it relies on you to configure, and what you need to know before deploying an agent that can do things in the real world.
The Core Security Model: Personal Assistant, Not Multi-Tenant
OpenClaw's security posture is built around a specific assumption: one trusted operator boundary per gateway. This is the personal assistant model — you, your agent, your data.
This is important because it means OpenClaw is not designed to isolate mutually adversarial users sharing one gateway. If multiple untrusted users can message your tool-enabled agent, they're effectively sharing delegated tool authority. For multi-tenant or hostile-user isolation, you need separate gateways and credentials per trust boundary.
Within the personal assistant model, OpenClaw gives you five layers of defense.
Layer 1: Channel Access Control
The first line of defense is who can talk to your agent at all. Every channel integration supports an allowFrom list that restricts inbound access to specific users.
\json
{
"channels": {
"whatsapp": { "allowFrom": ["+15555550123"] },
"telegram": { "botToken": "YOUR_BOT_TOKEN", "allowFrom": ["123456789"] },
"discord": { "token": "YOUR_DISCORD_TOKEN", "dm": { "allowFrom": ["123456789012345678"] } },
"slack": { "dm": { "allowFrom": ["U123SLACK456"] } }
}
}
\\
Without allowFrom, anyone who can reach your bot can send it messages. On WhatsApp especially, this is a real risk — bots don't have built-in auth, so allowFrom is your authentication layer.
For group chats, add a separate layer:
\json
{
"channels": {
"whatsapp": {
"allowFrom": ["+15555550123"],
"groupPolicy": "allowlist",
"groupAllowFrom": ["+15555550123"],
"groups": { "*": { "requireMention": true } }
}
}
}
\\
requireMention: true means the agent only responds when explicitly @-mentioned, which prevents it from reacting to every message in a busy group.
Layer 2: Session Isolation
Once a message is allowed in, OpenClaw routes it to an isolated session. Session keys are structured as agent:channel:peer — so different users, different channels, and different agents each get their own context. They don't share conversation history or accumulated state.
For sensitive deployments, enable secure DM mode when multiple users can reach the same agent. Without it, DMs from different senders collapse into a single context by default.
Sub-agents (spawned for background tasks) also run in isolated sessions with clean slates — they don't inherit your main session's context unless you explicitly pass it in the prompt. This is by design: sub-agents are isolated workers, not extensions of your main session.
Layer 3: Tool Execution Control
This is where things get serious. OpenClaw's tool system is powerful — exec, browser, file writes, external API calls. The tool policy system controls which tools are available in which contexts.
Tool Allow/Deny Lists
\json
{
"tools": {
"allow": ["exec", "read", "write", "edit"],
"deny": ["browser", "canvas"]
}
}
\\
You can lock down specific tools globally or per-agent.
Exec Approvals
The exec tool — the one that runs shell commands — has its own approval layer:
\json
{
"tools": {
"exec": { "ask": "on-miss" }
}
}
\\
Approval modes:
- off — no approval required (fastest, least safe)
- on-miss — ask when the command isn't in the known-safe list
- always — require approval for every exec call
When approval is needed, OpenClaw pauses and sends you the exact command with /approve allow-once, /approve allow-always, or /approve deny options.
Elevated Tool Access
Some tool calls require elevated permissions. Elevated access is gated per-channel and per-user:
\json
{
"tools": {
"elevated": {
"enabled": true,
"allowFrom": {
"slack": ["U123YOURID456"],
"whatsapp": ["+15555550123"]
}
}
}
}
\\
Layer 4: Sandbox Isolation
For non-main sessions — sub-agents, cron jobs, isolated tasks — OpenClaw supports Docker sandbox isolation:
\json
{
"agents": {
"defaults": {
"sandbox": {
"mode": "non-main",
"perSession": true,
"docker": {
"image": "openclaw-sandbox:bookworm-slim",
"readOnlyRoot": true,
"network": "none",
"user": "1000:1000"
}
}
}
}
}
\\
With network: "none", a sandboxed sub-agent literally cannot make outbound network requests. Even if it runs malicious code, it can't exfiltrate data or call home.
Layer 5: External Content Wrapping
When your agent fetches URLs, reads emails, or processes webhook payloads, that content arrives wrapped in XML tags with an explicit security notice — OpenClaw's defense against indirect prompt injection.
Is it perfect? No. But wrapping + the security notice significantly raises the bar compared to injecting content directly into context.
Prompt Injection: The Honest Assessment
OpenClaw's threat model is refreshingly honest:
- Direct prompt injection: Residual risk = Critical. Detection only, no blocking.
- Indirect prompt injection: Residual risk = High. Content wrapping helps but isn't foolproof.
- Tool argument injection: Residual risk = High. Relies on user judgment via exec approvals.
Your actual defense is:
- Restrict who can send messages — allowFrom
- Use exec approvals — require human confirmation
- Don't fetch untrusted content with elevated permissions
- Sandbox sub-agents — isolate untrusted workloads
ClawHub Skill Supply Chain
If you install skills from ClawHub, you're running third-party code in your agent's context. Treat skill installation like installing an npm package: it runs in your environment with your permissions. Only install skills from authors you trust.
Tailscale: The Cleanest Gateway Auth
\json
{
"gateway": {
"host": "100.x.y.z",
"port": 8080,
"auth": { "type": "tailscale" }
}
}
\\
Only devices on your Tailnet can reach the gateway. No tokens to manage, no ports to expose.
What to Configure Right Now
- Set allowFrom on every channel — no exceptions
- Run openclaw security audit and fix what it flags
- Enable exec approvals (ask: "on-miss" at minimum)
- Restrict elevated tool access to your user ID only
- Enable sandbox mode for non-main sessions
- Use Tailscale if your gateway is on a remote server
The goal isn't paranoia — it's being deliberate about who can talk to your bot, where the bot is allowed to act, and what happens if something goes wrong.
Originally published at openclawplaybook.ai. Get The OpenClaw Playbook — \$9.99 for the full configuration guide, security templates, and real-world agent setups.
Top comments (0)