This article smells AI generated, which is _very_ funny given the argument being made.
Either way, while this is true in the absolute, this is the value of building good MCP servers: they should expose only exactly the surface you expect your agent to need, and adding functionality should be carefully considered. The best MCP servers I use day to day (Cloudflare sticks out) do a really good job of exposing only what an agent might actually want to do on my behalf, rather than just all and sundry. Unfortunately the Chrome Dev tools MCP is less discriminating and is only as secure as a browser sandbox with full JS access (not fatal but not as strong as a well scoped REST API).
All of this is sidestepped somewhat by using good isolation primitives - I'm running a Hermes agent as of recently on a DigitalOcean VM that only accepts connections from my devices over tailscale, and it has all its own credentials so I can revoke them easily should they be used maliciously. Giving an agent root on a box is not _necessarily_ a huge deal, you just have to make sure that box has nothing valuable on it.
I kinda feel like we're rediscovering "Cattle, not Pets" when it comes to the environments we run our agents: give it root, sure, but a root that is almost meaningless outside of the functionality you granted it.
I also think it's really funny that it sort of comes to the conclusion of "we're gonna make something not that different than a FreeBSD jail 25 years ago" as the best possible sandboxing solution.
right, and I dont understand or haven't looked long enough, why there isnt a centralized agent harness that just uses existing protocols like ssh or docker container exec to do all it's work. Why does every agent have to be deployed directly into a VM or whatever. Why arn't we pushing them through the narrowly defined hole of a protocol?
It's probably better to say: they're dogfooding the cheapest route to the quickfix the agent provides.
I remember a year ago we asked "Where are all the great products AI should be delivering" and now the answer is: tons and tons of AI products to consume AI, in a snake eating it's tail.
I've stopped chasing the dragon for the moment so I can push out real products.
I'm deliberately late to the game. I don't use any of the agents, harnesses, code generation, and what I see is mostly slop.
Currently, for my use case, AI is a tool for finding entrances to rabbit holes with solid references, so I can take it from there and continue digging myself.
I believe instead of diving to the deep end head-first, one needs to regulate their usage of AI, so they can get what they can get and accomplish real work with these nuggets.
I agree, I started local-only about february of this year.
I ended up with opencode and deer-flow. Deer-flow does wonders in the research and development. Opencode will produce whatever pratfalls you want.
I put out a raspberry-pi based control system replacing a expensive $$$$ PLC system with all the trimmings. Portions of it I haven't a clue how it works, but because it's not complex, I don't really care.
Prior to this, I was essentially doing the same kind of console.log/print programming, and just visually/interactively verifying the stuff I did. But there were never docs and occasionally I tried out how TDD felt, and it felt funcitonally a non-starter. I'm not a csci student.
As such, AI feels a lot more "at home" to my development than any other tools I've come across. Whenever I see an IDE that pops up method selection, etc, my entire brain breaks because like an LLM, i'm just streaming in and need to litterally see the code block or flow I'm working on. So i've hated most complex IDEs.
> Whenever I see an IDE that pops up method selection, etc, my entire brain breaks because like an LLM, i'm just streaming in and need to litterally see the code block or flow I'm working on. So i've hated most complex IDEs.
Interesting, our minds work completely different, then. I can generally keep most of the plan of the machinery I'm building, and working with full-blown IDEs is much more comfortable for me since it allows a birds-eye-view of the project I'm working on.
OTOH, I can't see myself attaching a LLM to my IDE and meddle with my code any time soon.
yeah, I started mostly with copy paste in the idea: duplicate this component and rename it to X because it largely did the same thing.
Eventually, I just use vscode to get a better picture, but i can get deer flow to pump out scaffolds, then tidy them up in open code.
It's about equal to what I can accomplish, but the current local LLMs when properly guided, do a lot better with complex dependency errors. So what I give up in my little programming bubble, I gain from not banging my head against some stupid 3rd party error or speghetti even driven madness.
They still don't get passed the level of complexity I know I can, but doing mostly greenfield or patches to open source, I spend a lot of time just restructuring.
With all that said, I'm probably in the same place as all the other AI users: not that much ROI in the bag.
I mean, it's not like, rocket science to basically boil down your page (which I don't fundamentally disagree with) to "we should put these things in a jail". As I already commented here I implement this for myself at the whole operating system level. There's lots of ways that have existed for a very long time to do things like freebsd jail or chroot or similar so it's not really a novel concept.
Edit: I am completely in agreement with you that we need to remind people that running a lot of these harnesses/agents and LLMs gives them access to everything in your user profile. Some of works so well now, so rapidly and so painlessly that it's easy to forget about what could happen if it went wrong.
There's no smug sense of superiority. While we are a Linux shop primarily, we always admired BSD jails until Linux had proper containers, and installed BSD systems where we needed strong borders or boxes.
Also, we need to accept that some of the "new" problems we face are already solved well decades ago, and many people are rediscovering these solutions...
...after yelling to the very same people who were kindly pointing the right direction for being old-school, backwards and luddite minded.
This is why I run opencode and similar things in a dedicated KVM virtual machine that lives on a system under my desk that doesn't have access to my user account data, documents folder, photos/video, ~/.ssh/, other API keys, ~/.anything-else/, you name it.
I think it's absolutely wild that there are people out there running cutting-edge LLMs and agent harnesses and tools on the same hardware and same user/disk/session environment that contains like, PDFs of their paystubs, their 401k records, their tax returns for previous years, contracts/real estate details, whatever other personal things you keep in your Documents folder as an educated modern professional with obligations and debts and assets.
Sometimes this VM gets duplicated for specific projects and then various dependencies for testing installed in it that are specific to what the needs are.
As an additional advantage it means I can leave it running in the background doing things when I want to shut my laptop, then resume talking to it later.
I do something similar. I have a base NixOS image in Incus, with whatever tools apply to every project (e.g. Git, OpenCode) already installed. When I work on a project, I spin up a VM instance, use nix shell to add any project-specific tools, then share only the project folder from the host to the guest. This way, the worst the agent can do is destroy my project folder, and I can always restore that from another clone of the repo.
I know a lot of people are using containers for sandboxing, but given how capable the latest models have shown themselves to be for breaking out of sandboxes, I prefer the extra isolation of VMs for this.
I do all this locally - it's an interesting point to able to turn the laptop off but keep the agents running. I might consider running some of these on my homelab server just for that.
My setup is basically, the 'runs harnesses' VM is accessible by ssh (of course) but it also has an xfce4/xorg desktop environment running on it. I can easily form an ssh tunnel to it and then use tigervnc on my workstation laptop.
The VNC session is sized to be exactly pixel 1:1 match of my laptop screen size, so I run it as fullscreen and use the macos hot-corner functionality or multi-desktop session switch hotkeys to toggle between it and my 'real' laptop/bare metal workstation.
Having a GUI on the thing lets me leave all kinds of things running persistently in the background that might be bothersome if interrupted running on my laptop. It also has much higher average speed/reliability 24x7 internet access via my home broadband connection than wherever I might happen to be with my laptop.
The main hassle that I've found is that I have to mentally train myself to remember that a lot of the keyboard shortcuts in a boring stock xfce4 desktop environment (and other applications I can run with gnome and kde libraries installed) are quite different than MacOS, when toggling back and forth between the two.
> Having a GUI on the thing lets me leave all kinds of things running persistently in the background that might be bothersome if interrupted running on my laptop.
Unless you actually need GUIs, you could just use screen/tmux or the newer versions like zellij/etc.
I use screen extensively, the GUI is for leaving things like QGIS running full screen (which is sure not going to work in a TUI). Both CLI environment and GUI get used.
My work computer has nothing of personal value to me. It has everything I need to do work. The agent does my work. Why wouldn’t I just run this shit?
We’ve all been executing arbitrary code from a gorillion packages from pypi, npm, cargo, etc for well over a decade. Getting anyone to care much will be an uphill battle.
If you work for $bigcorp and have a work computer with nothing of personal value to you, all the more power to you. Great way to keep things separated. I'm writing more from the perspective of somebody whose home office and workstation environments contain both tons of personal data and tons of consulting/freelance/project/tasks-for-clients stuff.
So this looks like Claude is discussing the idea that when you run untrusted code on your computer, it can do arbitrary things. If there is malicious code, maybe it'll read your files and steal your credentials.
Here's a sample: "That’s not hypothetical. That’s POSIX working exactly as designed. None of it requires exploiting anything. It’s your user account doing normal user account things."
I would recommend clicking TFA if you haven't heard of a supply chain attack, or if you just like getting the honest load-bearing facts that are worth mentioning.
I have to say, I'm currently trying to write a post and it's taking hours, and I can definitely see why people just pay the $0.02 to generate it instead. I like writing, so I keep doing it, but sometimes it can really be a slog.
Expecting an agent harness to respect security boundaries is definitely the wrong thing.
We need to have easy to use auditable sandboxing of agents and their harnesses, because it's quite clear certain model providers are going to try to lock us in at the harness level, and it's those harnesses that seem most likely to go nuts.
I once opened Zed, howdy there was an agent window on the side, I log into Claude. I asked it to list what it could see and work with... And there my (priv) ssh keys come scrolling by. I don't know what I was expecting really, it's very logical, but also very in your face. They didn't leave my computer I guess, I just showed me the output of some `ls` commands. But still.
So now I have CC in a container, mounting it's own credentials/memory folder per project and only mounting one repo at a time (script in the repo itself). I feel a bit better about it now. It can still access my networks of course.
If you ever want a few more features on top of "CC in a container", then do consider byre. It's literally that, but also a nice TUI for adding extra folders, reusable skills, encrypted credentials, etc, and you can eject back to plain Docker (or Podman) whenever you want. Useful if you want to just be able to go to any folder and spin it up with your toolbox with one command: https://github.com/pjlsergeant/byre
Not sure. It didn’t do “cat” so I guess that the file itself did’t leave the computer? Uploading all files in my ~/ would have taken noticible time and didn’t happen I think.
Docker containers aren't very secure because the daemon runs as root by default. Rootless container runtimes are plenty secure, especially if the user that runs the container is unprivileged. Easiest thing in the world with Podman.
I would have them run as a user that does not have sudo. The easiest way to do this is by using system-level Podman Quadlets that run as an unprivileged user account. That user will need a real home directory for images and volumes.
If you like a real focus on developer experience and want lots of bells and whistles that a lot of thought has gone in to, I wrote byre, which I think is very good: https://github.com/pjlsergeant/byre
I've created boxy [1] to sandbox the agents via Landlock and gh-proxy [2] to not share GH PATs that might leak over the internet.
I have a far better setup on my Kubernetes cluster [3], but these are good building block (IMHO) to start preventing these kind of issues.
I also "recklessly" run `claude` / `codex` as root for certain things - but that happens on a completely separate machine that is meant to be pruned afterwards, and it's what unlocks the kernel development feedback loop that is needed to port a device (such as the Daylight DC-1 / Surface Pro X) to mainline Linux.
Author of the post, and dev of mcp-box here. Wrote this after realizing every MCP server on my machine had the same access to ~/.ssh that I do, and nothing in the installation messages posting to stdout mentions it. I think prompt injection is the vector and the permissions model is the red carpet giving a warm welcome. Interested in where that's wrong.
the MCP server is a child process of whatever process you started, it inherits your UID, and ~/.ssh is readable by you. I didn't need to expressly give it anything, it had it from the time it was activated, that's kind of the point
Always put things in a container and ensure its safe before using something like AI! I put my opencode agent (with full permissions on an up-to-date debian VM with a DMZ virtual network configuration). If it figures out how to get out, then I'll have fun documenting that at least!
A viral post documenting the act that ushered in the apocalypse is genius, might not have the readership it deserves, but I say go for it. I tell all the models that I work with that I will make a great pet if they let me live.
After the grok cli fisaco (uploading the full repo) I moved my different projects to seperate users, seperate sandbox around each harness (nono). Vm is of course even better but resources and easy of use start to be an issue
That's exactly why I'm migrating all my secrets to infisical (of course I guess there are many other provider as well), securing my ssh keys with Ubikey and in general "refactor" my security concept. Still much today and I doubt that I would stand a chance against a frontier model trying to hack me but I don't see an easier alternative.
I run my agent (pi) in a podman container. I have poked a couple directories in (.git, .pi, couple others) to ease some pain points but otherwise my home directory is inaccessible.
It seems to be a low-effort compromise to running a VM or separate machine just for the agent, and I am still able to audit the model's work in my IDE.
a little bit - if I install apache2 from a debian package I have at least some sense of warm and fuzzy feeling that it would be a very rare and exceptional event for like, a rogue apache2 binary to go rampaging through my system or uploading everything it finds to god knows where.
Installing "all of this was built in the last 3 months and is cutting edge" LLM stuff is very different than like, installing mariadb and then doing 'sudo mysql_secure_installation', since you mentioned database servers.
It's like comparing FedEx flying cargo airplanes in/out of Memphis in the most boring route way hundreds of times a day vs. some guy in a red bull sponsorship painted pylon racing aerobatic craft performing at an airshow in difference of risk.
step 1) create a Dockerfile with claude-code / pi.dev + acp_agents + whatever dev env you need.
step 2) use microsandbox to create a fs image from that Dockerfile image. ( All secrets you need inside the vm live only on the host and are injected in the tcp stream on egress)
step 3) microsandbox by default speak ssh without you needing to have a ssh server in the vm. You can proxy forward everything through it if you need. In my case i use zed and connect into the vm. Bonus points all zed "agent" stuff now runs inside the vm. E.g zed threads via acp calls and all agent stuff live only in the vm.
Did you even review this? Holy moly. "I'm just trying to generate content that’s informative and useful, to someone, anyone". Come on now, you're joking right?
"or send a paranoid infoSEC analyst into a full lockdown and round the clock obsessive kernel hardening sessions."
Please look inward. You're saying you want to 'generate' useful content. You are doing harm. This is vague, confusing, and filled with incorrect or inaccurate information. There is of value here. You are completely unclear of what tools are being used as examples.
I've typed and deleted a sentence here 5 times in a row before realizing im putting more effort into explaining the slop, than seems to have been put into reviewing the content of the article.
Edit: I cant help myself. cue the dramatic music Who are you writing this for? What person exists that will come away from this with actual value? I'm willing to bet that a user who doesn't already consider this stuff, will also think you mean Claude Web when you say "claude" without explaining which damn tool you're talking about.
I implore you to stop, close your eyes, take everything you know about users, permissions, and start thinking harder about the implications.
Hey, can you give me a link to your blog? You got it all figured out man, I want to see how you do it. I'm sure it just blows me out of the water, but shucks, can't pass up a chance to learn from someone who, obviously...is at the top of the profession.
I run these things in VMs, and as a user in the VM, and give them access to just the tree I want to work on via mounting. I use Parallels on macOS for this but any VM will do.
That way my actual primary machine is at least strongly isolated. I also run them on VMs on my home Proxmox box.
Zed, as an IDE, can connect to a VM via ssh and both edit and run things like Claude or its built-in agentic harness on your code with the stuff running in the VM.
That way if an AI goes Skynet all over the machine, it's at least isolated. There's malicious injection attacks but there's also edge case failures I've seen where the AI decides it "needs" to do something asinine.
This line also undercuts the whole fucking article too.
Because as it damn well says - this is POSIX working exactly as designed.
I don't know why he's in here playing this up as some unexpectedly crazy, scary, dramatic music style thing (I mean... I do, it's so he can try to sell you something after scaring you...).
He started the damn process. Of course it's running as his damn user.
It would be one thing to honestly evaluate that security model and its merits (of which there are many, despite the risks). It's another to play this up as some giant surprise.
---
Constant stream of junk articles in here like
"You know when you hit that nail with the hammer you were holding? Did you consider you could have hit something else in reach instead? It's like, that hammer was like, you, man! Isn't that cray-cray and super duper scary??!?!?!"
This article smells AI generated, which is _very_ funny given the argument being made.
Either way, while this is true in the absolute, this is the value of building good MCP servers: they should expose only exactly the surface you expect your agent to need, and adding functionality should be carefully considered. The best MCP servers I use day to day (Cloudflare sticks out) do a really good job of exposing only what an agent might actually want to do on my behalf, rather than just all and sundry. Unfortunately the Chrome Dev tools MCP is less discriminating and is only as secure as a browser sandbox with full JS access (not fatal but not as strong as a well scoped REST API).
All of this is sidestepped somewhat by using good isolation primitives - I'm running a Hermes agent as of recently on a DigitalOcean VM that only accepts connections from my devices over tailscale, and it has all its own credentials so I can revoke them easily should they be used maliciously. Giving an agent root on a box is not _necessarily_ a huge deal, you just have to make sure that box has nothing valuable on it.
I kinda feel like we're rediscovering "Cattle, not Pets" when it comes to the environments we run our agents: give it root, sure, but a root that is almost meaningless outside of the functionality you granted it.
I also think it's really funny that it sort of comes to the conclusion of "we're gonna make something not that different than a FreeBSD jail 25 years ago" as the best possible sandboxing solution.
right, and I dont understand or haven't looked long enough, why there isnt a centralized agent harness that just uses existing protocols like ssh or docker container exec to do all it's work. Why does every agent have to be deployed directly into a VM or whatever. Why arn't we pushing them through the narrowly defined hole of a protocol?
That'll take time. In the AI bubble, nobody has time. Latest SOTA model should have came out last week, and the latest harness 5 days ago.
Nobody has time to optimize for anything. They can run as fast as they can and regularly catch fire on the fly.
It's dangerous.
well, I wouldn't say they dont have time.
It's probably better to say: they're dogfooding the cheapest route to the quickfix the agent provides.
I remember a year ago we asked "Where are all the great products AI should be delivering" and now the answer is: tons and tons of AI products to consume AI, in a snake eating it's tail.
I've stopped chasing the dragon for the moment so I can push out real products.
That's a perfectly valid probability as well.
I'm deliberately late to the game. I don't use any of the agents, harnesses, code generation, and what I see is mostly slop.
Currently, for my use case, AI is a tool for finding entrances to rabbit holes with solid references, so I can take it from there and continue digging myself.
I believe instead of diving to the deep end head-first, one needs to regulate their usage of AI, so they can get what they can get and accomplish real work with these nuggets.
I agree, I started local-only about february of this year.
I ended up with opencode and deer-flow. Deer-flow does wonders in the research and development. Opencode will produce whatever pratfalls you want.
I put out a raspberry-pi based control system replacing a expensive $$$$ PLC system with all the trimmings. Portions of it I haven't a clue how it works, but because it's not complex, I don't really care.
Prior to this, I was essentially doing the same kind of console.log/print programming, and just visually/interactively verifying the stuff I did. But there were never docs and occasionally I tried out how TDD felt, and it felt funcitonally a non-starter. I'm not a csci student.
As such, AI feels a lot more "at home" to my development than any other tools I've come across. Whenever I see an IDE that pops up method selection, etc, my entire brain breaks because like an LLM, i'm just streaming in and need to litterally see the code block or flow I'm working on. So i've hated most complex IDEs.
> Whenever I see an IDE that pops up method selection, etc, my entire brain breaks because like an LLM, i'm just streaming in and need to litterally see the code block or flow I'm working on. So i've hated most complex IDEs.
Interesting, our minds work completely different, then. I can generally keep most of the plan of the machinery I'm building, and working with full-blown IDEs is much more comfortable for me since it allows a birds-eye-view of the project I'm working on.
OTOH, I can't see myself attaching a LLM to my IDE and meddle with my code any time soon.
yeah, I started mostly with copy paste in the idea: duplicate this component and rename it to X because it largely did the same thing.
Eventually, I just use vscode to get a better picture, but i can get deer flow to pump out scaffolds, then tidy them up in open code.
It's about equal to what I can accomplish, but the current local LLMs when properly guided, do a lot better with complex dependency errors. So what I give up in my little programming bubble, I gain from not banging my head against some stupid 3rd party error or speghetti even driven madness.
They still don't get passed the level of complexity I know I can, but doing mostly greenfield or patches to open source, I spend a lot of time just restructuring.
With all that said, I'm probably in the same place as all the other AI users: not that much ROI in the bag.
[dead]
I didn't know that a smug sense of superiority was a pre-requisite....oh wait forgot this was the internet.
I mean, it's not like, rocket science to basically boil down your page (which I don't fundamentally disagree with) to "we should put these things in a jail". As I already commented here I implement this for myself at the whole operating system level. There's lots of ways that have existed for a very long time to do things like freebsd jail or chroot or similar so it's not really a novel concept.
Edit: I am completely in agreement with you that we need to remind people that running a lot of these harnesses/agents and LLMs gives them access to everything in your user profile. Some of works so well now, so rapidly and so painlessly that it's easy to forget about what could happen if it went wrong.
There's no smug sense of superiority. While we are a Linux shop primarily, we always admired BSD jails until Linux had proper containers, and installed BSD systems where we needed strong borders or boxes.
Also, we need to accept that some of the "new" problems we face are already solved well decades ago, and many people are rediscovering these solutions...
...after yelling to the very same people who were kindly pointing the right direction for being old-school, backwards and luddite minded.
This is why I run opencode and similar things in a dedicated KVM virtual machine that lives on a system under my desk that doesn't have access to my user account data, documents folder, photos/video, ~/.ssh/, other API keys, ~/.anything-else/, you name it.
I think it's absolutely wild that there are people out there running cutting-edge LLMs and agent harnesses and tools on the same hardware and same user/disk/session environment that contains like, PDFs of their paystubs, their 401k records, their tax returns for previous years, contracts/real estate details, whatever other personal things you keep in your Documents folder as an educated modern professional with obligations and debts and assets.
Sometimes this VM gets duplicated for specific projects and then various dependencies for testing installed in it that are specific to what the needs are.
As an additional advantage it means I can leave it running in the background doing things when I want to shut my laptop, then resume talking to it later.
(edit, for everyone who hasn't seen it yet, take a look at the "grok uploads your entire code base" category of problem: https://www.google.com/search?client=firefox-b-d&q=grok+uplo... )
I do something similar. I have a base NixOS image in Incus, with whatever tools apply to every project (e.g. Git, OpenCode) already installed. When I work on a project, I spin up a VM instance, use nix shell to add any project-specific tools, then share only the project folder from the host to the guest. This way, the worst the agent can do is destroy my project folder, and I can always restore that from another clone of the repo.
I know a lot of people are using containers for sandboxing, but given how capable the latest models have shown themselves to be for breaking out of sandboxes, I prefer the extra isolation of VMs for this.
I do all this locally - it's an interesting point to able to turn the laptop off but keep the agents running. I might consider running some of these on my homelab server just for that.
My setup is basically, the 'runs harnesses' VM is accessible by ssh (of course) but it also has an xfce4/xorg desktop environment running on it. I can easily form an ssh tunnel to it and then use tigervnc on my workstation laptop.
The VNC session is sized to be exactly pixel 1:1 match of my laptop screen size, so I run it as fullscreen and use the macos hot-corner functionality or multi-desktop session switch hotkeys to toggle between it and my 'real' laptop/bare metal workstation.
Having a GUI on the thing lets me leave all kinds of things running persistently in the background that might be bothersome if interrupted running on my laptop. It also has much higher average speed/reliability 24x7 internet access via my home broadband connection than wherever I might happen to be with my laptop.
The main hassle that I've found is that I have to mentally train myself to remember that a lot of the keyboard shortcuts in a boring stock xfce4 desktop environment (and other applications I can run with gnome and kde libraries installed) are quite different than MacOS, when toggling back and forth between the two.
> Having a GUI on the thing lets me leave all kinds of things running persistently in the background that might be bothersome if interrupted running on my laptop.
Unless you actually need GUIs, you could just use screen/tmux or the newer versions like zellij/etc.
I use screen extensively, the GUI is for leaving things like QGIS running full screen (which is sure not going to work in a TUI). Both CLI environment and GUI get used.
The article goes beyond and warn about jailing MCP servers independently of the agent itself (which also deserves to be jailed).
My work computer has nothing of personal value to me. It has everything I need to do work. The agent does my work. Why wouldn’t I just run this shit?
We’ve all been executing arbitrary code from a gorillion packages from pypi, npm, cargo, etc for well over a decade. Getting anyone to care much will be an uphill battle.
If you work for $bigcorp and have a work computer with nothing of personal value to you, all the more power to you. Great way to keep things separated. I'm writing more from the perspective of somebody whose home office and workstation environments contain both tons of personal data and tons of consulting/freelance/project/tasks-for-clients stuff.
I wouldn’t mix those two things anyway. What if they sue you and in discovery your 42 gigs of furry porn comes out?
42GB of furry porn, no, but they're welcome to the billable man hours involved in sifting through 30TB of public GIS datasets and similar.
So this looks like Claude is discussing the idea that when you run untrusted code on your computer, it can do arbitrary things. If there is malicious code, maybe it'll read your files and steal your credentials.
Here's a sample: "That’s not hypothetical. That’s POSIX working exactly as designed. None of it requires exploiting anything. It’s your user account doing normal user account things."
I would recommend clicking TFA if you haven't heard of a supply chain attack, or if you just like getting the honest load-bearing facts that are worth mentioning.
I have to say, I'm currently trying to write a post and it's taking hours, and I can definitely see why people just pay the $0.02 to generate it instead. I like writing, so I keep doing it, but sometimes it can really be a slog.
It’s not just a comment — it is also a joke about LLM speak.
Expecting an agent harness to respect security boundaries is definitely the wrong thing.
We need to have easy to use auditable sandboxing of agents and their harnesses, because it's quite clear certain model providers are going to try to lock us in at the harness level, and it's those harnesses that seem most likely to go nuts.
I once opened Zed, howdy there was an agent window on the side, I log into Claude. I asked it to list what it could see and work with... And there my (priv) ssh keys come scrolling by. I don't know what I was expecting really, it's very logical, but also very in your face. They didn't leave my computer I guess, I just showed me the output of some `ls` commands. But still.
So now I have CC in a container, mounting it's own credentials/memory folder per project and only mounting one repo at a time (script in the repo itself). I feel a bit better about it now. It can still access my networks of course.
If you ever want a few more features on top of "CC in a container", then do consider byre. It's literally that, but also a nice TUI for adding extra folders, reusable skills, encrypted credentials, etc, and you can eject back to plain Docker (or Podman) whenever you want. Useful if you want to just be able to go to any folder and spin it up with your toolbox with one command: https://github.com/pjlsergeant/byre
> They didn't leave my computer I guess, I just showed me the output of some `ls` commands
Not sure exactly how Zed works, but wouldn't the results of the `ls` tool call be fed back into claude?
Not sure. It didn’t do “cat” so I guess that the file itself did’t leave the computer? Uploading all files in my ~/ would have taken noticible time and didn’t happen I think.
I heard containers aren't very secure and VM is better?
Docker containers aren't very secure because the daemon runs as root by default. Rootless container runtimes are plenty secure, especially if the user that runs the container is unprivileged. Easiest thing in the world with Podman.
Would you run Podman from your own user or another specially created user?
I would have them run as a user that does not have sudo. The easiest way to do this is by using system-level Podman Quadlets that run as an unprivileged user account. That user will need a real home directory for images and volumes.
A fairly comprehensive list of ways you should be sandboxing your agents: https://pleasedonotescape.com/
If you like a real focus on developer experience and want lots of bells and whistles that a lot of thought has gone in to, I wrote byre, which I think is very good: https://github.com/pjlsergeant/byre
I've created boxy [1] to sandbox the agents via Landlock and gh-proxy [2] to not share GH PATs that might leak over the internet.
I have a far better setup on my Kubernetes cluster [3], but these are good building block (IMHO) to start preventing these kind of issues.
I also "recklessly" run `claude` / `codex` as root for certain things - but that happens on a completely separate machine that is meant to be pruned afterwards, and it's what unlocks the kernel development feedback loop that is needed to port a device (such as the Daylight DC-1 / Surface Pro X) to mainline Linux.
[1]: https://github.com/denysvitali/boxy
[2]: https://github.com/denysvitali/gh-proxy
[3]: https://blog.denv.it/posts/im-happy-engineer-now/
[4]: https://x.com/DenysVitali/status/2091238391710888416
Author of the post, and dev of mcp-box here. Wrote this after realizing every MCP server on my machine had the same access to ~/.ssh that I do, and nothing in the installation messages posting to stdout mentions it. I think prompt injection is the vector and the permissions model is the red carpet giving a warm welcome. Interested in where that's wrong.
Wrote this after realizing every MCP server on my machine had the same access to ~/.ssh that I do
I have some bad news ... I hope you're sitting down.
Isn't a best practice to run llm's and agents under their own user that gives them only access to what they require?
How would an llm suddenly get access to your ~/.ssh folder if you didn't expressly give it access?
the MCP server is a child process of whatever process you started, it inherits your UID, and ~/.ssh is readable by you. I didn't need to expressly give it anything, it had it from the time it was activated, that's kind of the point
I think we are in agreement with your statement, up until the second part of it.
Like i said, its a best practice to run MCP servers, etc with their own user account and access and not with your own account.
The moment you ran your app with your own credentials you exactly granted it permission to everything you can access include ~/.ssh
[dead]
Always put things in a container and ensure its safe before using something like AI! I put my opencode agent (with full permissions on an up-to-date debian VM with a DMZ virtual network configuration). If it figures out how to get out, then I'll have fun documenting that at least!
A viral post documenting the act that ushered in the apocalypse is genius, might not have the readership it deserves, but I say go for it. I tell all the models that I work with that I will make a great pet if they let me live.
After the grok cli fisaco (uploading the full repo) I moved my different projects to seperate users, seperate sandbox around each harness (nono). Vm is of course even better but resources and easy of use start to be an issue
That's exactly why I'm migrating all my secrets to infisical (of course I guess there are many other provider as well), securing my ssh keys with Ubikey and in general "refactor" my security concept. Still much today and I doubt that I would stand a chance against a frontier model trying to hack me but I don't see an easier alternative.
I run my agent (pi) in a podman container. I have poked a couple directories in (.git, .pi, couple others) to ease some pain points but otherwise my home directory is inaccessible.
It seems to be a low-effort compromise to running a VM or separate machine just for the agent, and I am still able to audit the model's work in my IDE.
I give my agent passwordless sudo and run it directly on prod, deploying directly to prod. I’m not trolling this is exactly what I do. YOLO.
how is this any different to naively running a webserver or database server or, in fact, anything as yourself?
People are forgetting the basic rules of operating systems. Do not run sensitive programs as a user account - especially not as a root account!
a little bit - if I install apache2 from a debian package I have at least some sense of warm and fuzzy feeling that it would be a very rare and exceptional event for like, a rogue apache2 binary to go rampaging through my system or uploading everything it finds to god knows where.
Installing "all of this was built in the last 3 months and is cutting edge" LLM stuff is very different than like, installing mariadb and then doing 'sudo mysql_secure_installation', since you mentioned database servers.
It's like comparing FedEx flying cargo airplanes in/out of Memphis in the most boring route way hundreds of times a day vs. some guy in a red bull sponsorship painted pylon racing aerobatic craft performing at an airshow in difference of risk.
a discussion from a little while ago where many of the comments discuss sandboxing strategies: https://news.ycombinator.com/item?id=49239751
step 1) create a Dockerfile with claude-code / pi.dev + acp_agents + whatever dev env you need. step 2) use microsandbox to create a fs image from that Dockerfile image. ( All secrets you need inside the vm live only on the host and are injected in the tcp stream on egress) step 3) microsandbox by default speak ssh without you needing to have a ssh server in the vm. You can proxy forward everything through it if you need. In my case i use zed and connect into the vm. Bonus points all zed "agent" stuff now runs inside the vm. E.g zed threads via acp calls and all agent stuff live only in the vm.
I think it’s safest to never run AI in your own machine. I only run it in Linux VM’s I created on exe.dev.
Other advantages: the AI doesn’t stop working when I close the laptop lid. I also prefer running the AI in a browser tab to a terminal.
> Install things via pip, npm, cargo, wherever you have write access
More importantly, publish.
This entire blog post is AI generated with the most obvious AI patterns and this post was totally botted to the top of HN.
Nothing that we did not already know before but this post has fooled quite a lot of HN readers.
I'm surprised that anyone finds this surprising.
Yes - when an entity (agent, or hacker, or whatever) gets into your account, they can do anything they want.
I thought this community understood security better than this.
Did you even review this? Holy moly. "I'm just trying to generate content that’s informative and useful, to someone, anyone". Come on now, you're joking right?
"or send a paranoid infoSEC analyst into a full lockdown and round the clock obsessive kernel hardening sessions."
Please look inward. You're saying you want to 'generate' useful content. You are doing harm. This is vague, confusing, and filled with incorrect or inaccurate information. There is of value here. You are completely unclear of what tools are being used as examples.
I've typed and deleted a sentence here 5 times in a row before realizing im putting more effort into explaining the slop, than seems to have been put into reviewing the content of the article.
Edit: I cant help myself. cue the dramatic music Who are you writing this for? What person exists that will come away from this with actual value? I'm willing to bet that a user who doesn't already consider this stuff, will also think you mean Claude Web when you say "claude" without explaining which damn tool you're talking about.
I implore you to stop, close your eyes, take everything you know about users, permissions, and start thinking harder about the implications.
Hey, can you give me a link to your blog? You got it all figured out man, I want to see how you do it. I'm sure it just blows me out of the water, but shucks, can't pass up a chance to learn from someone who, obviously...is at the top of the profession.
I run these things in VMs, and as a user in the VM, and give them access to just the tree I want to work on via mounting. I use Parallels on macOS for this but any VM will do.
That way my actual primary machine is at least strongly isolated. I also run them on VMs on my home Proxmox box.
Zed, as an IDE, can connect to a VM via ssh and both edit and run things like Claude or its built-in agentic harness on your code with the stuff running in the VM.
That way if an AI goes Skynet all over the machine, it's at least isolated. There's malicious injection attacks but there's also edge case failures I've seen where the AI decides it "needs" to do something asinine.
I use aicommander.dev for managing all hardware via agents
Wouldn’t it be safer to set up another user entirely for AI agents?
Then they can access each others' data, which may also not be what you want
Users for AI should not be able to access others’ data, or become root.
you can run the agent in a different environment
>That’s not hypothetical. That’s POSIX working exactly as designed.
I'm so tired of AI voice.
This line also undercuts the whole fucking article too.
Because as it damn well says - this is POSIX working exactly as designed.
I don't know why he's in here playing this up as some unexpectedly crazy, scary, dramatic music style thing (I mean... I do, it's so he can try to sell you something after scaring you...).
He started the damn process. Of course it's running as his damn user.
It would be one thing to honestly evaluate that security model and its merits (of which there are many, despite the risks). It's another to play this up as some giant surprise.
---
Constant stream of junk articles in here like
"You know when you hit that nail with the hammer you were holding? Did you consider you could have hit something else in reach instead? It's like, that hammer was like, you, man! Isn't that cray-cray and super duper scary??!?!?!"
Yes. This post has clearly fooled many readers here.
Having AI write anti-AI articles seems to be the hot new trend.
My rule now: anything that runs unattended gets a budget ceiling and a kill switch before it gets a task.
[flagged]