Security in OpenClaw is built around the principle of least privilege applied at every layer. Per-agent sandbox modes control how agents execute commands. Tool allow/deny lists restrict what each agent can do. Channel access controls limit who can interact with agents. Secrets management keeps credentials out of configuration files. For production deployments, these controls are not optional -- they are the difference between a secure system and one that is vulnerable to prompt injection, credential leakage, and unauthorized access.
Master openclaw security & sandboxing
Take the Introduction to OpenClaw course with hands-on lessons and challenges.
The code-reviewer has strict sandboxing that extends to any sub-agents it spawns (scope: tree). It can only read files, search, and lint -- it cannot write files, run shell commands, or deploy. The deployer has basic sandboxing applied only to itself (scope: agent). Defense in depth: both agents have deny lists that explicitly block dangerous tools.
Telegram is restricted to a single admin user -- nobody else can interact with the bot. Discord is restricted to a specific guild (server). WebChat only accepts requests from your company's domain. These restrictions prevent unauthorized users from triggering agent actions.
Environment variables keep secrets out of configuration files. The ${VAR_NAME} syntax is resolved at runtime when the Gateway starts. OpenClaw also supports custom paths via OPENCLAW_HOME, OPENCLAW_STATE_DIR, and OPENCLAW_CONFIG_PATH for production deployments that follow filesystem hierarchy standards.
This checklist covers the key security controls for a production OpenClaw deployment. Run it before going live and periodically as part of security audits. Each step verifies a different layer of defense: sandboxing, tool access, channel restrictions, secrets, and TLS.
Elevation allows agents to temporarily request restricted tools with user approval. MaxDuration (300 seconds) limits how long the elevated access lasts. Audit logging tracks all tool calls for 90 days. Model request logging is disabled to reduce noise (and privacy concerns), but tool call logging stays on for accountability.
Setting sandbox mode to off during development and forgetting to change it before deploying to production
Default to strict sandboxing and only relax when needed. Use separate configuration files for development and production, or use environment-specific overrides.
Using scope: agent for an orchestrator that spawns sub-agents, leaving the sub-agents unsandboxed
Always use scope: tree for any agent that can spawn sub-agents. Without tree scope, sub-agents inherit the default sandbox, which may be less restrictive than intended.
Hardcoding API keys and bot tokens directly in openclaw.json and committing the file to Git
Use ${VAR_NAME} syntax for all secrets. Add .env files to .gitignore. Use a secrets manager (AWS Secrets Manager, Vault, Doppler) for production deployments.
Not restricting channel access, allowing anyone who discovers the bot to interact with powerful agents
Always configure allowedUsers, allowedGuilds, or CORS restrictions for channels connected to agents with sensitive tools. Public-facing agents should have the most restrictive tool access.
OpenClaw security is built on least privilege at every layer. Sandbox modes (off, basic, strict) control command execution. Scope (agent, tree) determines sandbox inheritance for sub-agents. Tool allow/deny lists restrict per-agent capabilities. Channel access controls limit who can interact with agents. Secrets use ${VAR_NAME} syntax -- never hardcode. For production: strict sandbox, tree scope, explicit tool lists, channel restrictions, reverse proxy with TLS, and audit logging.
Interactive lessons and challenges on Stanza, practice in VS Code, Cursor, or the web.
Interactive lessons and challenges, right in your code editor.
Check the free courses. No credit card.