I have been running OpenClaw (an open-source AI agent framework for building autonomous assistants that can use tools, browse the web, write code, and chain together multi-step tasks) in production for about six months, and the hardening checklist I am about to give you is the one I wish I had when I started. I learned most of it the hard way: by deploying a chat agent, watching a prompt-injection (an attack where untrusted text is crafted to make the AI follow the attacker’s instructions instead of the user’s) attack turn it into a credential-leaking machine, and then spending a weekend reading the security advisories. I am writing this so you do not have to do the same.
OpenClaw is a powerful tool. It is also, like any agent framework, a force multiplier for whatever the agent can be made to do. The same agent that books your flights can also be made to read your email and exfiltrate the contents, if the wrong input lands in the wrong context window. The fix is not to not use OpenClaw. The fix is to deploy it like you would deploy any other piece of infrastructure that touches untrusted input. With boundaries, with logging, and with a clear plan for what happens when something goes wrong.
Treat the tool execution layer as a security boundary
The single most important hardening step is to make sure that the tools your OpenClaw agent can invoke are running in a sandboxed (a restricted execution environment that limits what the code can do, often using containers or virtualization) environment, not on the host. I use Firejail (a Linux security tool that sandboxes applications by restricting their filesystem and network access) by default for shell tools, and a separate LXC container (a lightweight OS-level virtualization system that runs an isolated Linux system on top of the host) for any tool that needs network access.
The reason this matters: an agent that can call subprocess.run(["bash", "-c", user_input]) on the host is one bug in your prompt parsing away from rm -rf /. An agent that can call the same thing inside a Firejail sandbox is one bug away from deleting the contents of the sandbox, which you can wipe and rebuild in 30 seconds.
My current production setup:
- One Firejail profile per tool category. The shell tool runs in a profile that allows read access to
/tmpand the agent’s working directory, and no network. - The web-fetching tool runs in a profile that allows network access to a curated allowlist, and no filesystem writes outside
/tmp. - The code-execution tool runs in a fresh LXC container per session, destroyed on session end.
- Every tool invocation logs the input, the output, the timestamp, and the tool name to a structured log that I ship to Loki (an open-source log aggregation system designed for querying large volumes of structured logs).
This is more setup than the OpenClaw quickstart guide describes. It is also the difference between a research project and a production deployment.
Lock down the system prompt
The system prompt is the text that tells the agent how to behave. It is also the most common attack surface. An attacker who can append to the system prompt owns the agent. Treat the system prompt as if it were a root password:
- Store it in a file with
chmod 600(read/write for owner only), not in a database row that anyone with database access can modify. - Sign it with HMAC (a keyed hash that lets you verify the message has not been tampered with) at startup, and verify the signature before each agent invocation. If the signature does not match, refuse to start the agent.
- Do not let the agent’s own outputs modify the system prompt. This is a real attack vector, and I have seen it exploited.
- Version the system prompt in git. Every change is a commit. Every commit has a reviewer. Every reviewer knows what they are approving.
The version control step is the one most teams skip, because it feels like overhead. It is not overhead. It is the audit trail that lets you answer the question “what was the agent doing three hours ago when it leaked the customer’s email” with a specific commit, not with a shrug.
Isolate the model API credentials
The API key for your model provider (OpenAI, Anthropic, an open-source model running on your own hardware) is a high-value secret. It is also a secret that the agent does not strictly need to know. Configure the API call to be made by the OpenClaw runtime, not by the agent. The agent sends its messages to the runtime. The runtime adds the API key and makes the call. The agent never sees the key.
This is the right abstraction. The agent should not be able to log the key, exfiltrate the key, or use the key to call APIs you did not intend. The runtime is the only place the key lives, and the runtime is a piece of code that you have audited and locked down.
If you are running a self-hosted model, the same principle applies. The model server should be a separate process, listening on a localhost-only port, with no external network access. The OpenClaw runtime is the only thing that talks to it. The agent does not have network access at all, so the agent cannot talk to the model server directly even if it wanted to.
Rate limit and budget cap the agent
A bug in your agent logic can cause it to enter a loop, calling the model repeatedly with no progress. Each call costs money. The loop can drain your API budget in hours. The fix is to set hard rate limits and budget caps at the runtime level, not at the agent level.
My current production settings:
- Maximum 60 model calls per session.
- Maximum $5 of API spend per session.
- Maximum 30 minutes of wall-clock time per session.
- Hard kill at any of those limits. No “are you sure you want to continue?” prompt. The session ends.
The first version of my agent did not have these limits. The first version also ate $240 in API credits in a single weekend because of a bug that caused it to retry the same web search 4,000 times. The limits are not optional. They are the difference between a tool and a liability.
Log everything, including the boring stuff
Every agent invocation should log:
- The session ID and the user who initiated it.
- The system prompt version and the HMAC signature.
- The model name and the temperature setting.
- The full message history at the end of the session.
- The tool calls and their outputs.
- The final cost in dollars and tokens.
This is a lot of data. It is also the data that lets you debug “why did the agent do that” three weeks after the fact. Store the logs in a system that supports structured queries (Loki, Elasticsearch, or just plain Postgres with JSONB columns), and write queries that catch the obvious bad patterns:
- Sessions that exceeded the budget cap.
- Sessions that called the same tool more than 10 times in a row.
- Sessions where the model output was longer than 50,000 tokens.
- Sessions where the agent tried to access a path outside its sandbox.
The queries run as alerts. The alerts page you. You investigate. The system gets safer with every alert.
What I would tell past me
Three things, in order of how much pain they would have saved:
- Sandbox the tools on day one. It is 30 minutes of work upfront and 30 hours of work to retrofit later. I retrofitted it later.
- Version the system prompt in git from the first commit. You will change it 20 times in the first month. You will want to know what changed.
- Set a budget cap before the first request hits the API. I learned this the $240 way.
Trade-offs
Hardening an OpenClaw deployment is real work. The Firejail profiles, the LXC containers, the HMAC-signed system prompts, the budget caps, the structured logging, the alert queries. None of it is intellectually interesting. All of it is required.
The alternative is to run an agent framework on the open internet with no sandbox, no rate limits, and no audit trail, and to hope that the prompt-injection attacks do not land. That works until it does not, and when it does not, the cost is the data the agent had access to, which is usually everything.
If you are deploying OpenClaw for a research project, the quickstart guide is fine. If you are deploying it for a real workload, the steps above are the minimum, not the maximum. Treat the agent as a junior employee with access to your production systems. Give it the access it needs, log what it does, and review the logs.