[delayed]

Agreed, sandboxing is only part of agent security. Authorization (what data the agent can access and what tools it can execute) is also a big part of it.

I've found primer on agent sandboxes [0] is a great reference on sandboxing options and the trade-offs

For agents there's a tension between level of restriction and utility. I think a large part of OpenClaw's popularity is that the lack of restriction by default has helped people see the potential utility of agents. But any agent that isn't just for trying things out requires consideration of what it should and should not be able to do and from there the decision around the best combination of sandboxing and authorization.

At work, we've found it helpful to distinguish coding agents vs product agents. Coding agents have the ability to add new execution paths by pulling in external code or writing their own code to run. Product agents have a strictly defined set of tools and the runtime prevents them from executing anything beyond that definition. This distinction helps us reason about what sandboxing is required.

For data permissions it's trickier. MCP uses OAuth for authentication but each server can have different expectations for access to the external service. Some servers let you use a service account where you can narrow the scope of access but others assume a token minted from an admin account which means the MCP server might have access to things beyond what the agent using the server should.

So for that, we have an MCP proxy that lets us define custom permissions for every tool and resource, and at runtime makes permission checks to ensure the agent only gets access to the subset of things we define ahead of time. (We're using SpiceDB to implement the authorization logic and checks) This works well for product agents because they can't add new execution paths. For coding agents, we've tinkered with plugins/skills to try to do the same but ultimately they can build their way around authorization layers that aren't part of the runtime system so it's something we're still trying to figure out.

---

[0] https://www.luiscardoso.dev/blog/sandboxes-for-ai

Reminds me of https://xkcd.com/1200/

Should anyone think the comment is dismissive, here's this directly in the text:

> a respected public relations firm that often works with tech businesses covered by VentureBeat

Exactly this.

The whole wording also doesn't make sense.

OpenClaw was released in November of 2025, yet the article sounds like NanoClaw _disrupts_ some old staple of the industry.

You can't use that wording 4 months into the whole "industry". Even less so, when your competitor was "launched" 2 weeks ago. Even less so when it's written by claude

This nothingburger is so much nothing, it might as well be an antiburger.

It is not immune, but it limits #1 and #2.

The "lethal trifecta" is a limited view on security, as it's mostly concerned with leaking data. This solution focuses on a different aspect: the ability of rogue actions (instead of rogue communications per #3).

Prompt injection just seems unsolvable.

Are there works toward preventing it 100% of the time ? (I would assume the LLMs architectures would have to change)

This is cutting off the "Access to private data" leg of the lethal trifecta. One of the few ways to actually make an agent secure.

To their credit they put a single sentence of warning into the article they commissioned, but to highlight:

- I don't care deeply about this code.

- (This isn’t) production code but a reference or starting point they can use to build functional custom software for themselves.

- I spent a weekend giving instructions to coding agents to build this.

9 days ago