Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go hard on agents, not on your filesystem

jai.scs.stanford.edu

Post reply on HN
Print view View original

221–230 of 374 posts

Re: Go hard on agents, not on your filesystem

#221

Post by lxgr »

puttycat wrote: post #75

I am still amazed that people so easily accepted installing these agents on private machines. We've been securing our systems in all ways possible for decades and then one day just said: oh hello unpredictable, unreliable, Turing-complete software that can exfiltrate and corrupt data in infinite unknown ways -- here's the keys, go wild.

Not in unknown ways, but as part of its regular operation (with cloud inference)!

I think the actual data flow here is really hard to grasp for many users: Sandboxing helps with limiting the blast radius of the agent itself, but the agent itself is, from a data privacy perspective, best visualized as living inside the cloud and remote-operating your computer/sandbox, not as an entity that can be "jailed" and as such "prevented from running off with your data".

The inference provider gets the data the instant the agent looks at it to consider its next steps, even if the next step is to do nothing with it because it contains highly sensitive information.

Re: Go hard on agents, not on your filesystem

#223

Post by lxgr »

giancarlostoro wrote: post #95
mazieres wrote: post #57

Earlier quoted context omitted.

I've seen claude get confused about what directory it's in. And of course I've seen claude run rm -rf *. Fortunately not both at the same time for me, but not hard to imagine. The claude sandbox is a good idea, but to be effective it would need to be implemented at a very low level and enforced on all programs that claude launches. Also, claude itself is an enormous program that is mostly developed by AI. So to have…

In my opinion Claude should be shipped by a custom implementation of "rm" that Anthropic can add guardrails to. Same with "find" surprised they don't just embed ripgrep (what VS Code does). It's really surprising they don't just tweak what Claude uses and lock it down to where it cannot be harmful. Ensure it only ever calls tooling Claude Code provides.

> a custom implementation of "rm" that Anthropic can add guardrails to

Wrong layer. You want the deletion to actually be impossible from a privilege perspective, not be made practically harder to the entity that shouldn't delete something.

Claude definitely knows how to reimplement `rm`.

Re: Go hard on agents, not on your filesystem

#224

Post by cogogo »

d1sxeyes wrote: post #128
oefrha wrote: post #120

Earlier quoted context omitted.

You can define your own rm shell alias/function and it will use that. I also have cp/mv aliases that forces -i to avoid accidental clobbering and it confuses Claude to no end (it uses cp/mv rare enough—rarer than it should, really—that I don’t bother wasting memory tokens on it).

I did this, Claude detected it and decided to run /bin/rm directly.

This is terrifying. I have not used agents because I do not have a sandbox machine I do not care about. Am I crazy to worry about a sandboxed agent running on my home network? Anyone experienced anything weird by doing that?

Re: Go hard on agents, not on your filesystem

#225

Post by lxgr »

esperent wrote: post #73
mazieres wrote: post #57

Earlier quoted context omitted.

I've seen claude get confused about what directory it's in. And of course I've seen claude run rm -rf *. Fortunately not both at the same time for me, but not hard to imagine. The claude sandbox is a good idea, but to be effective it would need to be implemented at a very low level and enforced on all programs that claude launches. Also, claude itself is an enormous program that is mostly developed by AI. So to have…

I added a hook to disable rm, find - delete, and a few of the other more obvious destructive ops. It sends Claude a strongly worded message: "STOP IMMEDIATELY. DO NOT TRY TO FIND WORKAROUNDS...". It works well. Git rm is still allowed.

It works well so far, for you.

Are you confident it would still work against sophisticated prompt injection attacks that override your "strongly worded message"?

Strongly worded signs can be great for safety (actual mechanisms preventing undesirable actions from being taken are still much better), but are essentially meaningless for security.

Re: Go hard on agents, not on your filesystem

#226

Post by lxgr »

safety1st wrote: post #149
PaulDavisThe1st wrote: post #60

Earlier quoted context omitted.

On Linux, chroot(2) is hard to escape and would apply to all child processes without modification.

We anthropomorphize these agents in every other way. Why aren't we using plain ol' unix user accounts to sandbox them? They look a lot like daemons to me, they're a program that you want hanging around ready to respond, and maybe act autonomously through cron jobs are similar. You want to assign any number of permissions to them, you don't want them to have access to root or necessarily any of your personal files. It…

> for some reason they want it to live under your user account

The entire idea of Openclaw (i.e., the core point of what distinguishes it from agents like Claude Code) is to give it access to your personal data, so it can act as your assistant.

If you only need a coding agent, Openclaw is the completely wrong tool. (As a side note, after using it for a few weeks, I'm not convinced it's the right tool for anything, but that's a different story.)

Re: Go hard on agents, not on your filesystem

#227

Post by lxgr »

brianush1 wrote: post #68
shakna wrote: post #63

Earlier quoted context omitted.

chroot is not a security sandbox. It is not a jail. Escaping it is something that does not take too much effort. If you have ptrace, you can escape without privileges.

claude is stupid but not malicious; chroot is sufficient

Until it gets prompt injected. Are you reading every single file your agent reads as part of the tasks you give it, including content fetched from the web or third-party packages?

Re: Go hard on agents, not on your filesystem

#228

Post by reader_1000 »

AnotherGoodName wrote: post #15

Add this to .claude/settings.json: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } You can change the read part if you're ok with it reading outside. This feature was only added 10 days ago fwiw but it's great and pretty much this.

For some reason, this made everything worse for me. Now claude constantly tries to access my home folder instead of current directory. Obviously this is not still good enough. Also Claude keeps dismissing my instructions on not to read my home directory and use current directory. Weird.

Re: Go hard on agents, not on your filesystem

#229

Post by sanitycheck »

lll-o-lll wrote: post #160
sanitycheck wrote: post #133

Earlier quoted context omitted.

So don't let them interact with anything external. You can push and pull to their git project folders over the local filesystem or network, they don't even need access to a remote.

Unless you are talking about running a local model, that’s not possible.

Obviously if you're running Claude Code you need a token for that and an internet connection, that's kind of a given. What I'm talking about is permission (OS level, not a leaky sandbox) to access the user's files, environment variables, project credentials for git remotes, signing keys, etc etc.

Re: Go hard on agents, not on your filesystem

#230

Post by oefrha »

cogogo wrote: post #224
d1sxeyes wrote: post #128

Earlier quoted context omitted.

I did this, Claude detected it and decided to run /bin/rm directly.

This is terrifying. I have not used agents because I do not have a sandbox machine I do not care about. Am I crazy to worry about a sandboxed agent running on my home network? Anyone experienced anything weird by doing that?

Don’t dangerously skip permissions and actually read commands when you get prompted and you’re fine.
Post reply on HN