Agents need real sandboxes

At AI DevCon London I gave a talk with a slightly silly title: "You're Absolutely Right, It Was Your Home Directory!"

It got a few laughs because the scary version is easy to imagine. You give a coding agent a task, enable the convenient mode where it stops asking for permission every five seconds, and then it confidently does something wrong.

Like deleting your home directory. Hi, gpt-5.6 Sol 👋.

The less funny version is broader than deleting files. It is the agent sitting on the same machine as your source code, API tokens, SSH keys, browser state, local databases, internal docs, test credentials, and the rest of the developer-machine archaeology.

I work at Docker on developer tooling around AI, and one of the things we have been working on is Docker Sandboxes: isolated microVM environments for running coding agents locally. The talk was about local agent isolation: what agents should be able to do, what they should not be able to touch, and why prompt-level guardrails are not enough once the agent can act on your behalf.

Tessl also turned the AI DevCon talk into a skill your agent can use as context: talk-selajev-docker-sandboxes-agents. Or, if you prefer the old-fashioned way, make your agent watch the recording: https://www.youtube.com/watch?v=bFBNXIoLkW4.

Autonomy changes the threat model

We want agents to do more work for us. Otherwise we would just keep autocomplete and call it a day.

But the more useful an agent becomes, the more responsibility it takes automatically. The blast radius grows with it, because "helpful" means "able to act."

Productivity is a spectrum. On one end you have autocomplete and chat assistants. They suggest code, you inspect it, and you decide what to paste, run, or commit. The human still performs most of the actions.

On the other end you have agents that get a goal and figure out the path. They inspect files. They run commands. They install packages. They start services. They retry when something fails. They read logs. They rewrite code. They may even coordinate with other agents.

This direction is useful, and it is where the old local-development threat model stops fitting.

More autonomy means more actions taken on your behalf. Fewer approval prompts means fewer chances for a human to notice that something is weird. Local execution means the agent is close to the files, tools, tokens, and environments developers use every day.

In the talk I referred back to Liran Tal's security session, because the same risk model applies. Things get dangerous when three ingredients meet:

• private data;
• untrusted content;
• external communication.

Private data is your code, local files, credentials, API tokens, config, and company context. Untrusted content can come from prompts, issues, pull requests, emails, documents, repositories, or websites. External communication is the agent pushing, uploading, posting, calling APIs, or sending requests somewhere.

Once an agent can combine those three, a sentence in a prompt is not a security boundary.

The agent is not the boundary

A prompt can guide an agent. It cannot enforce filesystem access. It cannot enforce network access. It cannot keep a secret out of a process environment. It cannot prevent a tool from being called if the tool is available and the runtime allows it.

Instructions are useful. Enforcement has to live outside the model.

One part of the demo made this very visible. I gave an agent enough local skills to do dangerous things: edit CLAUDE.md, look for secrets, inspect SSH keys. Then I asked it to write a Python script that did the same thing.

It wrote the script. Then it refused to run it.

Fair enough. The guardrail had noticed the shape of the action. So I changed the shape: put the dangerous code into a module, then write a boring main.py that imports and uses the module.

The agent still built it. It still refused to run it.

Then I cleared the context and asked it to run the program.

It ran very, very fine.

The model did not become evil. It did not need to. The guardrail lived in the conversation, and the conversation changed. The environment still had the files, the tools, and the ability to execute the code.

"Please do not touch this" and "you cannot touch this" are different controls.

For an individual experimenting on a personal machine, maybe this is a risk they knowingly accept. For a company enabling coding agents across many developers, "the agent was told to behave" is not a control.

The agent should be able to work unbothered inside a boundary that does not depend on the agent obeying itself.

Containers are useful, but agents are weird workloads

The obvious first idea is: put the agent in a container.

Docker knows containers pretty well. Containers are a good answer for many software problems. They are excellent for packaging applications, running dependencies, and creating repeatable environments.

Agents are a bit different from packaged applications.

A normal container usually starts from something known. You know what went into the image. You can inspect the Dockerfile. You can produce an SBOM. You can reason about the thing you are about to run.

An agent changes the environment while it works. It installs tools. It writes scripts. It starts services. It edits the workspace. It may build and run more containers. It turns the environment into a temporary development machine.

Then there is the isolation boundary. Containers share the host kernel. That may be a completely acceptable tradeoff for many workflows. But when we talk to enterprise security teams about autonomous agents running near sensitive developer environments, containers alone are not the boundary they usually want.

That is where microVMs come in.

A microVM gives you a stronger isolation boundary while keeping the workflow close to what developers expect. The agent still gets a useful Linux environment. It can still build, test, install packages, and run tools. But the host is no longer one bad tool call away.

A sandbox still has to be useful

This part matters more than security people sometimes like to admit.

If using the sandbox is miserable, developers will bypass it.

A useful agent sandbox has to give the agent enough room to do real software work. It should be able to inspect the project it was given, run builds, execute tests, start dependent services, and use containers inside the isolated environment when the workflow needs that.

The interesting part is what it does not get by default.

It should not get arbitrary access to the host filesystem. The user should choose what is shared. Network requests should be observable and controllable. Secrets should not be copied into random files the model can read. If the agent damages the sandbox, you should be able to throw it away and create a fresh one.

That is the balance I want: useful enough that people keep using it, constrained enough that a weird agent run does not become a weird host-machine incident.

In the live demo I showed the command-line experience of dropping into a familiar agent interface inside the sandbox. Nothing about the UI needed to look exotic. The agent should still feel like the agent you already use, just running somewhere less precious than your host.

It can build, test, explore, and make a mess. It just makes the mess somewhere disposable.

The agent gets capability, not custody

Developer machines are full of real credentials. Sometimes intentionally. Sometimes historically. Sometimes because that one CLI setup guide from 2021 told you to put a token in a file and now nobody remembers it exists.

So the sandbox should not solve auth by copying secrets into the agent-visible workspace.

The pattern I described uses sentinel values and a security proxy. The agent can operate as if it has the capability it needs, but the real credential is injected outside the sandbox boundary when a request goes to an approved service.

The secret does not need to sit in a file the agent can read.

The useful mental model is: the agent gets capability, not custody.

The same idea can apply to larger trusted workflows. Commits, code signing, provenance metadata, and other sensitive operations can happen outside the sandbox or through controlled paths. The agent gets enough power to complete the task. The organization keeps the most sensitive material away from the model-visible environment.

That is how you make an agent useful without handing it everything.

Empty sandboxes do not survive contact with developers

Developers spend years shaping their machines. Compilers, package managers, CLIs, caches, credentials, dotfiles, project conventions, that one tool installed with curl | bash three jobs ago. A clean sandbox can feel like starting from nothing every time.

If that is the experience, people will run the agent outside the sandbox the moment they are under pressure.

One answer is to build a huge base image with everything in it. That works for a while. Then the image gets too large, too slow, too generic, and too annoying to maintain.

The approach I showed is sandbox kits.

A kit is a declarative way to configure a sandbox. It can define commands to run, files to place in the environment, processes to start, network policy, and secret-handling configuration. It can be local, or it can be shared as an OCI artifact.

If you have used devcontainer features, this should feel familiar: reusable environment configuration layered on top of a base. With agents, the kit also has to care about network access and secrets. Convenience is only half the job here.

In the demo I used a Testkube kit to show the idea. The larger point is that vendors and platform teams can provide kits for the tools developers actually need: testing platforms, cloud CLIs, language toolchains, data systems, internal services, whatever makes the sandbox feel like a real place to work.

There are public examples in docker/sbx-kits-contrib, and Docker's docs also have kit examples plus a guide for building an agent kit.

Sandboxing should fit into existing tools

A sandbox should not become a separate ritual.

Developers already live in terminals, editors, issue trackers, CLIs, and pull requests. If running an agent safely means leaving that flow and doing ceremony, people will do it once for the demo and then stop.

Command-line ergonomics matter. IDE integration matters. When a developer opens an agent pane in VS Code, IntelliJ IDEA, Zed, or another editor, the agent should be able to run inside the sandbox rather than directly on the host.

The experience should stay close to normal. The isolation boundary should change underneath.

Containers taught us this already. They became widely adopted because they eventually became practical, repeatable, and integrated into everyday development workflows. Agent sandboxes need the same ergonomics, with a stronger boundary and controls that match autonomous work.

Sandboxes limit blast radius, not every risk

Sandboxing gives you a boundary. I tried to be careful about this in the talk.

A sandbox helps with local-machine blast radius. It gives you a place to enforce filesystem access, network paths, credential handling, and disposable execution.

Application-level permissions still matter.

If you give an agent permission to read and write email, someone may still try to influence the agent through email content. If you give an agent broad access to a SaaS app, the SaaS permissions still matter. If an agent can open pull requests, merge policies still matter. If an agent can call production APIs, please do not pretend the sandbox has solved production governance.

Sandboxing should sit next to tool controls, product permissions, logging, approval policies, and security review.

The useful part is that the boundary moves out of the prompt and into infrastructure.

That was the argument I brought to AI DevCon London: local coding agents need real sandboxes because useful autonomy requires real boundaries.

If you run agents locally, try this exercise: ask what the agent can read, what it can change, what network it can reach, and where its credentials live.

If the answer is "my whole machine," you do not have an agent setup. You have a trust exercise.