Docker published a post this week about AI Governance, and my first reaction was not "cool, Docker has an AI feature now."
My reaction was: of course this is where the market goes.
Not because Docker magically solves AI safety. It does not. But because the moment you let agents do real work, the boring container questions suddenly become interesting again:
- What files can this thing read?
- What network calls can it make?
- Which secrets are visible?
- Can it install packages?
- Can it write outside the workspace?
- Can I reproduce what happened after the fact?
That is not a chatbot problem. That is a runtime problem.
And containers have always been a runtime-shaped answer to uncomfortable runtime questions.
agents made isolation feel urgent again
For a while, containers were boring in the best possible way.
They became part of the furniture. Build image, push image, run image, deploy image. Kubernetes made them infrastructure. CI made them muscle memory. Local dev made them annoying, then necessary, then invisible.
But AI agents change the emotional temperature around containers.
A normal application is dangerous in a relatively predictable way. It has code. It has dependencies. It has configuration. It does what the humans shipped, plus whatever bugs the humans accidentally shipped.
An agent is different. An agent is a loop with tools. It observes, decides, calls something, reads the result, and decides again. If you give it a shell, a filesystem, network access, credentials, package managers, browser automation, and a vague instruction like "fix the failing tests," you did not just give it a productivity tool.
You gave it a small operating entity inside your engineering environment.
That sounds dramatic, but I think it is the right mental model. The operational behavior is closer to an untrusted automation worker than a library call.
And untrusted automation workers need boundaries.
the interesting part is not packaging anymore
The old container pitch was mostly packaging: "it works on my machine" becomes "it works in this image."
That was useful. Still is.
But for agents, packaging is the least interesting part. The interesting part is policy.
A container can define:
- the filesystem shape the agent sees
- whether the workspace is mounted read-only or read-write
- which directories are excluded
- whether network access exists at all
- which binaries are installed
- which credentials are injected
- how the process is logged
- how the environment can be destroyed after the task
That list is basically an agent governance checklist with a Docker accent.
This is why Docker's recent AI governance and sandboxing posts are more important than the branding suggests. They are not just saying "run AI stuff in Docker." They are pointing at a larger architectural shift: containers are becoming permission envelopes for autonomous work.
The same thing is happening in agentic terminals, CI agents, code review bots, local model runners, and internal platform tools. The question is no longer only "can we run this workload?" It is "can we let this workload act without giving it the keys to the whole apartment?"
least privilege is harder when the worker is creative
The uncomfortable part is that agents are good at finding paths you did not explicitly think about.
A human engineer might ask, "can I access this file?" An agent might just try three commands, follow a symlink, inspect an environment variable, read a generated config, and then confidently continue.
Not maliciously. Just because that is what task completion looks like.
This is why I do not trust prompt-level policies as the primary control. "Do not read secrets" is nice. "The secrets are not mounted" is better.
Same with network access. "Only call approved APIs" is a guideline. "This container has no outbound network except through a proxy that logs and filters requests" is a control.
Same with write permissions. "Only modify files related to the task" sounds reasonable until the agent decides the fastest way to fix the build is to update a shared config file and touch half the repository. A read-only base plus an explicit writable workspace is less flexible, but it is also less surprising.
This is the pattern platform teams already know from production systems. Policy that depends on good behavior is not policy. It is hope with a YAML file.
the developer experience tradeoff is real
Now, the obvious pushback: too much sandboxing makes agents useless.
And yes. Absolutely.
If every agent task requires a ticket, a custom container, a security review, and three approvals from someone named Greg, engineers will route around it. They will run the agent locally with full access because the unsafe path is the only path that feels productive.
This is where the platform work gets interesting.
The goal is not to make the sandbox perfect. The goal is to make the safe path the easiest path for common work.
For example:
- A default coding sandbox with repo access, no cloud credentials, limited outbound network, and disposable state.
- A documentation sandbox that can read docs and open a browser but cannot touch source files.
- A dependency-update sandbox with package registry access but no production secrets.
- A migration sandbox that can run tests against a scrubbed database, not the real one.
- A privileged break-glass mode that is logged, rare, and slightly annoying on purpose.
That is developer experience design, not security theater.
The winning internal platforms will not say "agents are banned" or "agents can do anything." They will offer a small menu of well-understood execution envelopes and make it trivial to pick the right one.
containers are not enough, but they are the right primitive
To be clear: containers do not solve the whole problem.
A container with the wrong mounts, broad network access, and injected admin credentials is just a fancy way to feel safe while being unsafe. Container escapes exist. Supply chain problems exist. Secrets leak. Logs lie.
Some agent workloads need stronger isolation than ordinary containers. MicroVMs, hardened images, user namespaces, seccomp, network proxies, policy engines, and ephemeral credentials all matter depending on the blast radius.
But containers are still the right starting primitive because they are understandable. Engineers already know how to reason about images, mounts, environment variables, ports, processes, and logs. The mental model is imperfect, but it is much better than "the agent runs somewhere in your laptop with whatever access your shell had at 11:43 PM."
This is why I think the container renaissance around AI is real. Not because containers became fashionable again. Because isolation became valuable again.
what i would actually do on a team
If I were designing agent infrastructure for a serious engineering org right now, I would start small:
Define default sandboxes by task type. Coding, docs, tests, dependency updates, infra changes. Do not start with infinite flexibility.
Make secrets opt-in and scoped. Most agent tasks do not need production credentials. If a task needs cloud access, give it short-lived credentials with a narrow role.
Put network behind a policy layer. Even basic allowlists and logs are better than pretending nobody cares where the agent connects.
Keep the workspace disposable. The agent should be able to make a mess without making the developer's machine weird for the next three days.
Treat the transcript and command log as build artifacts. If an agent changed code, future reviewers should be able to see the path it took, not just the final diff.
Make escape hatches visible. Sometimes people need power. Fine. But privileged modes should be named, logged, and reviewed later.
None of this requires a giant AI governance program. It requires platform teams to admit that agents are not just autocomplete. They are tool-using processes, and tool-using processes need runtime boundaries.
the boring layer wins again
Infrastructure keeps reappearing at the center of whatever trend was supposed to abstract it away.
Serverless did not remove runtime concerns. It moved them.
Kubernetes did not remove operations. It renamed them controllers, operators, admission policies, and CRDs.
AI agents will not remove platform engineering. They will make platform engineering more important, because now the platform has to govern not only applications and humans, but semi-autonomous work happening between them.
That is why the Docker AI governance story is worth paying attention to. Not because Docker has the final answer. Because it shows where the answer is likely to live.
The future agent stack is not one giant model with unlimited permissions. It is a set of models, tools, policies, logs, sandboxes, and escalation paths.
And in that control plane, containers are not just packaging units anymore. They are becoming the thing that says: this agent can act, but only inside this shape.
That shape is going to matter a lot more than the demo videos suggest.