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

261–270 of 374 posts

Re: Go hard on agents, not on your filesystem

#261

Post by Bender »

I would have to be very inebriated to give a bot/agent access to my files and all security clearance should be revoked but should I do that it would have to be under mandatory access controls that my unprivileged user has no influence over, not even with sudo or doas. The LSM enforced rules (SELinux, AppArmor, TOMOYO, other newer or simpler LSM's) would restrict all by default and give explicit read, write, execute permissions to specific files or directories.

The bot should also be instructed that it gets 3 strikes before being removed meaning it should generate a report of what it believes it wants to access to and gets verbal approval or denial. That should not be so difficult with today's bots. If it wants to act like a human then it gets simple rules like a human. Ask the human operator for permission. If the bot starts "doing it's own thing, aka going rogue" then it gets punished. Perhaps another bot needs to act as a dominatrix to be a watcher over the assistant bot.

Re: Go hard on agents, not on your filesystem

#262

Post by 9wzYQbTYsAIc »

mentalgear wrote: post #202
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.

I'm now considering installing QubesOS for all dev work to absolutely ensure all coding agents run in secure separate sandboxes together without any OS level exposure.

Phew, just get the Qubes to spin up on demand with each agent and that could be pretty neat.

Re: Go hard on agents, not on your filesystem

#263

Post by rienbdj »

ethanwillis wrote: post #190
throwaway2027 wrote: post #185

Earlier quoted context omitted.

All of which is useless when it just starts using big blocks of python instead. You need filesystem sandboxing for the python interpreter too.

What we need is a capabilities based security system. It could write all the python, asm, whatever it wants and it wouldn't matter at all if it was never given a reference to use something it shouldn't.

Docker is enough in practice no?

Re: Go hard on agents, not on your filesystem

#264

Post by adi_kurian »

gck1 wrote: post #104

It's full VM or nothing. I want AI to have full and unrestricted access to the OS. I don't want to babysit it and approve every command. Everything that is on that VM is a fair game and the VM image is backed up regularly from outside. This is the only way.

I have a pretty insane thing where I patched the screen sharing binary and hand rolled a dummy MDN so I can have multiple profiles logged in at once on my Mac Studio. Then have screen share of diff profiles in diff "windows". Was for some ML data gathering / CV training.

It's pretty neat, screen sharing app is extremely high quality these days, I can barely notice a diff unless watching video. Almost feels like Firefox containers at OS level.

Have thought that could be a pretty efficient way to have restricted unrestricted convenient AI access. Maybe I'll get around to that one day.

Re: Go hard on agents, not on your filesystem

#265

Post by hiq »

Is there already some more established setup to do "secure" development with agents, as in, realistically no chance it would compromise the host machine?

E.g. if I have a VM to which I grant only access to a folder with some code (let's say open-source, and I don't care if it leaks) and to the Internet, if I do my agent-assistant coding within it, it will only have my agent credentials it can leak. Then I can do git operations with my credentials outside of the VM.

Is there a more convenient setup than this, which gives me similar security guarantees? Does it come with the paid offerings of the top providers? Or is this still something I'd have to set up separately?

Re: Go hard on agents, not on your filesystem

#266

Post by lemontheme »

faeyanpiraat wrote: post #173
lemontheme wrote: post #164

And for the macos users, I can’t recommend nono enough. (Paying it forward, since it was here on HN that I learned about it.) Good DX, straightforward permissions system, starts up instantly. Just remember to disable CC’s auto-updater if that’s what you’re using. My sandbox ranking: nono > lima > containers.

I've just switched to lima, and cant find anything about "nono" can you post a link?

I really like lima too. It's my go-to recommendation for light VMs. But I do consider it slightly less convenient.

A good example of why is project-local .venv/ directories, which are the default with uv. With Lima, what happens is that macOS package builds get mounted into a Linux system, with potential incompatibility issues. Run uv sync inside the VM and now things are invalid on the macOS side. I wasn't able to find a way to mount the CWD except for certain subdirectories.

Another example is network filtering. Lima (understandably) doesn't offer anything here. You can set up a firewall inside the VM, but there's no guarantee your agent won't find a way to touch those rules. You can set it up outside the VM, but then you're also proxying through a MITM.

So, for the use case of running Claude Code in --dangerously-skip-permissions mode, Lima is more hassle than Nono

Re: Go hard on agents, not on your filesystem

#267

Post by hiq »

rsyring wrote: post #42

I've been reviewing Agent sandboxing solutions recently and it occurred to me there is a gaping vector for persistent exploits for tools that let the agent write to the project directory. Like this one does. I had originally thought this would ok as we could review everything in the git diff. But, it later occurred to me that there are all kinds of files that the agent could write to that I'd end up executing, as the…

I don't follow why you'd run uncommitted non-reviewed code outside of the sandbox (by sandbox I'm meaning something as secure as a VM) you use. My mental model is more that you no longer compile / run code outside of the sandbox, it contains everything, then when a change is ready you ship it after a proper review.

The way I'd do it right now:

* git worktree to have a specific folder with a specific branch to which the agent has access (with the .git in another folder)

* have some proper review before moving the commits there into another branch, committing from outside the sandbox

* run code from this review-protected branch if needed

Ideally, within the sandbox, the agent can go nuts to run tests, do visual inspections e.g. with web dev, maybe run a demo for me to see.

Re: Go hard on agents, not on your filesystem

#268

Post by tempaccount5050 »

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.

I don't understand why file and folder permissions are such a mystery. Just... don't let it clobber things it shouldn't.

Re: Go hard on agents, not on your filesystem

#269

Post by RALaBarge »

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.

You do also have to worry about exec and other neat ways to probably get around stuff. You could also spin up YAD (yet another docker) and run Claude in there with your git cloned into it and beyond some state-level-actor escapes it should cover 99% of your most basic failures.

Re: Go hard on agents, not on your filesystem

#270

Post by michaelcampbell »

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.

> 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.

These are generally (but not always) 2 different sets of people.

Post reply on HN