So, you want to run OpenClaw?

OpenClaw, the open-source agent formerly known as Clawdbot (...and, more recently, Moltbot) has become a phenomenon. And it’s not just a target of attention in tech circles, with the reddit-like Moltbook site featuring in the mainstream press globally. People are clearly excited and it appears they’re getting value from it.

However, there are significant security concerns. That’s why, at Thoughtworks, we’ve restricted it on our managed systems; it's permission-hungry by nature and we need to protect our data. 

However, if Open Claw-like agents are really as productive as advocates claim they are, it’s difficult to see this position as one that can be maintained indefinitely. With that in mind, let's look at what "as safely as possible" actually looks like right now, and what trade-offs you're making when you do adopt this kind of agent.

Why OpenClaw has taken off

OpenClaw started as a WhatsApp integration — connecting a coding agent to what's essentially a more accessible channel. From there, it grew an open plugin architecture for everything from email to calendar to web browsing. What it's doing is exposing the powerful agentic loop of a coding agent to a much broader range of use cases.

Credit to the creator: OpenClaw is a sophisticated technology delivered in a way that’s appealing, flexible and relatively easy to get started with. However, as with many technologies that access a lot of data and can perform risky functions, there’s a security trade-off. 

The trade-off you can’t sandbox away

This is nothing new. There has always been a direct trade-off between accessibility and security. By providing more access to data and sensitive actions to an agent, you create novel security risks. That's not a bug to be fixed; it's the fundamental tension. You have to acknowledge this trade-off before you can make informed decisions about where to draw the line.

A frequent question I hear is: can I simply put it in a sandbox? The honest answer is that there’s no magic sandbox where this trade-off disappears. Sandboxing is merely a choice of where to draw the line between what you’re happy for an agent to access and what you are happy for an agent to lose.

This vulnerability is best understood through the lens of what Simon Willison calls the "lethal trifecta" for AI agents: untrusted input, sensitive data and external communication. If an agent has all three, prompt injection and data exfiltration aren't edge cases, but instead a likely outcome. 

As Martin recently wrote this week (February 17), email is the canonical example: it contains untrusted content from strangers, sensitive information and is itself a channel for external communication. Grant an agent read/write access to your inbox and you have satisfied the trifecta completely. (For a deeper treatment of this model and practical mitigations, see Korny Sietsma's Agentic AI and Security on Martin Fowler’s website).

The limits of isolation

While there is no proven safe way to run high-permissioned agents today, there are practical patterns that reduce the blast radius. If you want to experiment, you have options, such as cloud VMs or local micro-VM tools like Gondolin. 

Technologists looking to experiment should consider the following steps:

• Prioritize isolation first. Do not run these agents on corporate endpoints. Use a dedicated cloud VM, a separate machine, or at minimum a separate OS user account. Treat the host environment as disposable and assume it will be compromised. 

• Clamp down on network egress. This is the most underrated control for agent safety. Whether using a cloud proxy or local tools, enforce strict allowlists. If the agent can talk to the open internet, it can exfiltrate data. Be explicit about which domains are necessary and block everything else.

• Don’t expose the control plane. Open Claw has a websocket it exposes for control (port 18789). Anyone with access to this can control your instance and inherit any permission that it has. Bind it to localhost on your VM or container, put it behind authentication and if you need remote access, use a VPN or SSH tunnel rather than exposing the port.

• Treat secrets as toxic waste. Utilize short-lived tokens with tight scopes. If possible, use a secret injection pattern where the agent never possesses the actual credential string. If the agent doesn't hold the real key, it cannot easily reveal it in a chat log or external request. Gondolin is particularly notable for its secret injection capability, where the VM only sees placeholders for API keys, swapping in real credentials only at the network boundary.

• Assume the skills ecosystem is hostile. The OpenClaw plugin architecture is powerful, but it introduces supply chain risk. Treat third-party skills like any other unverified dependency: install only from trusted sources, pin versions and review the code. If a skill isn't strictly necessary, do not install it.

• Run endpoint protection. If an attacker leverages an agent to execute code, their first objective is usually persistence. Run standard anti-malware and endpoint protection on the host, keep it updated and monitor for alerts. Agent security creates a greater need for endpoint security, not a lesser one.

Following these steps can help make your experimentation safer. However, even with strong isolation, you are still making trade-off decisions. Every domain you allowlist for the agent to function is a potential exfiltration path.The containment is only as good as the holes you deliberately poke in it. Lock it down too far and the agent can't do anything useful.

Beyond protection: The need for detection

The conversation around AI agents is currently focused almost entirely on protection — how to apply access control and containment. However, if you want these agents to do genuinely useful work, sandboxing alone isn't sufficient. The most interesting applications will require real permissions, such as access to real data and the ability to interact with real external services. You can sandbox your way to safe experimentation, but you cannot sandbox your way to agents that actually do things in the real world.

So a residual risk will always remain if the agent is doing anything valuable. Which means we need to shift toward detect and respond. If we want to capture the value of these tools, we must accept they will have real permissions. The security challenge then becomes building the capability to observe what the agent is doing and intervene when behavior deviates from the norm.

Future security architectures for agents will likely resemble a "actitive defense" approach, where raw telemetry is captured and analyzed in real time to build detection and response capabilities around highly-permissioned agents. 

Where we are today

That said, we're still in the early days. The tooling for agent observability isn't mature, the patterns aren't proven and the telemetry standards are still emerging. For now, the most important advice is the simplest: don't connect these agents to sensitive data or high-stakes operations. The lethal trifecta is an architectural reality. Until detection and response capabilities mature, or we find some other security solutions to the problem, the safest posture is to keep the blast radius small.

So the advice for now is by all means experiment, but give careful thought to how you sandbox your agent. As these agents become more capable and integrated the temptation will grow to give them free access to your data and organization. But the responsible thing to do right now (in February 2026) is to wait for security architecture to catch up.