In This Article
Introduction
OpenClaw agents run shell commands, manage files, browse the web, and execute code. That power makes them useful — and dangerous if misconfigured. Every production OpenClaw deployment needs explicit security hardening. This guide covers the full security stack: what to lock down, how, and why.
This isn't theoretical. These are the exact measures we implement for every OpenClaw Consult client deployment. Skip any of these and you're running a production system with known vulnerabilities.
Threat Model
Before hardening, understand what you're defending against:
Prompt injection. External input (emails, messages, web content) that manipulates agent behavior. An attacker crafts input that makes the agent execute unintended actions — exfiltrating data, modifying files, or making unauthorized API calls.
Data exfiltration. The agent has access to sensitive data (API keys, customer records, internal documents). Without network controls, it could send that data to an external endpoint.
Credential exposure. API keys, database passwords, and other secrets in the agent's context. If the agent can read its own configuration, it can leak credentials through any output channel.
Resource exhaustion. Agents in loops or making excessive API calls. Cost spikes from unbounded LLM usage. Disk fills from uncontrolled file operations.
Lateral movement. An agent that escapes its sandbox and accesses other systems on the network. This is the worst-case scenario and the reason isolation matters.
Container Sandboxing
Run OpenClaw inside a container (Docker) with minimal permissions:
Read-only filesystem. Mount the OpenClaw directory as read-only. Only the workspace and memory directories should be writable. This prevents the agent from modifying its own code or configuration.
No host network. Use Docker's bridge network, not host networking. The container gets its own network namespace with explicit port mappings only for required services.
Drop capabilities. Remove all Linux capabilities except what's strictly needed. No CAP_NET_RAW, no CAP_SYS_ADMIN, no CAP_NET_BIND_SERVICE unless explicitly required.
Resource limits. Set CPU, memory, and disk limits. Prevents resource exhaustion from runaway agents. Typical: 2 CPU cores, 4GB RAM, 10GB disk for standard deployments.
Non-root user. Run the OpenClaw process as a non-root user inside the container. Never run agents as root.
Secret Management
Never put secrets in agent context:
Environment variables. Inject API keys and credentials as environment variables at container startup. The agent's Skills read from environment, not from configuration files.
Secret rotation. Rotate API keys on a schedule. If a key is compromised, the blast radius is limited to the rotation window.
Principle of least privilege. Each Skill gets only the credentials it needs. The email Skill doesn't need the database password. The CRM Skill doesn't need the payment processor key.
No secrets in memory. Configure OpenClaw's memory system to never store credentials. Audit memory files periodically to verify.
Network Isolation
Control what the agent can reach:
Allowlist outbound connections. The agent should only reach approved endpoints: your CRM API, your email service, the LLM provider. Block everything else at the network level.
DNS filtering. Use a DNS resolver that only resolves approved domains. This prevents the agent from reaching arbitrary endpoints even if prompt injection succeeds.
No inbound access. The agent container should not accept inbound connections from the internet. Triggers come through approved channels (webhooks to a gateway, message queues, or scheduled heartbeats).
Separate network segment. In enterprise deployments, put the agent on its own VLAN or VPC subnet. No direct access to database servers, internal tools, or other production systems.
Prompt Injection Defense
The most active threat vector for agentic systems:
Input sanitization. Clean all external inputs before they enter agent context. Strip HTML, control characters, and known injection patterns. Don't trust any external input.
Context separation. System instructions and user inputs should be clearly delineated. Use XML tags or delimiters that the model respects. Never concatenate untrusted input directly into system prompts.
Output validation. Before the agent executes any action (API call, file write, shell command), validate it against expected patterns. An agent that suddenly tries to curl an unknown domain should be blocked.
Action approval workflows. For high-risk actions (sending money, deleting data, contacting customers), require human approval. The agent proposes, a human approves. Adds latency but prevents catastrophic mistakes.
Canary tokens. Place unique strings in sensitive areas. If an agent outputs a canary token, you know it accessed something it shouldn't have. Alerts fire immediately.
Access Control
Role-based access. Not everyone needs admin access to the agent system. Operators can monitor and restart. Developers can modify Skills. Admins can change configuration. Users can interact through approved channels.
Audit logging. Log every action the agent takes: API calls, file operations, shell commands, and decisions. Immutable logs stored outside the agent's reach. Essential for debugging and compliance.
Multi-tenant isolation. If serving multiple clients or departments, each tenant gets its own agent instance with isolated data, credentials, and network access. No shared state between tenants.
Monitoring and Alerting
You can't secure what you can't see:
Cost monitoring. Track API spend in real-time. Set thresholds and alerts. A sudden spike usually means a loop or injection. Circuit breakers that pause the agent if spend exceeds thresholds.
Behavior monitoring. Track what the agent does over time. Baseline normal behavior. Alert on anomalies — unusual API calls, unexpected file access, new network connections.
Health checks. Regular heartbeat monitoring. Alert if the agent stops responding or takes too long to complete tasks. Automatic restarts for transient failures.
Error tracking. Centralized error logging. Categorize errors by type and severity. Persistent errors often indicate configuration issues or upstream API changes.
Security Checklist
Use this checklist for every OpenClaw deployment:
- Agent runs in a Docker container with resource limits
- Container uses non-root user
- Filesystem is read-only except workspace directory
- Network is isolated with outbound allowlist
- All secrets are in environment variables, not config files
- Secrets are rotated on schedule
- Memory system audited for credential leaks
- External inputs are sanitized before entering agent context
- High-risk actions require human approval
- All agent actions are logged immutably
- Cost monitoring with automatic circuit breakers
- Health checks with automatic restart
- Canary tokens placed in sensitive areas
- DNS filtering blocks unapproved domains
- Role-based access control for operators and developers
Frequently Asked Questions
Is OpenClaw safe to run in production?
Yes, with proper hardening. Out of the box, OpenClaw is designed for local development. Production deployment requires explicit security measures: sandboxing, network isolation, secret management, and monitoring. This guide covers all of them.
What's the biggest security risk with OpenClaw?
Prompt injection is the most active threat. External inputs (emails, messages, web content) can manipulate agent behavior if not properly sanitized. Defense requires input validation, context separation, output filtering, and action approval workflows.
Can OpenClaw Consult set up security for my deployment?
Yes. Every OpenClaw Consult engagement includes production-grade security hardening. Sandboxing, secret management, network isolation, prompt injection defense, and monitoring are included in every build — not optional add-ons.
Conclusion
OpenClaw's power comes from its ability to act autonomously. That power requires explicit security boundaries. Every measure in this guide is something we implement for real client deployments. Skip them at your own risk.
Need help securing your OpenClaw deployment? Talk to our team.