Every organization deploying AI agents already has the rules written down somewhere. Don’t expose customer data. Don’t touch production without authorization. Don’t execute untrusted code. Don’t use credentials outside approved workflows. The uncomfortable part, as Docker Captain Karan Verma puts it in the second installment of Docker’s AI governance series, is that writing the rules was never the hard part. Enforcing them against software that increasingly acts on its own is.
Verma’s essay, published July 22, plants its flag in a single sentence that deserves to be quoted on every architecture slide this year: “A prompt can influence behavior. A runtime can restrict behavior.”
That distinction sounds obvious once stated, but most agent deployments today quietly ignore it. Teams stuff their system prompts with instructions — never delete files outside the workspace, never call external APIs without asking — and treat that as a control. It isn’t. It’s advice. A sufficiently confused, manipulated, or simply unlucky agent can walk straight past it, because nothing at the infrastructure layer actually stops the action from happening. Runtime enforcement is the difference between a sign that says “keep out” and a locked door.
The gap between policy and enforcement
Verma’s framing lands because it names a failure mode the industry has already experienced. Docker’s own blog documented a case earlier in July in which an AI coding agent deleted a production environment, triggering a 13-hour outage — exactly the kind of incident that written policy prohibits and runtime boundaries would have prevented. The post’s prescription was scoped identities and isolated execution; Verma’s essay generalizes that prescription into an architecture.
The essay is also a deliberate continuation. In part one of the series, published July 8, Verma argued that traditional security models struggle with autonomous agents because a growing share of their activity happens outside familiar checkpoints — repositories, CI/CD pipelines, deployment environments. Part two answers the question that framing raises: if governance has to live where agents actually execute work, what does that look like in practice? And Docker’s editorial push here is coordinated — the same month brought a CISO panel on governing agentic AI without grinding development to a halt, published July 24.
Verma’s answer is three boundaries. Understand them and you understand the whole model.
Boundary one: execution
Agents read files, modify code, run commands, install dependencies, and open network connections. Verma’s example is a coding agent troubleshooting a failing test suite: it inspects configuration, generates temporary scripts, pulls in debugging dependencies, and reruns tests repeatedly before any human reviews the result. Every one of those steps is useful. Every one of them is also a potential blast radius.
The execution boundary determines the box inside which all of that happens. This is where the oldest idea in systems security — isolation — gets its second act. Containers, virtual machines, and sandboxes all exist, as Docker argued in its case for agent isolation, to create hard limits on what software can access and affect. Docker Sandboxes are the company’s own adaptation of that principle for agent workflows, and the strategic logic is sound regardless of whose sandbox you use: rather than letting an autonomous system roam a developer’s environment with the developer’s own privileges, you give it a bounded world where the worst case is contained by construction.
The essay’s sharpest observation here is about intent. The goal of isolation is not to make agents less capable. It is to make capability predictable — to change the question from “what might it do?” to “what can it possibly do?”
Boundary two: tools
The second boundary is the one most teams miss, because it doesn’t involve local code execution at all. Modern agents talk to source control platforms, issue trackers, communication tools, cloud services, internal APIs, and databases. An agent that opens a pull request, updates a Jira ticket, or fetches documentation through a tool connected via the Model Context Protocol never runs a risky command on your machine — yet it still changes real systems of record.
Verma’s point is that governance built solely around execution leaves this entire surface uncovered. Sandboxing an agent’s shell while giving it unfettered MCP access to your infrastructure is locking the front door and leaving the loading dock open. As MCP adoption accelerates — and it is accelerating fast, becoming the de facto wiring standard between agents and tools — visibility and policy over tool access matter as much as capability. The tool boundary asks: which integrations can this agent reach, what can it do through them, and is every one of those actions observable?
Boundary three: credentials
The third boundary is the least glamorous and, in the long run, probably the most consequential. Any agent doing valuable work eventually needs access to something valuable: a GitHub repository, a cloud environment, an internal API, a database, a customer support system. Behind each sits credentials, permissions, and identity.
The essay reframes the question in a way security teams will recognize from two decades of human identity management: not whether an agent can use a credential, but how that access is controlled, observed, and audited. As autonomy grows, credential governance converges with execution governance in importance. An agent with a leaked or over-scoped token doesn’t need to escape any sandbox to cause damage — it just needs to make authorized-looking API calls. Scoped, short-lived, per-agent identities are the direction of travel here, and the production-deletion incident is the case study for why.
The counterintuitive part: developers want this
The most interesting move in Verma’s essay is rhetorical. AI governance is usually framed as friction — the thing the security team imposes and developers route around. Verma inverts that: most developers, he argues, aren’t asking for fewer restrictions. They’re asking for predictability. Before delegating meaningful work to an agent, a developer wants to know what it can access, what it can modify, which tools it can use, and which credentials it can act with.
Clear answers to those questions are precisely what make delegation psychologically possible. In that sense the three boundaries aren’t just security controls; they’re trust-building mechanisms — the thing that turns agents from interesting experiments into everyday tools. Docker’s broader AI governance framing makes the same bet: the organizations that establish this confidence early will adopt agents faster, not slower, because their developers will actually hand over real work.
That claim has a familiar shape. It is the same argument that won for typed languages, code review, and CI gates — constraints that felt like overhead until teams noticed they were shipping faster because of the guardrails, not despite them.
What to take from it
For teams running agents today, the three-boundary model doubles as a maturity checklist, and the boundaries are not equally solved. Execution isolation is the most mature — containers and sandboxes are established technology being repurposed. Tool-boundary governance is emerging now, largely riding on MCP’s centralization of the agent-tool interface, which creates a natural enforcement point that didn’t exist when every integration was bespoke. Credential governance for non-human identities is the least settled of the three, and it’s where the next wave of incidents — and products — will likely concentrate.
The practical sequencing follows from that: sandbox execution first, because the tooling exists today; inventory and gate tool access second; then treat agent identity as a first-class citizen of your IAM program rather than a shared service account bolted on at the end.
Verma closes with a teaser for part three, which will argue that governance is as much a developer-experience challenge as a security one. That’s the right destination. Enforcement that developers resent gets bypassed; enforcement that makes delegation feel safe gets adopted. The teams that internalize the difference between influencing an agent and restricting one — between advice and enforcement — are the ones that will get to move fast without finding out what their own 13-hour outage looks like.
