Docker Is Not Just a Container Company Anymore

I’ve been in the Docker community since 2015. I’ve written more docker run tutorials than I can count, and I still get people in the Collabnix Slack asking me which base image to use for their Spring Boot app. That question is still valid. But it is no longer the most interesting question Docker answers.

Here’s what I keep running into at meetups and workshops: developers who last looked closely at Docker in 2023 assume the roadmap is still “faster builds, smaller images, better Compose.” Then they open the docs in 2026 and find pages titled “Can I run my AI agent in a sandbox?” and wonder whether they’ve landed on the wrong site.

They haven’t. Let me explain what actually happened, because I don’t think it’s a pivot. I think it’s the same product with a different problem in front of it.

What Docker was actually building all along

Strip away the tooling and Docker has always built two things for developer communities: a packaging format, and a trust boundary around code you didn’t write.

That second one gets less attention than it deserves. The reason containers won wasn’t just reproducibility. It was that you could pull a Postgres image off the internet, run it on your laptop, and be reasonably confident it wasn’t going to scribble all over your home directory. Namespaces and cgroups gave you a boundary that was good enough for the threat model of the time.

And that threat model was very specific: the untrusted thing was a dependency. It was a library, a base image, a transitive npm package. It was code that sat still. You could scan it, sign it, pin it, and once it was running, it did roughly what it did yesterday.

That assumption is dead. The untrusted thing now writes code, installs its own packages, calls tools over the network, reads your .env file, and does all of that in a loop, at machine speed, based on text it read from a GitHub issue five seconds ago.

Containers were not designed for that. And Docker, to its credit, said so out loud rather than pretending a --read-only flag was going to hold.

Why “just put the agent in a container” doesn’t work

I’ve written about this before under the title “A Container Is Not a Sandbox,” and it’s the sentence I repeat most often in workshops. Two reasons it matters here:

One: the kernel is shared. A container is a process with a fence around it. The fence is enforced by the same kernel the host is running. A kernel escape in one container is a host compromise. For your own microservices that’s an acceptable risk. For code an LLM generated thirty seconds ago after reading an untrusted webpage, it isn’t.

Two and this is the one people miss – containers assume immutability. The entire mental model is: build the image, freeze it, run it, throw it away. Agents violate that on purpose. An agent’s whole job is to mutate its environment. It pip installs things. It writes files. It clones repos. The immutable-artifact model doesn’t just fail to secure that, it doesn’t describe it.

So the boundary had to move down a layer.

Pillar 1: Agent Sandboxing

Docker Sandboxes (the sbx CLI) gives every agent session its own microVM ~ its own kernel, running on hardware virtualisation, with its own Docker daemon inside it. A kernel exploit inside the sandbox does not reach your laptop. That’s a hard boundary, not a policy suggestion.

%  sbx exec catalog docker info -f 'sandbox daemon: {{.ID}} @ {{.Name}}'
Sandbox catalog started successfully
sandbox daemon: d8cb455c-bd7b-47fe-a417-557f123c2b59 @ catalog

But the isolation is the boring part. The interesting part is what crosses the boundary, and how deliberately you have to ask for it:

Filesystem. The agent sees the directories you mounted. Not ~. Not ~/.ssh. Not the sibling repo with the production Terraform state.
Network. Egress runs through a proxy with an allowlist. The agent reaches what you allowed and gets a denial for everything else and the denial is logged.
Credentials. Secrets are imported into the session explicitly and scoped to it. In recent versions this got stricter: sbx stopped auto-inheriting your host environment variables, which broke a few of my scripts and was absolutely the right call.

Here’s the shape of it in practice:

# Create and run a sandbox with claude in current directory
sbx run claude

# Create and run with additional workspaces (read-only)
sbx run claude . /path/to/docs:ro

# Nothing gets out until you say so
sbx policy allow network api.github.com

# Secrets are imported deliberately, not inherited
sbx secret import github  # reads GH_TOKEN / GITHUB_TOKEN from your env
sbx secret import # scans & prompts for all known services

# Manage persistent access policies for sandboxes.
sbx policy log

That last command is the one I’d point a skeptical security team at first. Not because deny-by-default is novel, but because the audit trail is a byproduct of the enforcement, not a separate logging agent you have to install and hope stays running.

There’s an extensibility story too, sandbox kits, which are declarative mixins that install tooling, wire up MCP servers, and configure credentials so a fresh sandbox comes up productive instead of empty. I’ve built and published several (Mem0, Firecrawl, SurrealDB, Dagger, Grafana, Dynatrace among them) and the community catalogue is growing fast. If you’ve written a Dockerfile, the kit spec will feel familiar within about ten minutes.

Pillar 2: AI Governance

Sandboxing solves one agent on one laptop. It does not solve an organisation.

This is the gap I keep arguing about, including with a well-circulated LangChain piece from June that laid out a five-property checklist for choosing a sandbox. The checklist is fine. It’s also scoped to a single sandbox, chosen by a single developer, configured by that developer, on that developer’s machine. That is not a security posture. That’s a personal preference with a config file.

Docker AI Governance is the control plane on top: policy defined once in the admin console, pushed to every machine where an agent runs, enforced at the runtime layer rather than as advice the agent could be argued out of.

The framing Docker uses is blunt and I think correct ~ your laptop is the new production. An agent on a developer machine is reaching private repos, production APIs, customer records and the open internet, often inside a single session, using that developer’s real credentials. Endpoint tools can’t see it. Cluster tools don’t reach it. Cloud security tools live in neither place.

Three things this covers in practice:

Sandbox policy ~ what the agent can mount and reach, set centrally, synced at docker login, taking precedence over local config.
MCP tool governance ~ which tools an agent can actually call, allowlisted by expression rather than by trusting whatever the model decided to invoke.
Audit and visibility ~ and as of early August, policy decisions stream into your SIEM. That’s the unglamorous feature that turns this from a developer tool into something a CISO will sign off on.

The MCP piece deserves emphasis. The public MCP ecosystem is enormous and largely unreviewed, tool-poisoning research has embarrassingly high success rates against real servers, and malicious “skills” have already been found at scale in agent marketplaces. Application-level guardrails do not save you when the tool surface itself is compromised. You need a chokepoint below the app, which is what the MCP Gateway is: one point where every tool call is authenticated, authorised, and logged.

Pillar 3: The supply chain the agent pulls from

Isolation and governance both assume the stuff inside the sandbox is worth running. So the third leg is Docker Hardened Images ~ minimal, low-CVE, attested base images, with the same hardening methodology now extended to MCP server images.

This is where the “Docker is still a container company” thread genuinely continues, because DHI is a container supply-chain product. But watch how it composes: the agent runs in a microVM, its tool calls route through a governed gateway, and the images it pulls come from a hardened catalogue whose CVE data it can query directly through the DHI MCP server. Agent asks “is this image safe,” gets an attested answer, and the whole exchange is logged.

Three separate products. One story.

The part nobody talks about: the model doesn’t have to leave

One more piece that reframes things. Docker Model Runner serves local LLMs over an OpenAI-compatible API. Combine it with a sandbox and you get a pattern I’ve tested end to end and now demo constantly:

Agent in a microVM. Model on the host. Nothing leaves the machine.

You allow the sandbox exactly one network destination ~ the local model endpoint and the agent talks to it across the VM boundary as if it were OpenAI. No API keys. No tokens crossing the internet. No prompt content in a vendor’s logs. Every call visible in the policy log.

For anyone in a regulated industry who’s been told “we can’t use coding agents, the data can’t leave,” that architecture is worth an afternoon of your time.

Try it yourself in thirty minutes

Don’t take my word for any of this. The fastest honest test:

Install sbx and start a sandbox scoped to one throwaway repo.
Run your coding agent of choice inside it.
Ask it to do something mildly aggressive ~ install packages, hit an external API.
Run sbx policy log and read what it tried to do.

Step four is the one that changes minds. Most people have never actually seen the egress list of an agent they’ve been running unsandboxed on their work laptop for six months.

Where I’ll be honest with you

I work at Docker. So let me hand you the counter-arguments before someone else does.

The MCP gateway space is crowded. Cloudflare, Kong, Bifrost, Azure API Management all make overlapping claims. Docker’s structural argument that governance belongs to whoever owns the runtime executing the agent, and that Docker is that runtime on the laptop, in Kubernetes, and in the cloud is a real argument, but it’s an argument, not a fact.

MicroVMs cost something. Boot time and memory overhead versus a plain container are real. For most agent workloads it’s noise. For some it won’t be, and you should measure rather than assume.

None of this is finished. Scoped, trustworthy agent access to sensitive services is still an unsolved problem across the whole industry. Sandboxing contains the blast radius. It does not make the agent trustworthy.

And containers didn’t go anywhere. Compose is still how most of us run local stacks. Buildx still matters. If your job is shipping a Django app, none of this is urgent for you yet.

The one-sentence version

Docker didn’t stop being a container company. It noticed that the thing worth containing stopped being a dependency and started being an autonomous process with your credentials, and it moved the boundary down a layer to match.

If you’ve been evaluating “which sandbox should I use for my agent,” you’re asking a 2025 question. The 2026 question is: who sets the policy, where is it enforced, and can you prove afterwards what your agents actually did?

That’s a different product category. Docker just happens to have arrived at it from the container side.

Want to learn more? Come, visit me at WeAreDeveloper Conference this September 23-26 to learn more about Agentic AI and security, Docker Sandboxing and AI Governance