Hardening OpenClaw for production requires configuring multiple security layers that work together. Sandbox modes control how agents execute commands -- from unrestricted (off) to fully isolated (strict). Tool access control uses allow and deny lists to restrict what each agent can do. Elevated access provides a controlled way for agents to temporarily request restricted tools with user approval. Network isolation limits what agents can reach over the network. Secrets management keeps credentials out of configuration files. This page covers each layer in depth with production-ready configurations.
Master openclaw security hardening for production
Take the OpenClaw for Production & Advanced Use course with hands-on lessons and challenges.
The dev-assistant has sandbox off for local development only -- never use this in production. The code-reviewer has basic sandboxing that hides sensitive environment variables and restricts SSH access. The public-support agent has strict sandboxing with filesystem restrictions (only /workspace and /tmp), network restrictions (only your API and GitHub), and resource limits. Scope: tree on the public-support agent ensures sub-agents inherit these restrictions.
Each agent has the minimum tools it needs (allow) and an explicit blocklist (deny) as a safety net. The code-reviewer can read and analyze code but cannot write files or run commands. The deployer can execute deployments but cannot modify source code. The public-bot can only query the knowledge base -- all action tools are explicitly denied. The deny list catches misconfiguration: if someone accidentally adds bash to the public-bot's allow list, the deny list still blocks it.
This configuration adds rate limiting (maxElevationsPerHour), a cooldown period between elevations, and notifications on every elevation event. ApprovalChannels restricts where elevation approvals can be issued -- only Telegram admins can approve, even if the agent runs on Discord. These controls prevent abuse while maintaining flexibility for legitimate needs.
Network isolation restricts which hosts the agent can connect to. The allowedHosts whitelist permits only your API, docs, and GitHub. The blockedHosts list explicitly blocks internal services and cloud metadata endpoints -- a common target for prompt injection attacks. AllowedPorts restricts to HTTP/HTTPS only. The DNS resolver override prevents DNS-based exfiltration attacks.
The validate command performs automated security checks against your configuration. Integrate it into your CI/CD pipeline to catch misconfigurations before deployment. The manual checks supplement the automated validation with network-level tests for TLS and rate limiting that the config validator cannot perform.
Deploying to production with sandbox: off on any agent, even 'trusted' internal agents that only the team uses
Use at least basic sandboxing for every agent in production. Even internal agents are vulnerable to prompt injection through pasted content, forwarded messages, or malicious links. Sandbox: off should only exist on developer laptops.
Configuring tools.allow but not tools.deny, relying entirely on the whitelist and leaving no safety net for misconfiguration
Always configure both lists. The deny list catches mistakes in the allow list. If someone accidentally adds bash to a reviewer's allow list, the deny list still blocks it. This is defense in depth.
Disabling elevation approval (requireApproval: false) for convenience, allowing agents to self-escalate their tool access without human oversight
Elevation without approval means agents can grant themselves any tool at any time. This defeats the purpose of tool access control entirely. Always require approval, and restrict approvalChannels to admin-only channels.
Not blocking cloud metadata endpoints (169.254.169.254, metadata.google.internal) in strict sandbox, leaving agents vulnerable to credential theft via prompt injection
Always add cloud metadata endpoints to the blockedHosts list. Prompt injection attacks commonly target these endpoints to steal service account tokens and instance credentials. This is especially critical for public-facing agents.
Storing API keys and bot tokens directly in openclaw.json and committing the file to version control
Use ${VAR_NAME} syntax for all secrets. Store values in .env files (gitignored) for development and a secrets manager for production. Rotate keys immediately if they are ever committed to Git.
Hardening OpenClaw for production requires layered security: sandbox modes (off, basic, strict) control execution, tool allow/deny lists restrict per-agent capabilities, elevated access provides controlled temporary escalation with approval, network isolation prevents data exfiltration, and secrets management keeps credentials out of configuration files. Use strict sandbox with scope: tree for public-facing agents. Always configure both allow and deny lists. Block cloud metadata endpoints. Run `openclaw config validate --strict` before every deployment. Never deploy with sandbox: off.
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.