I don’t understand how “running it in a vm” Or a docker image, prevents the majority of problems. It’s an agent interacting with your bank, your calendar, your email, your home security system, and every subscription you have - DoorDash, Spotify, Netflix, etc. maybe your BTC wallet.

What protection is offered by running it in a docker container? Ok, It won’t overwrite local files. Is that the major concern?

Read my second paragraph.

It’s a matter of giving the system shims instead of direct access to “write” ops. Those shims have controls in place. Their only job is to examine the context and decide whether the (email|purchase|etx) is acceptable, either by static rules, human intervention, or, if you’re really getting spicy. separate-llm-model-that-isn’t-polluted-by-untrusted-data.

Edit: I actually wrote such a thing over the weekend as a toy PoC. It uses the LLM to generate a list of proposed operations, then you use a separate tool to iterate though them and approve/reject/skip each one. The only thing the LLM can do is suggest things from a modest set of capabilities with a fairly locked-down schema. Even if I were to automate the approvals, it’s far from able to run amok.

> computer nerds understand

No, literally no one understands how to solve this. The only option that actually works is to isolate it to a degree that removes the "clawness" from it, and that's the opposite of what people are doing with these things.

Specifically, you cannot guard an LLM with another LLM.

The only thing I've seen with any realism to it is the variables, capabilities and taint tracking in CaMeL, but again that limits what the system can do and requires elaborate configuration. And you can't trust a tainted LLM to configure itself.

https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

https://simonwillison.net/2025/Jun/13/prompt-injection-desig...

https://simonwillison.net/2025/Apr/11/camel/

If the “clawness” means you only use the llm to control itself, then yes, that’s impossible. But you can easily shim such a process so that the interfaces it uses to “claw out” to the real world are shims that have safeties such as human control. Openclaw does not do this, and is thus a scary shit show, but you can play with it in isolation safely, and I think a standard pattern for good control will emerge.

> easily

Yeah that's an active research topic for teams of PhDs, including some of Google's brightest. And the current approach even with added barriers may just be fundamentally untrustable. Read the links from my earlier comment for background.

If the shim doesn’t use an LLM to make its decisions this is not a problem.

If the shim does use an LLM but no uncontrolled data is allowed in, this is not a problem.

I think you're misunderstanding the severity of the lethal trifecta. Just because you put access controls around the LLM doesn't mean all that much if the access controls allow anything in & out. There is no way to write a shim that blocks "everything naughty", while remaining useful.

You literally have to fully prevent all outside input, or you have to prevent all exfiltration routes including web page reading (even the choice of links to follow is an exfiltration mechanism). At that point, what's left? What do you think will be on your allowlist?

I seriously doubt the early adopters of these software bundles use their assistants like with such restraint (https://xcancel.com/summeryue0/status/2025774069124399363), and that idealized image of these access control shims is not realistic.

Your definition of “remaining useful” seems to require a lot more than mine. An email shim, for example could have destination whitelists, rate limits, an overall message quota, and can have its contents driven by fixed templates which the LLM can choose from, but not inject arbitrary data into. The point is that your claw need not have “do anything” powers, it needs to have extremely constrained powers. Maybe that is, as you say, “not a claw.” In fact, mine calls itself a “clav” because it’s almost a claw, but not quite.