Source: Docker Blog — 2026-07-22
Summary
Docker Captain Karan Verma argues that as coding agents gain autonomy over files, terminals, APIs, and credentials, prompt-level instructions ("please don't touch production") are advice, not governance — only a runtime that can actually block an action counts as enforcement. The post lays out three governance boundaries agent platforms need — execution, tool, and credential — and frames isolation (containers, VMs, sandboxes) as the substrate that makes all three actually enforceable rather than aspirational.
Key Takeaways
- Core distinction: "a prompt can influence behavior; a runtime can restrict behavior." Anything an agent is merely told not to do, it can still do if nothing stops it at execution time.
- Three boundaries to govern separately: the execution boundary (what an agent can read/modify/run locally), the tool boundary (what external systems it can reach — source control, ticketing, cloud APIs, databases), and the credential boundary (what secrets it holds and how auditable that access is).
- Trust is framed as capability + visibility + control + accountability, not capability alone — a fully capable agent with no audit trail or blast-radius limit is the risky configuration, not the safe one.
- The argument for isolation (containers/VMs/microVMs) as the enforcement layer: it converts "the agent shouldn't do X" into "the agent physically cannot reach X," independent of what the model decides to do.
- Positions clear boundaries as an adoption accelerant, not a brake — teams delegate more to agents once they trust the blast radius is actually capped, not just requested.
Reel Script
Hook (~18s, 40 words) Every AI coding agent today runs on the honor system — you tell it in a prompt not to touch production, and you hope. Docker's latest post says that's not governance, that's a suggestion. Here's the actual distinction between an agent you can trust and one you're just hoping behaves.
Core Concept (~60s, 135 words) The line is simple: a prompt can influence behavior, but only a runtime can restrict it. A system prompt telling an agent "don't delete files outside your workspace" is a request the model can still ignore, misread, or get talked out of by a clever input. A runtime boundary — a sandbox, a container, a scoped credential — makes the action physically impossible, not just discouraged. Docker breaks agent governance into three boundaries you have to enforce separately: the execution boundary, which is what the agent can read, write, and run; the tool boundary, which is what external systems — GitHub, Jira, your cloud provider — it can actually call; and the credential boundary, which is what secrets it holds and whether that access is observable at all.
Hands-On (~55s, 125 words) Picture the three boundaries as concentric fences around an agent. Innermost: the execution fence, containing what files and commands it can touch on its own machine. Next: the tool fence, gating which outside APIs and services it's even allowed to dial. Outermost: the credential fence, controlling which keys it's handed and whether every use gets logged. An agent with full execution rights but no tool fence can still reach your production cloud account. An agent with a tool fence but no credential fence can still get handed a master key it never needed. Enforcement means every fence is a real technical block — sandboxed runtime, network allowlist, scoped and audited credentials — not a paragraph in the system prompt asking nicely.
Takeaway (~22s, 48 words) If your agent governance lives entirely in prompt text, you don't have governance — you have a hope. Isolate execution, gate tool access, scope and audit credentials, all at the runtime layer. Do that first, then give the agent more autonomy — not the other way around.