SUPER interesting! You just earned star #508. Going to take a look at this.
41 karma · joined January 13, 2026
2. The VM is, in some sense, packaging. The main value adds are the two indirections between the agent and the outside world. Its access to `git` and `gh` are both mediated by a rules-based dispatcher that exercises fine-grained control in excess of what can be achieved with a PAT. HTTP requests pass through a middleware that block requests based on configurable rules.
As a matter of fact, the tool is zero-knowledge by design: state is decrypted in your browser and encrypted again before it leaves. There are no account integrations. The persistence layer sees noise. There are a couple of stateless backend tools that transiently see anonymous data to perform numerical optimizations.
But that's a story for another Show HN...
These tools generally offer the ability to simply shut off these guardrails. When you do this, you're in what has come to be called "yolo mode."
I am arguing that, sandboxed correctly, this mode is actually safer than the standard one because it mitigates my own fatigue and frustration. These threats surface every hour of every day. Malicious actors are definitely a thing, but your own exhaustion is a far more present danger.
It's designed to be fairly safe in exactly that situation, because it's sandboxed twice over: once in a container and once in a VM. You start to layer on risk when you punch holes in it (adding domains to the whitelist, port-forwarding, etc).
> how do you deploy this inside AWS Lambda/Fargate for the same usecase These both seem like poor fits. I suspect Lambda is simply a non-starter. For Fargate, you'd be running k8s inside a VM inside a pod inside k8s. As an alternative, you could construct an AMI that runs the yolo-cage microk8s cluster without the VM, and then you could deploy it to EC2.
("But David," you might object, "you said you were using this to build a financial analysis tool!" Quite so, but the tool is basically a fancy calculator with no account access, and the persistence layer is E2EE.)
It wasn't "vibe coded" in the sense that I was just describing what I want and letting the agent build it. But it definitely was built indirectly, and in an area that is not my primary focus. A charitable read is that I am borrowing epistemic fire from the gods; an uncharitable one is that I am simply playing with fire.
I am not apologetic about this approach, as I think it's the next step in a series of abstractions for software implementation. There was a time when I sometimes took some time to look at Java bytecode, but doing so today would feel silly.
Abstracting to what is in essence a non-deterministic compiler is going to bring with it a whole new set of engineering practices and disciplines. I would not recommend that anyone start with it, as it's a layer on top of SWE. I compare it to visual vs instrument flight rules.
Anthropic is trying to earn developer trust; they have a strong incentive to make sure that private keys and other details that the agent sees do not leak into the training data. But the agent itself is just a glorified autocomplete, and it can get confused and do stupid stuff. So I put it in a transparent prison that it can see out of but can't leave.
That definitely helps with the main failure modes I was worrying about, but it's just one layer. You definitely want to make sure that your production secrets are in an external vault (Hashicorp Vault, Google Secret Store, GitHub secrets, etc) that the agent can't access.
The things that agent is seeing should be dev secrets that maybe could be used as the start of a sophisticated exploit, but not the end of it. There's no such thing as perfect security, only very low probabilities of breach. Adding systems that are very annoying to breach and have little offer when you do greatly lowers the odds.
For Claude specifically, there are two places where it tracks state:
~/.claude.json -- contains a bunch of identity stuff and something about oauth
~/claude/ -- also contains something about oauth, plus conversation history, etc
If they're not _both_ present and well-formed, then it forces you back through the auth flow. On an ordinary desktop setup, that's transparent. But if you want to sandbox each thread, then sharing just the token requires a level of involvement that feels icky, even if the purpose is TOS-compliant.
That said, I have not yet started playing with MCP servers. I suspect that they are completely broken inside yolo-cage right now, as they almost certainly get stopped by the proxy.
As far as lock-in, though, that's been much less of a problem. It's insanely easy to switch because these tools are largely interchangeable. Yes, this project is currently built around Claude code, but that's probably a one-hour spike away from flexibility.
I actually think the _lack_ of lock-in is the single biggest threat to the hyperscalers. The technology can be perfectly transformative and still not profitable, especially given the current business model. I have Qwen models running on my Mac Studio that give frontier models a run for their money on many tasks. And I literally bought this hardware in a shopping mall.
What's my role here? Over the past year, it's become clear to me that there are really two distinct activities to the business of software development. The first is the articulation of a process by which an intent gets actualized into an automation. The second is the translation of that intent into instructions that a machine can follow. I'm pretty sure only the first one is actually engineering. The second is, in some sense, mechanical. It reminds me of the relationship between an architect and a draftsperson.
I have been much freer to think about engineering and objectives since handing off the coding to the machine. There was an Ars Technica article on this the other day that really nails the way I've been experiencing this: https://arstechnica.com/information-technology/2026/01/10-th...
Why do I trust the finished product if I don't trust the environment? This one feels a little more straightforward: it's for the same reason that construction workers wear hard hats in environments that will eventually be safe for children. The process of building things involves dangerous tools and exposed surfaces. I need the guardrails while I'm building, even though I'm confident in what I've built.
I think it's the convergence of two things. First, the agents themselves make it easier to get exactly what you want; and second, the OEM solutions to these things really, really aren't good enough. CC Cloud and Codex are sort of like this, except they're opaque and locked down, and they work for you or they don't.
It reminds me a fair bit of 3D printer modding, but with higher stakes.
Then I was talking to a security engineer at my company, who pointed out that a VM would make him feel better about the whole thing anyway. And it occurred to me: if I packaged it as a VM, then I'd get both isolation and determinism. It would be easier to install and easier to debug.
So that's why I decided to go with a Vagrant-based installation. The obvious downside is that it's harder now to integrate it with external systems or to use the full power of whatever environment you deploy it in.
On the one hand, you're right: those commit messages are proof positive that the security is not perfect. On the other hand, the threat model is that most threats from AI agents stem from human inattention, and that agents powered by hyperscaler models are unlikely to be overtly malicious without an outside attacker.
There are some known limitations of the security model, and they are limitations that I can accept. But I do believe that yolo-cage provides security in depth, and that the security it provides is greater than what is achieved through permission prompts that pop up during agent turns in Claude Code.
The threat with AI agents exists at a fairly high level of abstraction, and developing with them assumes a baseline level of good intentions. You're protecting against mistakes, confusion, and prompt injection. For that, your threat mitigation strategy should be focused on high-level containment.
I've been working on something in a similar vein to yolobox, but the isolation goal has more to do with secret exfiltration and blast radius. I'd love some feedback if you have a chance!
Yolobox protects your local machine from accidental damage (crucial if you're worried about rm -rf ~). yolo-cage focuses on secret exfiltration and multi-agent coordination: it runs in Kubernetes, scans all egress traffic for secrets (API keys, tokens, SSH keys), enforces git branch isolation so multiple agents can work in parallel, and ensures agents can't merge their own PRs. "Agent proposes, human disposes."
The escape testing framework has a meta twist: there's a canned prompt that asks Claude to try to escape its own containment, and that prompt lives inside the repository. The agent verifies the prompt is legitimate by finding it in the repo it's auditing - the cage contains its own escape room instructions.
(I tried to post this as a separate Show HN but my account is too new - happy to discuss the tradeoffs between local sandboxing vs. server-side containment here.)