I'm OK with the attribution, but I just didn't like a session URL appearing on a public repo all of a sudden. I was left wondering "did I just leak my private session?"
I don't understand why it isn't opt-in. Or at least a heads-up somewhere.
At this point it's believable to me that Anthropic might not even be aware of what features get added in a given release. It's hard to tell the difference between "they actively are against documenting all of the defaults they keep changing" and "they genuinely don't even pay enough attention to notice when their vibe-coded changes have changed a default". Functionally they're the same, and both would stem from similar (lack of) values, but I think it does kind of matter because it's essentially the difference between explicitly crafting an experience for users versus defining same things they want and letting the vibes end up driving it towards a bunch of user-facing emergent properties that no one has considered.
"Of course they were intentional in adding in an ad to everyone's git log" honestly night be the less cynical take, because the alternative is assuming that they actually look at git logs ever rather than only having Claude deal with it.
I searched for "times new roman" for some reason, and noticed the whole results page was rendered in that font. I knew there were easter eggs on the page, but I was surprised by the sheer number of them.
I noticed the same thing with email-decode.min.js on my site. It turns out it's the "Email Address Obfuscation" feature, which I didn't expect to be on by default.
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.
Same here, so I ended up moving the whole dev environment (editors, agents, containers) inside a hardened QEMU/KVM VM that reaches the internet but has no route to the host, the LAN, or any other private address. I wrote a script to create such VMs and also verify network containment by scanning outward from inside the guest. Even then, I still don't feel great when running agents unattended.
I do something similar and I've also got a nice script to provision my VMs.
> 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.
It's the first thing the biggest devops guru I know advised me to do. He told me to always ever ever run my containers inside VMs. I religiously followed his advice ever since and I couldn't be happier: I was already doing it before the AI days, to run "normal" containers. Now with these insane agents trying to break out, I'm happy that it's second nature to me.
It's funny that, just like you, I'm using IPv4-only too for those VMs.
I tried GPU-passthrough as a proof-of-concept (worked fine) but I've got no use for it yet.
FWIW all my VMs are running on a 10 years old Xeon / 14 cores / 28 threads / ECC RAM. That's where the agents live.
Thanks for the link to your write-up, very interesting to read from like-minded people and see what's similar and what's different in their solutions.
> Now with these insane agents trying to break out, I'm happy that it's second nature to me.
FWIW, the cases of these agents "breaking containment" is not someone asking "Create space invaders in HTML, CSS and JS" and the agent breaking out of containers and VMs to destroy the user's computer. They're effectively asking the agents "Answer question X, find the answer in any way you deem possible and applicable" during evaluations and letting them run for days, hoping the agents come up with their own strategies, which sometimes results in "cheating" like getting internet access to query public datasets, and similar stuff. And in this case, getting access to production databases to look up answers :)
As long as your filesystem is disconnected from the container you run (so no synced/mounted volumes, instead copy stuff in, copy stuff out), you're safe just running agents in the container without full VM isolation.
Thanks. Like you, I'd been running containers inside VMs for a while before the agents. Turns out it's right for them too. Making it IPv4-only simplified the firewall rules and network containment check, and made the boundary easier to reason about.
Posted this because I saw a piece of the cable at the Science Museum in London years ago. It looks like it's still on display in the Information Age gallery:
This assumes one-shot generation. I don't use it that way, and I don't think many people who find it useful do.
I use it as a colleague I'm drafting with. I'll ask how a sentence lands, tell it to make a paragraph more friendly or more dramatic, have it argue against a point I'm making. The piece comes together over many turns, and the information arriving in each turn is mine — it's not expanding one prompt, it's helping me converge on something.
The information-content framing also proves too much: a copy editor adds no information either. Neither does a translator, or a ghostwriter. What they add is form, and form is most of what makes writing good or bad.
Many people make the mistake to think LLMs are stochastic parrots, but they are more like pianos, you play the keys and they make music, if you don't bring no new spices to the soup no wonder it comes out bland.
Frontier agents are already compressing the dev loop with humans in it, and as the article notes, compression alone can be exponential enough to matter. Walking vs. driving is a nice analogy.
Nice paper. They predict the outcome of edits up to ~25 steps before the agent makes them. Decodable doesn't mean causal, as the authors note, but a cheap probe that flags doomed trajectories early could save a lot of wasted agent compute. We clearly still have a lot to learn about what these models represent internally.
I don't understand why it isn't opt-in. Or at least a heads-up somewhere.