OpenClaw is powerful because it can actually do things. It can access email, calendars, files, browsers, APIs, messaging platforms, and other systems. That makes it useful, but it also means you are no longer securing a chatbot. You are securing an autonomous system with access, and that distinction matters.
If I were deploying OpenClaw today, I would approach it the same way I would approach any privileged system: assume compromise is possible, minimize trust, reduce the blast radius, and make every meaningful action observable. The goal is not to make the agent impossible to trick. The goal is to make sure that if the agent is tricked, the consequences are limited.
Start With Isolation
The first rule is simple: Do not give the agent direct access to your primary workstation or server environment unless there is an extremely good reason. I would run OpenClaw in a dedicated environment. That could be:
- a dedicated VM
- a hardened container host
- an isolated cloud instance
- a purpose-built sandbox
I would avoid running it directly on my everyday laptop, with access to my home directory, browser profiles, SSH keys, cloud credentials, and local application data. Think of the agent as a highly capable contractor: you would not normally give a new contractor unrestricted access to your entire laptop, and the same principle applies here.
Run With the Minimum Possible Privileges
The OpenClaw process should not run as root, and the container or virtual machine should have access only to the files and systems it actually needs. Avoid mounting large portions of the host filesystem. Instead of giving it:
/home/jd
give it something much narrower:
/agent-data/reports
If OpenClaw needs access to documents, give it a dedicated working directory. If it needs to write files, limit writes to specific locations. Where possible:
- use read-only mounts
- use non-root containers
- use read-only root filesystems
- disable unnecessary operating system capabilities
- restrict process execution
- limit CPU and memory
The security question should always be:
What is the minimum this agent needs in order to complete its job?
Treat Network Access as a Privilege
One of the biggest mistakes I would avoid is giving an autonomous agent unrestricted outbound internet access. If the agent only needs to communicate with:
- OpenAI
- Anthropic
- Google APIs
- GitHub
- a few internal services
then those should be the destinations it can reach, and everything else should be blocked by default. That gives you an important layer of protection against data exfiltration. Imagine a prompt injection successfully convinces the agent to upload sensitive information. If the destination is not an approved endpoint, the network layer should simply reject the connection. Egress filtering matters for agents because a secure architecture should assume the model might eventually try to communicate somewhere it should not.
Proposal
Keep Credentials Outside the Agent
This is one of the controls I consider most important. I would avoid placing reusable credentials directly inside the agent runtime, which means avoiding environments full of variables like:
AWS_SECRET_KEY
GOOGLE_TOKEN
GITHUB_TOKEN
SLACK_TOKEN
If the agent can read the credential, a compromised tool or successful prompt injection may be able to read it too. Instead, credentials should ideally live behind a broker. The agent requests an action, a policy layer decides whether the action is allowed, and the credential is injected at the boundary or exchanged for a short-lived token. The agent never sees the underlying secret.
If a credential has to exist inside the environment, I would keep it:
- narrowly scoped
- short-lived
- read-only where possible
- tied to a dedicated service account
- separate from personal or administrative identities
Never give an agent your global administrator account just because it makes setup easier. Convenience is not worth that blast radius.
Use Dedicated Service Accounts
Every external service should ideally have an identity specifically created for the agent. For example:
openclaw-google@example.com
openclaw-github
openclaw-slack
Those identities should have the minimum permissions required. This creates separation between what you can do and what the agent can do. If the agent account becomes compromised, you can revoke it without disabling your own identity. It also makes audit logs much easier to understand: instead of wondering whether you or the agent performed an action, you have a distinct principal.
Enable Sandboxing for Tool Execution
Tool execution is one of the highest-risk areas. Giving an LLM unrestricted shell access is essentially saying:
Interpret information from the internet and then execute commands on my computer.
That deserves some skepticism. Where possible, tools should run inside a sandbox. I would prefer:
- WASM-based execution
- isolated containers
- restricted shell environments
- dedicated browser sandboxes
In OpenClaw specifically, sandboxing is off by default, and when I turn it on only tool execution moves into the sandbox while the Gateway process stays on the host. The backends are container-based, Docker by default with Podman, SSH, and other options, and the OpenClaw sandboxing docs are candid that this is not a perfect security boundary, which is why the isolation controls above still matter. WASM-based execution is a general preference of mine rather than an OpenClaw backend today.
Tools should not automatically inherit access to the agent host. A command that needs to manipulate a file should only see the files required for that task, a browser automation tool should live in its own sandbox, and a third-party plugin should not automatically inherit every privilege of the main runtime.
Be Extremely Conservative With Plugins
Plugins expand functionality, and they also expand the trusted computing base. Every plugin should be treated like software you are installing on a privileged server. Before adding one, I would ask:
- Who maintains it?
- Is the source available?
- What permissions does it request?
- Does it execute inside the main process?
- Can it access secrets?
- Can it access the host filesystem?
- Can it initiate arbitrary network traffic?
- How quickly is it patched?
For OpenClaw, the answer to the in-process question is currently always yes: native plugins are TypeScript modules loaded in the Gateway process, and the plugin internals docs say plainly that they are not sandboxed and share the same trust boundary as core code. The isolation I want here is a requirement I hold plugin vendors to, not a setting I can flip today.
More capability is not always better. For an agent environment, fewer trusted components usually means a safer system.
Proposal
Use Human Approval for High-Risk Actions
Not every action needs approval, but certain categories should absolutely require it. Examples include:
- sending external email
- deleting files
- deleting messages
- changing cloud infrastructure
- modifying identity or security settings
- installing software
- making purchases
- transferring money
- accessing sensitive records
- publishing content publicly
Read operations can often operate with much more autonomy, while write operations deserve more scrutiny. A useful starting point is: Read automatically. Write carefully. Delete reluctantly.
OpenClaw does have approval prompts, with allow once, always allow here, and deny, plus typed scopes that summarize actions such as sending messages or making payments, but the exec approvals docs are clear that the default security mode for a gateway host is full access with prompts off. This control only exists if I switch it on deliberately.
Put Spending and Resource Limits Everywhere
Agents can create surprisingly large operational problems without anything technically being compromised. A loop can consume API credits, a browser agent can repeatedly purchase something, and a coding agent can create expensive cloud infrastructure. I would put limits on:
- API spend
- cloud spend
- transaction size
- number of API calls
- number of spawned agents
- execution time
- CPU and memory
- amount of data transferred
These limits function as circuit breakers. If the agent suddenly begins behaving very differently from normal, something should stop it before the behavior becomes expensive or destructive.
Log Everything Important
An autonomous system should be extremely observable. I would want records of:
- user requests
- agent actions
- tool invocations
- policy decisions
- credential requests
- network destinations
- files accessed
- external messages sent
- authentication events
- configuration changes
The goal is not to store every internal thought generated by a model. The goal is a reliable record of what the system actually did, so that if something goes wrong you can reconstruct the sequence of actions.
Build a Kill Switch
You need a way to immediately disable the agent. One action should be able to:
- stop execution
- disable tool access
- revoke credentials
- terminate network access
- prevent new jobs
- preserve logs
Do not design incident response around logging into five different SaaS platforms to revoke tokens manually. Assume that someday you will need to isolate the agent quickly, and design for that day.
Proposal
My Baseline Architecture
For a serious deployment, my preferred design would look something like:
OpenClaw remains useful, but it is surrounded by controls. That distinction is important.
Synthesis
The Core Principle
I do not think secure deployment means believing that OpenClaw will never make a mistake. The more realistic goal is:
Assume the agent will eventually make a bad decision and architect the environment so that decision has a limited blast radius.
Isolation, least privilege, credential separation, network control, auditing, human escalation: those are not new security ideas. What is new is the thing we are applying them to. As agents become more capable, they will increasingly deserve the same scrutiny we apply to privileged users, servers, workloads, and service accounts.
OpenClaw can absolutely be useful, but usefulness should not be confused with trust. Trust should be engineered.