Where OpenClaw Security Is Heading

I run a home-grown 'Agent' by just making a local user on my linux box. I treat it like an untrusted local user, I only give it scoped API keys, and manage permissions just like any other thing. I have a NixOS machine and I have the Agent setup to just use home-manager to manage itself and its timers and deps and stuff inside its own config.

It would be insane to run a full fledged Agent from your own accounts, with the same access as yourself. At the same time running it fully scoped inside a container/VM seemed a little bit too heavy handed to me and the Agent-as-user seems like a better fit for me right now. (I did run my coding agents inside a microVM for a while but ran into a few too many annoyances)

Agents are fundamentally insecure, there’s no getting around it. You can put OpenClaw in a box but for it to do anything useful it still needs some access to the outside world, and any untrusted tokens that go into its context are a threat.

Claude’s auto mode classifier is probably the best ‘firewall’ out there right now, but it’s a non deterministic layer with a failure rate of 17%.

I know it's probably against the guidelines to comment on it, but any chance you could ask whatever agent is responsible to remove the scroll highjacking? It makes it incredibly tedious to read this article.

What is happening in the first screenshot under "Command approvals and prompt fatigue"?

Why is "Allow Once" completely red, "Always allow" is black and "Deny" is muted red? Isn't the order of safety (descending) "Deny", "Allow Once" and "Always Allow"?

Isn't a lot of this what containerization was supposed to solve? Why are they reimplementing file system isolation from scratch when jails and chroots exist? Why do they have to reason about arbitrary HTTP requests when firewalls and content filtering exist?

[dead]

[dead]