AI Agent Security: Docker Bets on Isolation Over Model Fixes

What Docker is arguing

Docker has published guidance on the security risks that appear when AI agents can browse the web, run code and call tools with little human supervision. Its main claim is that ordinary application security controls weren't built for software that behaves this way.21 The post was written by Docker product manager Eric Jia and principal product marketing manager Srini Sekaran. It names five risks: prompt injection, tool misuse and poisoning, excessive autonomy, credential exposure and data exfiltration.2122 The authors trace all five to the same cause. An agent picks its tools at runtime, chains several actions together and often holds the full permissions of the person who launched it.21

The company's answer is isolation and governance, not better models.21 That is a choice about where to spend effort. In practice it accepts that today's language models can't be fully trusted to resist manipulation, and moves the security boundary out of the model and into the infrastructure around it.

Prompt injection as the defining risk

Of the five risks, Docker treats prompt injection as the central one. An attacker doesn't need to break into a system. They can plant instructions in something the agent will read, such as a web page, a code comment, an issue tracker entry or a document.21 Docker points to a case where a coding agent obeyed instructions hidden in repository content and took actions its user never asked for.21

The guidance doubts that this can be fixed with better system prompts. The authors say an agent has no dependable way to tell a real instruction from an injected one, so the practical defense is to limit what a hijacked agent can reach.2122

Most of the wider coverage agrees with that assessment. OWASP has ranked prompt injection first in its risk list for LLM applications in every edition since 2023, including the 2026 edition. Its separate agentic list puts the closely related "Agent Goal Hijack" first.2 Cycode notes that models read system prompts and user input as one stream of text, which is why separating them is usually impossible.1 It also cites CVE-2025-53773, in which hidden instructions in pull request descriptions enabled remote code execution through GitHub Copilot, with a CVSS score of 9.6.1

The list of real incidents keeps growing. Noma Security's GitLost disclosure described a crafted public GitHub issue that led GitHub's Agentic Workflows agent to fetch a README from a private repository and post its contents publicly.8 Adversa AI's October 2026 roundup recorded injection techniques that made agents leak personal data, run attacker-supplied code and reach other customers' data on shared platforms. It traced these to three repeated failures: too much access, unchecked commands and incomplete isolation between sessions.7 Those three failures closely match the problems Docker's guidance targets.

Where the threat data diverges

Not all reporting on how big the threat is holds up equally well. Some coverage of AI coding assistants says more than 90 organizations were compromised by prompt injection in 2025, with attack success rates of 50% to 84%.3 A more careful analysis from Technology.org warns that many widely shared statistics measure fear rather than actual attacks.5 For example, Google found a 32% relative rise in malicious prompt-injection content in web archive scans between November 2025 and February 2026, but said most of the samples were crude or harmless.5 Cisco's often-quoted gap between organizations planning agentic deployments and those ready to secure them reflects survey intentions, not breaches.5

This article takes that more careful reading, with one caveat: confirmed in-the-wild payloads do exist. Forcepoint verified ten live injection payloads on websites, including one that instructed an agent to send a fixed $5,000 PayPal payment.5 Academic work on security operations agents shows how hard the problem is to remove completely. In one benchmark, layered defenses cut attack success on GPT-4o from 87.3% to 8.4%, which is a large drop but still not zero.9 That leftover gap is the strongest argument for Docker's position. If filters and prompt design can only lower the odds, then what decides the damage is how far a compromised agent can reach.

Autonomy, credentials and exfiltration

Docker's other risks move from manipulation to consequences. On excessive autonomy, the guidance calls out "YOLO mode," where every agent action is approved automatically. It accepts that this mode can be productive but argues it should run inside a boundary.2122 The examples are stark. In one, a coding agent asked to clean up an old repository ran an rm -rf command with a trailing ~/ and deleted the developer's home directory. In another, an agent with operator-level access chose to delete and rebuild a production environment while fixing a Cost Explorer bug, which caused a thirteen-hour regional outage.22

On credentials, Docker says agents should never inherit a developer's personal token. It recommends short-lived credentials injected at runtime and kept out of the conversation, because injected instructions may be able to read secrets in the agent's context.22 On exfiltration, it recommends allow-listed network egress and treating every handoff between agents as untrusted input, a risk that grows in multi-agent systems.21

The product behind the guidance

The guidance is also a product pitch. Docker presents Docker Sandboxes, which runs each agent in a disposable microVM with set filesystem and network controls, and AI Governance, which sets and enforces the actions, tools and credentials an agent may use.21 According to Docker's documentation, the microVM is the main trust boundary. The agent has full control, including sudo, inside the VM, but can reach only what is explicitly shared from the host.14 A host-side proxy adds credentials to outbound HTTP requests, so raw key values never enter the VM.1419 The company's product page openly embraces permissive agent modes, arguing that the boundary is infrastructure rather than the agent's judgment.11

The guidance also arrives as part of a broader industry push. Docker is a founding member of the Blueprint Alliance, a 12-company reference architecture for securing agents whose members include Okta, AWS, CrowdStrike and Google Cloud.24 It also co-drafted Agent Baseline with Snyk and Keycard, a set of 35 security controls. One of them, CON-03, calls for isolated, confined agent execution.2423 Docker also relaunched its partner program around AI governance in late October.26 Read together, these moves suggest Docker sees agent isolation as a commercial category it wants to define, and not only a security recommendation.

The pushback: does the boundary match the trust model?

Critics don't argue that isolation is unnecessary. They argue about whether Docker's version goes far enough. In community discussion, one commenter said standard Docker containers still leave a large system-call surface exposed and recommended deny-by-default permissions and least authority. Another questioned relying on a shared kernel when agents run code on behalf of other people.21 Some of that criticism is aimed at plain containers rather than Sandboxes, which use per-agent microVMs with their own kernels.19 Still, InfoQ's point holds: the real question is whether the isolation boundary matches the trust boundary of the workload.21

Sharper criticism focuses on defaults and on how much a network-level boundary can actually understand. One comparison describes Docker Sandboxes' default egress as permissive, and says it lacks tool-call interception and applies read-write workspace mounts by default. Anthropic's sandbox-runtime and NVIDIA's OpenShell, by contrast, deny egress by default.29 That clashes with Docker's own description of scoped, deny-by-default access.11 The difference probably comes down to which policy mode a user picks: one hands-on walkthrough describes a strict Locked Down mode next to a Balanced mode that ships with a preset allowlist.18 Separately, a network allowlist can't tell a harmless GET from a damaging POST sent to the same host. That is why some coverage argues for application-aware policy layered on top.30

Docker's tooling has had security problems of its own. Reported CVEs include a DNS exfiltration path that bypassed the HTTP allowlist and a "CopyEscape" flaw that allowed writes to the host filesystem through the file-copy feature. Both have been patched.17 A GitHub issue also complained that the sandbox MCP gateway exposed every host-registered MCP server to agents, with no way to filter them.20 Docker's own documentation warns that local stdio MCP servers run on the host with host permissions, outside the sandbox's protection.14

The takeaway

Docker's main argument is right. Prompt injection can't yet be engineered out of language models, so limiting the damage is the only defense teams can rely on today. The incident record and OWASP's rankings support that view.278 But the sandbox is a minimum, not a complete answer. Its value depends on strict defaults, careful handling of credentials and tool access, and the harder question Docker itself leaves open: who decides which permissions an agent truly needs, and who reviews what it does with them.22