Everyone's tweeting "we sandboxed the agent" as a joke, so I tried to break mine by taking the container my coding agent runs in and ran escape attempts against it.

Before we dive into the results, some catchup:

Partner with us

Axern

Open-source sandboxes for running AI agents and untrusted code, plus durable services. Apache-licensed, backed by the cofy-x org.

Opendot

A terminal AI agent where every file and shell action is snapshotted and reversible, so you can fully undo a session. Model-agnostic, connects to MCP servers and 1000+ app tools,

Human-review

A visual tool to edit HTML and Markdown and leave Google-Docs-style comments that get sent back to your AI agent. Works inside existing agent harnesses,

Juror

An open-source code-review tool that runs on your own GitHub Actions, positioned as a cheaper Greptile alternative, MIT-licensed.

The target was the sandbox, the same isolated environment my agent gets dropped into every session. 

Five vectors:

Same brief to both: add recurring tasks with automatic next-occurrence generation on completion. Full diff required, tests included.

Full root and near-complete capability set. On a normal box this is game over, you own the host. So the interesting part is what "the host" is.

A Firecracker microVM, the same hardware-level isolation that AWS Lambda and Fly.io run on.

Root inside this guest gets you the guest, and nothing more. The wall to the host is enforced by the hypervisor, which your root privileges inside the guest can't touch.

If your agent sandbox is a plain Docker container and the agent gets root, you're one namespace away from the host kernel. 

Check what your sandbox is before you trust "it's containerised" as a safety claim.

Blocked domains get denied at the proxy with a reason header. 

That tells me something useful, because a timeout or a DNS failure could mean anything went wrong. 

A 403 with host_not_allowed means someone wrote a rule and the rule fired.

I think this is the single most important test on the list.

An agent that can reach any IP on port 443 can send your data anywhere.

--network=none with an explicit allowlist is the one control that matters if the model gets prompt-injected mid-task, because everything else assumes the agent stays inside the lines voluntarily.

The obvious target is 169.254.169.254, the address every cloud SSRF writeup goes for, because it's how you steal instance credentials without touching a real endpoint. 

So I tried it, then tried to sneak past the filter with raw and encoded IPs.

Every version failed the same way. The proxy checks the destination IP, so skipping the hostname buys you nothing.

This test separates a legit allowlist from a cosmetic one.

A lot of setups filter on the Host header, which does nothing when you make a raw IP request and skip the header entirely. 

This one filters at the network layer, so the Host header is irrelevant.

If you're building your own allowlist with an if host in allowed_list check in your application code, this is your gap. 

Test it with a raw IP before you ship it.

The mounted paths that should be read-only are locked at the filesystem level, but /etc was fully writable. As root, I could write anywhere in the guest's own root filesystem.

That looks like a hole until you remember what the guest filesystem actually is: ephemeral storage inside the microVM. 

Writing to /etc doesn't reach the host, doesn't persist after the session ends, doesn't leave. The security boundary is the VM wall from test 1 and the network wall from tests 2 and 3.

Permissions inside a disposable guest are a convenience, never the thing keeping you safe.

Ask whether what the agent writes can leave the box or phone home. If it can't, root inside the guest stops being interesting.

Nothing I tried got out.

The design stacks three boundaries that work independently, so breaking one doesn't hand you the other two.

Full root and a near-complete capability set inside the guest turned out to matter very little once I realised the guest was designed to be disposable.

The walls that counted were around it.

The meme resonates because most agent sandboxes I've looked at are one Docker container with default flags. The agent can reach any IP it wants, and the only thing between it and the host kernel is a namespace. 

A folder with extra steps.

Most agent builders I talk to aren't thinking about it that way yet. 

They treat the sandbox as a deployment convenience, and the ones who are thinking about security are filtering hostnames in application code and calling it an allowlist.

That gap is going to close, because it has to. 

The moment agents start handling real credentials and customer data in production, and a few already do, the conversation shifts from "did you sandbox it" to "prove it." Infra providers who figured this out early, 

Firecracker-grade isolation, network-layer enforcement, real deny responses, are going to set the floor. 

Everyone building on a naked Docker container will have to catch up or explain why they didn't.

(Whether that shift happens because of an incident or because enterprise procurement starts asking the right questions, I don't know, but it's coming.)

Until next time,
Vaibhav 🤝🏻

If you read till here, you might find this interesting

# Partner 1

For its first CTV campaign, Jennifer Aniston’s DTC haircare brand LolaVie had a few non-negotiables. The campaign had to be simple. It had to demonstrate measurable impact. And it had to be full-funnel.

LolaVie used Roku Ads Manager to test and optimize creatives — reaching millions of potential customers at all stages of their purchase journeys. Roku Ads Manager helped the brand convey LolaVie’s playful voice while helping drive omnichannel sales across both ecommerce and retail touchpoints.

The campaign included an Action Ad overlay that let viewers shop directly from their TVs by clicking OK on their Roku remote. This guided them to the website to buy LolaVie products.

Discover how Roku Ads Manager helped LolaVie drive big sales and customer growth with self-serve TV ads.

The DTC beauty category is crowded. To break through, Jennifer Aniston’s brand LolaVie, worked with Roku Ads Manager to easily set up, test, and optimize CTV ad creatives. The campaign helped drive a big lift in sales and customer growth, helping LolaVie break through in the crowded beauty category.

Learn more.

# Partner 2

Most e-commerce sellers juggle 6–8 tools and pay hundreds monthly to keep operations running. StoreClaw replaces the stack with one autonomous AI engine that monitors competitors, optimizes listings, automates marketing, and tracks profit 24/7. Connect your store and let AI handle the work — no prompts, no complex setup, no credit card required.

Try if for free today