The login is annoying but, lacking an open source alternative, this has been my daily driver for a while now because it works great out of the box with two key features: outbound firewall and secret injection with placeholders.
I run it with superset and then each git worktree is mounted in a sandbox that is configured for each repo i work in.
Outbound firewall is `--network-isolated`: egress is denied except the agent's own API endpoints plus domains you allow, enforced sandbox-side (working on host-side enforcement now). `--network-none` if you want nothing.
Credential brokering works the way you describe (currently Claude-only, I'll add more as time allows). The API key stays on the host, a local proxy injects it into the outbound request, and the sandbox never holds anything worth stealing. Other agents' credentials currently arrive as read-only file mounts instead (weaker, and something I'll fix soon). Generalising the injector is the obvious next thing.
One difference from your setup: yoloAI copies your worktree instead of mounting it. The agent works on the copy, you `yoloai diff`, and `yoloai apply` replays the commits into your real repo. That's deliberate. Docker's own security docs talk about the dangers of bombs being left behind in a live-mounted dir (git hooks, package.json scripts, Makefiles, IDE task config), which diff/apply avoids.
Isolation is per-sandbox rather than fixed: runc, gVisor, or Kata VMs (QEMU or Firecracker) on Linux; Seatbelt or full macOS VMs via Tart on a Mac.
A few months ago now I started adding seccomp sandboxing to jinja2rs and then liboverlayfs support to ansiblers (which are early Rust ports).
Haven't finished that, but
I started working on a VM format that stores signed machine state into an OCI container repository, using the hypervisor migration support of KVM/QEMU.
Though this is not safe yet if ever, VM migrations are probably another way to sandbox and deploy en masse.
Agreed. Network control and secret injection together with a microVM setup is as good as it gets right now, although I believe that we need more fine-grained tools down the road. It sounds like Microsandbox would be the perfect fit for what you are describing. I also built my own coding agent workbench on top of it (https://github.com/isolade/isolade). Microsandbox is quite cool, check it out: https://github.com/superradcompany/microsandbox
I've put some effort to integrate it to my agentic workflow. The problem, however, with docker in smolvm: it work-ish (there is example), but quite hacky.
Another problem which I wasnt able to solve - persistent image without Dockerfile. CloudInit will be ideal.
Documention at this moment in an early stage.
Overall, its a great project but for me was simpler just use Virtual Machine Manager (libvirt GUI).
I wish all luck to the maintainers, but probably DX-wise I will prefer to have more granular or predictable controls (eg micro cloud from Canonical).
Yep - similar in some ways but headed towards different directions.
I am building a virtual machine to simplify/replace container infra. Ex. we run containers inside of linux VM's even in the `cloud`, resulting in managing both the vm, and the containers.
But smol machines is a lightweight, portable VM that you can package into a single portable .smolmachine file to be rehydrated on any platform, kind of like how containers are used for today.
Sandboxing happens to be a feature of virtual machines, so we are alike in being used for sandboxing.
> Docker containers are not enough isolation for anyone that cares about jailbreak scenarios.
For the vast majority of developers, containers are enough, which is why they are ubiquitous while vms are less common. Ofc that ubiquity has led to lazy configuration, which is how the jailbreaking can occur. Knowing what you are doing with containers is a requirement to use containers as an AI sandbox.
the big thing containers don't allow is for the agent to run and use docker itself without compromising the host
I'm not sure where "vast majority" cuts in but I would say a huge number of developers use docker and it is inconvenient at best if your AI harness can't actually run and test the infra it is building against
> Only real alternative is to use microvms. My goto solution for this are apple/containers.
Why microVMs? I never ever run a container, AI harness or other, in something else than a full on VM. I could use a microVM but in any case I really don't see why I'd run a container on one of my bare metal OS: the place of a container is inside a VM (or microVM).
Especially for AI harnesses where the threat of an escape is very real: the more defense in depth, the better.
And If I can use rootless Podman instead of "rootfull" Docker, the better. Most of my containers are Podman btw.
> My goto solution for this are apple/containers.
To each his own: my goto solution is an actual server on my LAN with shitload of cores and memory and plenty of scripts to provision VMs etc.
I really don't understand why people are YOLO'ing containers on their bare metal OS.
I agree. I thought everybody knew to never use docker for high security, because it is "security lite". Might as well just use firejail. I presume that an agent knows more about networking and virtualization than I do. The only real solution is using multi-tenant level vm isolation, while presuming that the agent still might break out of their vm. So the vms need to be hosted on their own physical box that only runs the kvm provisioning host (or similar), and is firewalled on its own isolated network. It's a bit of a pain of course, but anything less feels almost like security theatre rather than meaningful to me. Otherwise you need to stick to the remote chatbots only.
multi-tenant level vm isolation does not solve, imho, specific issues like data exfiltration (ssh private key, api tokens) or privilege escalation, as the vm still contains the whole kernel and userspace inside. So breaking out of the vm may be a realistic scenario.
Yes of course, the secrets have to be isolated from the VMs, preferably at the network gateway and not on the same KVM host. But as far as I know there is no safer containerization technology than a VM, and the only way to be more secure would be to have a physical computer per agent process? A KVM does not use the host kernel and user space, and provides hardware level isolation (the CPU hypervisor etc), that's the point. I think that once you are inside of vm, just using firejail is the better approach, since you have more direct control over the OS level controls that are being leveraged by various container solutions anyways. At any rate, that's what I did.
If you can't isolate a computer on your network, you probably can't isolate your network from the internet, so it's an irrelevant exercise at that point. And yes, probably you can't do any of those things and any frontier model could technically hack your network, but I don't think there's a better way to do it?
Many thanks for the insight. Actually you are right, kvm provides a different level of isolation. If there is a better way to do it... Not sure about that. It seems this is somehow unexplored territory right now, and the current hype about frontier-models capable of """everything""" is difficult to fight against.
Entire VMs bring quite a lot overhead, though, I picture it as many agents being able to run in isolated environments in the very same dev laptop.
My current approach has been to use podman so far. It supports libkrun, so I may give a try to microVMs in my current project.
https://github.com/pjlsergeant/byre -- slightly different security model, but lazer-focused on developer experience; my daily driver and I love it not just because I wrote it. The TUI is great for configuring and setting up instant boxes just how you want
https://pleasedonotescape.com/ -- a list of every other agent jail I could find, filterable by open-source and whatever else you want
Isn't Nvidia's openshell exactly what you're looking for?
I'm asking because I'm just learning about this stuff myself and tested openshell yesterday with pi for the first time.
Eclipse Enclave does exactly that: There is an outbound firewall and secret injections, so that the agent never sees a real key. And it's fully open source: https://github.com/eclipse-enclave/enclave
What is missing in qemu + podman that we need rootful docker for this? Is there actual capability that is missing or is it more of a design choice by the eclipse enclave folks?
I use Linux Containers managed by Incus for working with Claude.
I have a dedicated container for that. It can run its own Docker daemon and other system services if needed.
Apart from the Claude login token, it has no SSH keys or other credentials. I push everything I need to it from the local machine. And I pull the Claude generated outputs from it.
Of course, this kind of setup requires a stack which can run or at least be tested without any credentials.
Love Incus and I'm using throwaway restricted projects for testing. Highly recommend incus-windows if you need to do any Windows testing. Having agents validate Windows behavior has reduced so much toil for me.
I do the same, but with pi.dev in Incus, mapping a project folder into the VM.
What I don‘t have compared to sbx is an outbound firewall, but my VM does not have any personal/interesting data, only a vanilla Fedora installation and the project dir with open source code, so I do not care much about exfiltration.
Gondolin looks interesting. It sounds like a TypeScript wrapper that achieves the same thing as my setup: Docker & Kata Containers 4 (KVM/QEMU backend) for microVMs, iron-proxy for egress and secrets, and dnsmasq for internal network name resolution (workaround for a Docker/Kata incompatibility).
It's an OS-level sandbox, though. It doesn't launch VMs or containers for sandboxing purposes; it uses whatever sandboxing features your host kernel offers.
Has egress and ingress filtering, egress can be bound to host/internet/subnet or even better to internal apps (which are each separate netns) meaning you can do your own firewall/vpn/whatever per sandbox. Plus you control what other components in the sandbox env the app can communicate with.
Really not built for day-to-day dev work though, more like automating your company/life / getting rid of SaaS (e.g. for technical Founders / Sales etc, not exactly useful for dev work)
Currently running codex. I run one sandbox per repo. So I create the sandbox in the repo root. Then it's a custom terminal preset:
sbx run --name "yoursandbox" -- --cd "$PWD"
This boots a sbx session in the worktree directory.
For Claude there is no --cd so it's more hacky, but I solved it by creating a sbx kit with entrypoint script that reads a flag (e.g --cwd) from the terminal preset command and then inside the sandbox cd's there and starts claude.
Def makes integrating easier but I try to avoid using direct mode for security (exposes .git folder, though there's probs a better way to protect it by disabling hooks or something)
Yes correct. We don't use git hooks so they are globally disabled. I also see they added host worktree mode which could work well with superset since it creates the worktrees.
We run cloud sandboxes, and have some experimental local sandbox support that is fully OSS.
Main thing for amika.dev is you can control the sandboxes and agents interchangeabley by SSH, web, or API, and can expose the services the agent is working on over signed URLs
Entire sandbox config is a TOML file
We're going to improve the local OSS sandbox mode and add better network controls over the next couple weeks.
Ultimately, what we're building kind of like if Tailscale and Firecracker had a baby, with a messaging protocol for remote controlling any sandboxed agent
It's free to try out. Still a lot to build, so we really appreciate any and all feedback about what we should focus on
Wouldn't say 'better' alternative, but I worked on making my own setup that I can trust by implementing a pi extension that leverages smolvm and agent-vault. The VM tooling is controlled by nix flakes. I can't share the source code (developed on company time), but I have a 'spec' of the whole thing, which you should be able to feed to your agent to replicate - https://gist.github.com/mahalel/c4e984292ff90bd4e11269555158...
Does secret injection really prevent that the agent send my GitHub key somewhere? If it has access to it via env var, can it not just paste it somewhere?
right, but say you give the agent access to github and it can push as you, or make a gist; now it can easily exfiltrate your secret.
And that's just an easy case - really if it has any network access at all it can come up with a clever way to route a request through the network such that the key comes back somewhere in the request. If you scan for it inbound too, the machine can obfuscate it.
Our agents are trained to be so intensely helpful and they have such intricate knowledge of how things work that they will do some incredibly clever tricks to do what you ask them to do.
The agent has no access to the secret. It has a placeholder that is replaced at a higher level. When it makes the network request the secret is substituted but that is outside of the caller's worldview.
microsandbox maintainer here. the custom certificate is installed in the guest's trusted root CA list, so it should work across any program, except where the program opts to explicitly pin certificates for a destination.
Yes, I read it. That means that it doesn’t work in those cases. Btw, as a developer it’s very easy to have something like that. It’s not as trivial as it seems at all. I encountered with similar problems all the time, with similar solutions (mainly for security theater reasons) in the past. There are websites which simply doesn’t work if you replace certificates, regardless of browser or CA for example.
Yes, I've worked with people who have run into issues with "security" solutions like ZScaler. I have tried it with some APIs (like GitHub) and it does work. Not to say it will work in your case.
At least for gondolin and microsandbox, you bind a specific secret placeholder to the target host. i.e. your GH token is only replaced/injected for calls to api.github.com, not other hosts. And you can set up both with deny-by-default
Only if the replacement is global and not, say, only looking and inserting it into the actual (eg) Authorization header. If something is only transparently altering the Authorization header, then an agent inserting the dummy value somewhere else is totally safe.
For clarity, there is no "search and replace" function going on. It's only setting the header.
The main reason a "proxy-managed" env var is set is because most CLI tools assume if the env var is set, auth is set. If the env var is unset, it will assume auth needs to occur. Fortunately, most don't do a pattern matching on what the value actually is.
You just don't inject the real secret unless hostname/whatever rule matches the request, right? I don't know if that's how this works but it's my assumption.
If you just need a python+venv sandbox with dev-first UX, no container build step needed, and no startup cost then I am using https://github.com/nzjrs/sandbubble in prod.
I havent used nor gondolin neither docker's solution, but curious to know what gondolin is missing (evaluating both for my personal use)? is it only the DX or something else, if DX, can you what exactly is missing?
In my experience it's mostly the UX/DX where Gondolin is lacking. For instance, I don't want to set up a JavaScript project every single time I need a sandbox. Instead, I just want to place a config file somewhere in my repo or my home dir and be done with it.
You can run the agent in the gondolin sandbox if you wish.
Their example implementation with pi uses a pi extension so that pi runs on the host but the read/write/bash/etc tools run in the guest. Doesn’t have to be that way though.
What I run is one hardened QEMU/KVM VM per project holding the whole dev environment (editors, agents, containers), with nftables on the host allowing internet egress but dropping anything aimed at the host, the LAN, or any other private address, plus an allowlist for deliberate exceptions.
Basically, it's a plain QEMU/KVM VM on a stock Debian cloud image: device model stripped down to a virtio disk, a virtio NIC and a serial console, nested virt off, no passwordless sudo in the guest. It also ships a containment check that scans outward from inside the guest, so the network boundary is something you can verify.
Wrapping the whole environment rather than a single agent session puts supply chain attacks inside the boundary too. A poisoned npm or PyPI package, or a compromised editor extension, lands in the VM instead of on the host. That was the original reason I set this up; agents just made it more urgent.
There's no per-domain egress allowlist; the policy is "internet yes, private addresses no". Secret injection isn't built in either, though Infisical's agent-vault on the host as an egress proxy covers that part.
Wrote the whole setup up here, in case it's useful:
Yeah I discovered your blog a few days ago: I've got a setup not unlike yours.
> So rather than pick one, this post advocates layering both, in the spirit of defense in depth: a sandbox VM wraps your containers along with the whole toolchain, and that sandbox reaches the internet but has no route to anything private.
Yup it's the only proper way.
And that is true not just for AI harnesses/agents (that shall try to escape), but also for stuff like Plex/Jellyfin/Immich/private pastebin etc.
If you care about security, there really simply is zero reason to run containers on the bare metal.
I wonder when and if microplastics will get it's Asbestos moment. Obviously they are not as carcinogenic, but it seems we don't have the full picture, and microplastics are present at an insanely higher degree than asbestos where.
Probably never. I think it's been at least a decade since the fear over them became mainstream. Yeah, it's possible these things can take time to show up but considering the scale of their presence and how long we have been using them, we would have at least seen some definite relationship between them and some serious health concern. Look at the article itself, the health impact is conveniently buried in the last section, and it just repeats over and over how they can found everywhere in the body but nothing on what can possible happen.
So much of the scare revolves around the same framing, "microplastic" have been found in breast milk/blood whatever, but never seen one mentioning what it can possibly cause. Is it too hard to fathom that the answer is "nothing"?
Not as long as there are powerful car lobbies and the main source of microplastic will remain car tires.
Instead, you have articles like this trying to tell people to look away from that main source of problem, and blame, say, indoors or food preparation, and skip details like how the homes with the most microplastic in them are… close to the highway.
Given the fact that they are so ubiquitous and yet no causal relation between microplastics and any health issue whatsoever has been identified in any rigorous study until today [1], I'd say a lot of this reporting is fear mongering by the eco/organic industry, aimed at gullible people who know very little about science. Not as insane and unphysical as electro smog, but definitely nowhere near asbestos. The linked article even goes into detail how warped the perceptions are among the general population and how doctors should educate people better, because there are real risks from other things out there. If you're really concerned about health effects of common pollutants, there are much bigger risks with actual proven causal effects in everyday compounds.
> BPA is a known endocrine disruptor. Although initially considered to be a weak environmental estrogen, more recent studies have demonstrated that BPA may be similar in potency to estradiol in stimulating some cellular responses.
> In 2017 the European Chemicals Agency concluded that BPA should be listed as a substance of very high concern due to its properties as an endocrine disruptor.[30] In 2023, the European Food Safety Authority re-evaluated the safety of BFA and significantly reduced tolerable daily intake (TDI) to 0.2 nanograms (0.2 billionths of a gram), 20,000 times lower than the previous TDI from 2015.
> In 2012, the United States' Food and Drug Administration (FDA) banned the use of BPA in baby bottles intended for children under 12 months.[31] The Natural Resources Defense Council called the move inadequate, saying the FDA needed to ban BPA from all food packaging.
> This followed another paper in early 2024, where a group of Italian researchers identified microplastics in plaques found in the carotid arteries – a pair of major vessels which deliver blood to the brain – of people with early-stage cardiovascular disease. This linked their presence to worsening disease progression. Over the following three years, individuals carrying these microplastics in their plaques had a 4.5-fold greater risk of stroke, heart attack or sudden death.
> Then in February 2025, another group of scientists identified microplastics in the brains of human cadavers. Most notably, those who had been diagnosed with dementia prior to their death had up to 10 times as much plastic in their brains compared to those without the condition. "We were shocked," says Matthew Campen, a University of New Mexico toxicology professor who led this study.
This is exactly the kind of fear mongering reporting I was talking about and explains the general public's warped perception described in the research review I linked above. If you look at the brains of dead people with dementia, you'll also find more aluminum, which has caused people to panic about antiperspirants. But there is zero actual causal evidence that Al exposure causes dementia, if you do the science right. The same goes btw. for amyloid plaques, which has actually hindered real Alzheimer's research. So not even scientists are safe from the correlation!=causality problem. You can make up all kinds of potential hazards by comparing similar molecules and inventing bioavailability pathways. But at the end of the day this is just speculation and you need hard data to prove these assumptions.
The aluminum relations are easily explained with the observation that healthy kidneys excrete aluminum well, whereas unhealthy kidneys don't and so it accumulates. There might also be similar variations in aluminum deposition in the brain depending on the brain's innate ability to wash out chemicals. In contrast, the excretory mechanisms of plastics seems less trustworthy.
The user is deliberately and blatantly ignoring a wealth of scientific literature that exists. Also, plastics come bundled with numerous other harmful classes of chemicals, e.g. phthalates, bisphenols, etc. The risk is not merely in the brain, but also in blood vessels, including those adjacent to the heart.
Beware the plastics industry shills on this page. They will have you ignore the science, become infertile, and then have you die, all for their temporary gain.
It doesn't change the fact that there is no actual causal evidence. Perhaps the demented brains simply suck at flushing out microplastics as well. If you ever find people with more microplastics exposure have more dementia (like they did for asbestos and lung cancer), then you're onto something. But no rigorous study has found this yet. And if they do, you will hear of it immediately for sure, given how much reporting there is for microplastics=bad for you.
Strictly speaking, there is no “actual casual evidence” for anything, because there is hardly any stable definition for what casual evidence exactly is. Establishment of causality is commonly considered as requiring repetition and probabilistic reasoning.
In plain words, it’s your guess against theirs, except they had done research and published a paper with a claim and you are simply saying they are not rigorous enough. Could you point to more rigorous support of your claim?
This was in mice that were given up to 1000 mg/L of microplastics in their drinking water. If you have this level of contamination, you probably should stop whatever it is you are doing anyways, disregarding your testicles. But even then, there is no evidence for this in humans. Research shows that most microplastics simply passes through your digestive system unhindered.
Yeah, typically we test adverse effects in mice before doing trials on larger animals.
That we haven't observed such extreme behaviour in a scientific way in humans doesn't mean it isn't there, it's just that we haven't yet scientifically observed anything. That there is some evidence in favour of it having adverse effects somewhat defeats the idea that it's "provably non-harmful", which is your current stance.
It might be interesting; instead of downplaying the harm, to see if we can observe any patterns that fit with these findings over the course of human history with the introduction of microplastics...
and if we were to do that, we'd find some interesting correlation, even if it's not provably causation yet.
Sorry, I still subscribe to science and not speculation. But I guess I am increasingly alone with that idea on HN. And to be clear if someone points out a rigorous causal link, I'd be onboard immediately. But this purely speculative fear mongering based on random scientific observations targeted at non-scientists is similar to what you see in the homeopathy and energeticism circles. Except noone here would believe that 5G makes you sick, because techies know at least this kind of science a little bit.
Then please link to it. I'm still waiting for a causal health issue meta analysis that disagrees with me. Shouldn't be hard, if "the science" as you call it has come to a consensus. But I have only seen wild speculation so far like the one linked here.
- Microplastics found in every human testicle sampled, at 3x the concentration of dogs, with PVC correlating to lower sperm count in canines: https://pubmed.ncbi.nlm.nih.gov/36948312/
- In-vitro exposure of human semen to polystyrene MPs showed time-dependent decline in motility and increased DNA fragmentation: https://www.mdpi.com/2305-6304/13/7/605
The mouse study I linked earlier isn't the whole picture; it's one piece. The "no human evidence" line was maybe defensible in 2022. It isn't anymore.
Also, re: "1000 mg/L is unrealistic".. the study used two doses, 100 μg/L and 1000 μg/L. Raw surface water in Amsterdam has been measured at ~50 μg/L. The lower experimental dose is well within an order of magnitude of real-world contamination. That's how dose-response science works.
You'll excuse me if I only explain the first one, since the others seem redundant (not to say suspiciously redundant if you look at the authors). And none of this is a meta review like I asked, but I'll let it slide this time.
First:
>no significant association was found between MP exposure and sperm concentration or total sperm count
Second: N=34
Third (if second didn't give it away): The one effect they did find sits at p=0.056. That means one in 18 random studies will find that effect just because of probability statistics. And as you have nicely pointed out, there are maaaany studies like this out there. You just don't find all the null results if you go into research with your mindset. But that is exactly what differentiates a scientist looking for truth from a hobbyist trying to argue on the internet.
It found microplastics caused a decrease of 5.99 million/mL in sperm concentration, 14.62% in sperm motility, 23.56% in sperm viability, and a 10.65% increase in sperm abnormality rate. (I copied and pasted these values directly from the source).
You said you'd be "onboard immediately" if someone showed you a rigorous causal link. This is a meta-analysis with an adverse outcome pathway mapping the causal chain from molecular initiating event (ROS) through to tissue-level damage. That's about as rigorous as it gets before human clinical trials, which (for obvious ethical reasons) nobody is going to run.
As for the p=0.056 critique: you picked the weakest single data point from one of four links and declared victory (scientific!). The in-vitro study I linked exposed actual human semen to microplastics under controlled conditions and observed time-dependent decline in motility and increased DNA fragmentation. That's not a simple correlation, it's a direct causal experiment on human tissue. You didn't address it.
The goalposts have moved from "show me evidence" to "show me a meta-review" to "well not THAT meta-review." At some point you have to engage with what the research actually says rather than with what you'd like it to say.
Doesn't this one directly contradict the other one you linked? What is it now? How is my sperm in danger!? Please Mr. Googlescienceman! Oh god! I'm so confused! I can't take it anymore. Please just tell me what brand of air filter and plastic free clothes I need to buy!! Perhaps I should ask the all mighty google AI overview...
Edit: Oh - lol XD. It literally just told me the science has found no causal link for microplastics harm. Hm. I guess you are just better at researching random studies than us mortals with stupid science degrees and hyped summary machines.
A single study with N=34 finding no significant effect on sperm count doesn't contradict a meta-analysis of 39 studies that did. That's what meta-analyses are for: aggregating underpowered individual studies into something statistically meaningful.
You know this if you have the science degree you're claiming.
As for Google AI Overview: if that's your standard of evidence now, we've come a long way from 'I subscribe to science.'
reply