Now we just need one for every python package.
Go hard on agents, not on your filesystem
101–110 of 374 posts
Re: Go hard on agents, not on your filesystem
#102I 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.
> “high profile developer supply chain compromises”
And nothing big has happened despite all the risks and problems that came up with it. People keep chasing speed and convenience, because most things don’t even last long enough to ever see a problem.
Re: Go hard on agents, not on your filesystem
#103This looks great and seems very well thought out. It looks both more convenient and slightly more secure than my solution, which is that I just give them a separate user. Agents can nuke the "agent" homedir but cannot read or write mine. I did put my own user in the agent group, so that I can read and write the agent homedir. It's a little fiddly though (sometimes the wrong permissions get set, so I have a script tha…
Where this falls down is that for the agents to interact with anything external, you have to give them keys. Without a proxy handling real keys between your agent and external services, those keys are at risk of compromise.
Also. Agents are very good at hacking “security penetration testing”, so “separate user” would not give me enough confidence against malicious context.
Re: Go hard on agents, not on your filesystem
#104It'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.
Re: Go hard on agents, not on your filesystem
#105Earlier quoted context omitted.
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…
It seems that the LLM has not only designed the site, but also written the text on at least the frontpage, which is a pretty bad signal. You need to rewrite all the text and Telde it with text YOU would actually write, since I doubt you would write in that style.
any negative signal you get from the front page should probably end up cancelled out by the whole decades of experience + stanford professor thing.
Re: Go hard on agents, not on your filesystem
#106Add 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…
[dead]
Re: Go hard on agents, not on your filesystem
#107This is a cool solution... I have a simpler one, though likely inferior for many purposes..
Run under its own user account via ssh. Bind mount project directories into its home directory when you want it to be able to read them. Mount command looks like
sudo mkdir /home//
sudo mount --bind --map-groups $(id -g ):$(id -g ):1 --map-users $(id -u ):$(id -u ):1 /home//
Re: Go hard on agents, not on your filesystem
#108Ugh. The name jai is very taken[1]... names matter. [1]: https://en.wikipedia.org/wiki/Jai_(programming_language)
Jonathan Blow has said that "Jai" is just a placeholder name or something.
Re: Go hard on agents, not on your filesystem
#109Not sure I understand the problem. Are people just letting AI do anything? I use Claude Code and it asks for permission to run commands, edit files, etc. No need for sandbox
Yes, people very much are, and that's exactly the problem! People run `claude --dangerously-skip-permissions` and `codex --yolo` all the time. And I think one of the appeals of opencode (besides cross-model, which is huge) is that the permissions are looser by default. These options are presumably intended for VM or container environments, but people are running them outside. And of course it works fine the first 100 times people do it, which drives them to take bigger and bigger risks.
Re: Go hard on agents, not on your filesystem
#110Ugh. The name jai is very taken[1]... names matter. [1]: https://en.wikipedia.org/wiki/Jai_(programming_language)
a closed beta of an obscure programming language where the wikipedia page is nominated for deletion because it is a "Non-notable programming language that is not publicly available." is considered "very taken"?