Agentic AI Security: What CISOs Say About Governing AI Agents

Source: Docker Blog — 2026-07-24

Summary

Docker convened enterprise security leaders — including Warp CEO Zach Lloyd, NanoClaw co-founder Gavriel Cohen, CISO community founder Moriah Hara, and Docker CISO Mark Lechner — to discuss how to govern AI agents without killing developer speed. The conversation centers on three concrete mechanisms: Docker Sandboxes for MicroVM-based agent isolation, the open-source MCP Gateway as a strict (not advisory) policy-enforcement chokepoint for tool calls, and supply-chain hardening — immutable tags/digests, SBOMs, and minimum release-age rules — for dependencies that agents select autonomously. The throughline is that "ungoverned speed," not agent capability itself, is the actual risk.

Key Takeaways

• Docker Sandboxes run agents in disposable, MicroVM-based isolated environments enforcing OS-level isolation — the same sandbox travels from laptop to cloud to Kubernetes, so agent workflows can be "lifted and shifted" without re-architecting trust boundaries.
• MCP Gateway acts as a single enforcement chokepoint between agents and external tools, routing every tool call through authentication, authorization, and logging before it reaches an external system — making policy enforcement strict rather than advisory.
• Supply-chain hardening: immutable tags/digests lock manifests so poisoned images can be detected fast, and SBOMs give transparency for rapid response when a dependency is compromised — addressing the specific threat of agents autonomously selecting base images/dependencies that traditional post-build scanning can't keep up with.
• Gavriel Cohen recommends a concrete policy: a 7-day minimum release age before agents are allowed to select a new image/dependency version, plus curated "blessed image" repositories and dependency minimization even for ostensibly safe packages.
• "Laptops as the new prod": CISOs describe developer laptops as the most powerful and most exposed node in the enterprise now that agents run locally, which is a core argument for pushing agent execution into controlled cloud infrastructure with centralized visibility.
• Moriah Hara's framing: CISOs are currently "tolerating some tools, praying nothing breaks" — the panel's consensus is that governance built in from day one beats governance "bolted on after the first major incident."

Reel Script

Hook Your AI agent just picked a dependency, ran a shell command, and called an external API — all before any human looked at it. CISOs say that's not a hypothetical risk anymore. It's Tuesday. Here's how Docker is trying to put guardrails on agent autonomy without killing its speed.

Core Concept The panel's core insight: the danger isn't agents acting fast, it's agents acting fast ungoverned. Docker's answer has two layers. First, isolation — Docker Sandboxes run each agent inside a disposable MicroVM, a lightweight virtual machine that boots in the background and gets thrown away after the task, so a compromised or misbehaving agent can't touch the host system. Second, control — the open-source MCP Gateway sits between every agent and every external tool it wants to call (databases, APIs, other services) and forces each call through authentication, authorization, and logging. Critically, the panel stresses this enforcement is strict, not advisory: the gateway can actually block a call, not just flag it after the fact. Together, isolation plus a mandatory checkpoint means an agent can move fast inside its sandbox while every action leaving that sandbox is inspected.

Hands-On Picture the architecture as three concentric layers. Innermost: the agent runs inside a Docker Sandbox — a MicroVM boundary that's portable across a laptop, the cloud, or Kubernetes, so the same trust boundary applies wherever the agent executes. Middle layer: every tool call the agent tries to make routes through the MCP Gateway, which checks identity and permissions and logs the call before it's allowed to reach an external MCP server or API — this is the "chokepoint" that turns policy from a document into an enforced gate. Outer layer: supply-chain controls govern what the agent is even allowed to pull in — immutable image tags and digests so a manifest can't silently drift, SBOMs so every dependency is inventoried, and a practical rule like Gavriel Cohen's 7-day minimum release age, which blocks an agent from grabbing a brand-new (and unvetted) package version the same day it's published. None of these three layers alone is sufficient — a sandbox without a gateway still lets an agent exfiltrate data through an approved-looking API call, and a gateway without supply-chain rules still lets an agent build on a poisoned dependency.

Takeaway The verdict from Docker's own CISO: if you sandbox the agent and control what crosses the trust boundary, it stops mattering where the agent physically runs. That's the practical unlock — teams get to keep agent speed instead of trading it for security theater. If you're running agents anywhere near production, put a policy-enforcement point (MCP Gateway or equivalent) between agents and tools before you scale usage, not after an incident forces the conversation.

Discussion

(No questions yet — ask follow-ups via a Claude Code chat session on this repo; answers get appended here.)