This HackerNews comment really hits home some thinking I've been having recently:

Am I missing something? Why is everyone talking about sandboxes when it comes to OpenClaw?
To me it's like giving your dog a stack of important documents, then being worried he might eat them, so you put the dog in a crate, together with the documents.
I thought the whole problem with that idea was that in order for the agent to be useful, you have to connect it to your calendar, your e-mail provider and other services so it can do stuff on your behalf, but also creating chaos and destruction.

Inherently, there is no real security model for Openclaw. There is an agent that can do whatever with a set of credentials in a Mac mini. It can leak those credentials, sell them on the dark web, or edit its own SOUL.md. 

So what should the response be? 

Personalized AI agents certainly have the potential to amplify your entire enterprise, but we shouldn't allow only those willing to forgo all sense of security to reap the benefits. The proper way is to have all governance and controls in place for agents so that you don't have to take security shortcuts to adopt powerful agents. 

Now that we've drawn the picture of what doesn't work, what does the picture of what does work look like?

It looks more complicated than Openclaw in a box. Let me explain why that complexity is fundamental.

Gateway

The entire architecture pictured above is structured around having this gateway component. It's the keystone that everything else builds upon. 

The gateway boils down to having a single choke point for all agentic access to external systems and information. It allows you to have full observability into what your agents are doing, meaning you can record every tool call and LLM invocation, enabling you to stitch back together why a loan was approved or who authored the prompt that pushed new code to production. A gateway is also a centralized place for enforcing rate limits and applying guardrails. 

This is where the kill switch goes to turn off a rogue agent leaking your Salesforce customer data. No need to hunt down API access for 27 different services and systems, just turn it off for a single service or set of services for your entire digital workforce at once.

Audit log and transcripts

You want to know why and how the agent did a thing, not just what it did. Transcripts give you the ability to not only govern the actions and tools your agents have, but also enable agentic performance reviews. You can run different versions of agents, for example, giving similar agents different sets of tools to accomplish a job, then monitor and compare their performance. 

Full transcripts capture inputs, outputs, tool calls, token usage, and the agent's reasoning chain. Explicit guardrails allow you to act on a single agent's request or response. Transcripts allow you to correlate what's going on in a multi-agent system or track regressions over time. Without them, you're flying blind.

Token vault

Don't give the dog your keys.

When Openclaw connects to your calendar or Salesforce, it holds credentials. Probably in a config file. Probably with more permissions than it actually needs. That's the dog with your documents. The sandbox doesn't help because the credentials are already inside it.

A token vault handles credentials out-of-band. The agent never holds your Salesforce token directly. When it needs to take an action, the gateway requests a short-lived, scoped token from the vault for exactly that operation. 

This also unlocks patterns that are otherwise impossible. Many enterprise systems—Salesforce, ServiceNow—don't support service accounts at all. They only support user-based auth. On-Behalf-Of (OBO) flows through a token vault, allowing an agent to act in the context of a real user, with that user's actual permissions, without ever directly holding their credentials. You can't build a real multi-tenant agent without this.

Sandboxed compute and storage

Sandboxes are right. You give all your human workforce computers after all. Giving agents computational power to achieve their goals is one of the key capabilities to how Claude Code has taken over software development. It's well known how much more efficient LLMs are at deriving insights when they can post process tool output with standard Unix commands, and sandboxes are the best way to safely enable this. 

However, these sandboxes need to have very limited network access so that they can only go through the gateway. This allows the gateway to mediate all interactions with the public world (just like with a limited set of tools you can give an agent without a sandbox). 

Additionally, it is imperative that authentication is passed via out-of-band metadata associated with the agent's identity. This allows the agent to perform exactly the actions it needs through the gateway, only during that session. We at Redpanda have a demonstration of this using our "agentic gateway interface" or agi CLI (yes, the name is a play on that AGI) to allow the agent to invoke our AI gateway from within the sandbox, this way. Here's the demo:

‍

We use a dynamic, self-describing CLI to mediate access to external tools. This provides an interface for agents to discover and invoke services outside the sandbox, fitting cleanly into the composable Unix workflow while keeping all communication strictly governed by the gateway.

Don’t give the dog your documents  

It’s fair to say that Openclaw has been wildly successful. If you're a developer running it on a dedicated machine with limited access and scope, the threat model is manageable. You're not running it on company cloud infrastructure. You're not giving it access to production systems. The documents and the dog are both yours.

The problem shows up when organizations try to scale that model. When the IT team decides "just run it in a VM" for each department. When someone decides the sandbox is sufficient governance for production use. It isn't. The threat model is completely different at that point. It's critical that authentication and access keys are passed as out-of-band metadata. The agent can't leak or abuse what it can't see.

Gateway + Audit trail + Token vault + Sandboxed compute = Agents in production.

That's the minimum required to give anyone (developer, security team, CIO, etc) actual control over their agents. Once you have it, you stop worrying about the dog, because you stopped giving it your documents in the first place.

If you're curious, read our blog on Redpanda Agentic Data Plane to see what we're doing to help you get your security (and agents) in line.