Isolation & Trust Boundaries

The diagram below shows how requests flow through OpenClaw's trust zones — from external actors through authentication and permission scoping, into the gateway process, and out to sandboxed execution and external services.

Entry points

Three classes of external actor connect to the gateway:

• Channels — messaging platforms (Slack, Telegram, Discord, etc.) deliver webhook events over HTTPS.
• Web browser — the Control UI connects over loopback for local administration.
• MCP clients — external tools connect with per-connector permission scoping managed by ClawCentral.

All inbound traffic passes through the gateway's authentication layer before reaching any internal service.

Auth + rate limiting

The first trust boundary. Every request must present a valid credential — token, device identity, or trusted-proxy header. Failed authentication is rate-limited to 10 attempts per 60 seconds.

Permission scoping

A second layer enforces fine-grained access control on top of authentication. Permissions are scoped per-tool and per-connector, with ClawCentral managing the scope definitions for managed deployments.

Gateway process

The gateway process is the trusted operator boundary. Authenticated callers are treated as operators within this zone. It contains four core components:

Component	Role
Agent core	Runs skills, tools, plugins (trusted, in-process), hooks, memory, cron triggers, and outbound AI model calls
Session router	Routes messages by session key — a routing label, not an auth boundary
Config KV store	Plaintext, operator-visible configuration. No per-key encryption
Secrets store	Permission-hardened credential storage via env, file, or exec providers. API keys live here, not in config

Cron scheduler

Scheduled agent turns require admin scope. The scheduler dispatches agentTurn and systemEvent triggers into the agent core.

Execution sandbox

Code execution is isolated in a container that is off by default and must be explicitly enabled. The sandbox provides three isolation dimensions:

• Process — runs as a non-root user in a Linux container with no host access.
• Filesystem — host-isolated with no bind mounts by default; only a temporary root is writable.
• Execution — exec, spawn, and shell calls are contained. Supports Node, Python, Go, Rust, and Bun.

Entry to the sandbox requires explicit exec approval and allowlist membership.

External services

Two external service boundaries sit outside the host machine:

• Paired nodes — remote devices (macOS, iOS, Android, headless) connected via node pairing with exec approval and allowlist enforcement. Each node runs on a separate OS/host boundary.
• AI model provider — outbound calls originate from the agent core only. API keys are stored in the secrets store, never in config KV.