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

91–100 of 374 posts

Re: Go hard on agents, not on your filesystem

#91

Post by bigstrat2003 »

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 am too. It is genuinely really stupid to run these things with access to your system, sandbox or no sandbox. But the glaring security and reliability issues get ignored because people can't help but chase the short term gains.

Re: Go hard on agents, not on your filesystem

#92

Post by bigstrat2003 »

vardalab wrote: post #36
mazieres wrote: post #2

What would it take for people to stop recklessly running unconstrained AI agents on machines they actually care about? A Stanford researcher thinks the answer is a new lightweight Linux container system that you don't have to configure or think about.

unconstrained AI agents are what makes it so useful though. I have been using claude for almost a year now and the biggest unlock was to stop being a worrywart early on and just literally giving it ssh keys and telling it to fix something. ofc I have backups and do run it in VM but in that VM it helps me manage by infra and i have a decent size homelab that would be no fun but a chore without this assistant.

> unconstrained AI agents are what makes it so useful though

Not remotely worth it.

Re: Go hard on agents, not on your filesystem

#94

Post by culopatin »

fc417fc802 wrote: post #79
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.

People were also dismissing concerns about build tooling automatically pulling in an entire swarm of dependencies and now here we are in the middle of a repetitive string of high profile developer supply chain compromises. Short term thinking seems to dominate even groups of people that are objectively smarter and better educated than average.

If anything I feel more in control of these agents than the millions of LOC npm or pip pull in to just show me a hello world

Re: Go hard on agents, not on your filesystem

#95

Post by giancarlostoro »

mazieres wrote: post #57
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'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.

Re: Go hard on agents, not on your filesystem

#97

Post by xbar »

barishnamazov wrote: post #66
ray_v wrote: post #41

I'm wondering if the obvious (and stated) fact that the site was vibe-coded - detracts from the fact that this tool was hand written. > jai itself was hand implemented by a Stanford computer science professor with decades of C++ and Unix/linux experience. ( https://jai.scs.stanford.edu/faq.html#was-jai-written-by-an-... )

Sigh, I'd still have preferred a basic HTML page with hand-written succinct information instead of this crap verbosity.

There is a man page.

Re: Go hard on agents, not on your filesystem

#99

Post by mazieres »

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.

Also, a lot of people use multiple harnesses. I'm often switching between claude, codex, and opencode. It's kind of nice to have the sandbox policy independent of the actual AI assistant you are running.

Re: Go hard on agents, not on your filesystem

#100

Post by ihattendorf »

fc417fc802 wrote: post #80
enduser wrote: post #46

Earlier quoted context omitted.

By default it will automatically retry many tool calls that fail due to the sandbox with the sandbox disabled. In other words it can and will leave the sandbox. For example: Bash(swift build 2>&1 | tail -20) ⎿ warning: /Users/enduser/Library/org.swift.swiftpm/configuration is not accessible or not writable, disabling user-level cache features. warning: /Users/enduser/Library/org.swift.swiftpm/security is not accessib…

What is even the point in that case? The behavior you describe is no better than if SELinux were to automatically re-execute a process with containment disabled.

The purpose of the sandbox is to reduce permission fatigue. If it fails to run a command in the sandbox and retries it outside the sandbox, the regular permission rules apply. You'll still be prompted for any non-sandboxed tool calls that you haven't allowed or denied via permission rules.
Post reply on HN