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

311–320 of 374 posts

Re: Go hard on agents, not on your filesystem

#311

Post by ma2kx »

Its a bit annoying that there are so many solutions to run agents and sandbox them but no established best practice. It would be nice to have some high level orchestration tools like docker / podman where you can configure how e.g. claude code, opencode, codex, openclaw run in open Shell, OCI container, jai etc.

Especially because everybody can ask chatgpt/claude how to run some agents without any further knowledge I feel we should handle it more like we are handling encryption where the advice is to use established libraries and don't implement those algorithms by yourself.

Re: Go hard on agents, not on your filesystem

#312

Post by [deleted] »

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

[deleted]

Re: Go hard on agents, not on your filesystem

#313

Post by timeinput »

mazieres wrote: post #65
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-... )

Human author here. The fact that I don't know web design shouldn't detract from my expertise in operating systems. I wrote the software and the man page, and those are what really matter for security. The web site is... let's say not in a million years what I would have imagined for a little CLI sandboxing tool. I literally laughed out loud when claude pooped it out, but decided to keep, in part ironically but also s…

I've been building my own tooling doing similar sorts of things -- poorly with scripts and podman / buildkit as well as LD_PRELOAD related tools, and definitely clicked over to HN comments with out reading much of the content because I thought "AI slop tool", and the site raised all my hackles as I thought I'll never touch this thing. It'll be easier to write my own than review yet another AI slop tool written by someone who loves AI.

I'm glad I read the HN comments, now I'm excited to review the source.

Thanks for your hard work.

ETA: I like your option parser

Re: Go hard on agents, not on your filesystem

#314

Post by zadikian »

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

Doesn't detract from it. The jai tool is high-stakes, the static website isn't. The tool is designed to be used with LLM coding agents, so if anything it makes sense to vibecode the website, even better if the author used jai in that.

Re: Go hard on agents, not on your filesystem

#315

Post by js2 »

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.

Disable sandbox escape:

https://news.ycombinator.com/item?id=47552165

Re: Go hard on agents, not on your filesystem

#316

Post by mehdibl »

Docker is hard to setup. The author made a nice solution but not sure if he know devcontainer and what he can do. You do the setup once and you roll in most dev tools. I'm still surprised the effort people put in such solution ignore the dev's core requirements, like sharing the env they use in a simple way. You used it to have custom env and isolate the agent. You want to persist your credentials? Mount the target folder from home or sl into a sub folder. Might be knowledge. But for Linux or even Windows/Mac as long you don't need desktop fully. Devcontainer is simple. A standard that works. And it's very mature.

Re: Go hard on agents, not on your filesystem

#317

Post by otterley »

"jai is free software, brought to you by the Stanford Secure Computer Systems research group and the Future of Digital Currency Initiative"

I guess the "Future of Digital Currency Initiative" had to pivot to a more useful purpose than studying how Bitcoin is going to change the world.

Re: Go hard on agents, not on your filesystem

#318

Post by ma2kx »

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.

There exist restricted Shells. But honestly, I don't feel capable of assessing all attack vectors and security measures in sufficient detail. For example, do the rbash restrictions also apply when Python is called with it? Or can the agent somehow bypass rbash to call Python?

https://en.wikipedia.org/wiki/Restricted_shell

Re: Go hard on agents, not on your filesystem

#319

Post by calvinmorrison »

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…

Pledge might be useful here

Re: Go hard on agents, not on your filesystem

#320

Post by sleepytree »

mehdibl wrote: post #316

Docker is hard to setup. The author made a nice solution but not sure if he know devcontainer and what he can do. You do the setup once and you roll in most dev tools. I'm still surprised the effort people put in such solution ignore the dev's core requirements, like sharing the env they use in a simple way. You used it to have custom env and isolate the agent. You want to persist your credentials? Mount the target f…

I'm surprised from reading these comments that more people aren't chiming in to ask why this solution is better than a dev container. That seems like the obviously best way to setup security boundaries that don't require you to still trust that AI will do what you ask it. You can run it remotely and it's portable etc.
Post reply on HN