Source: Docker — 2026-08-18
Summary
Docker's latest "Coding Agent Horror Stories" post walks through a class of attack most teams running coding agents haven't accounted for: the allowlist itself becomes the attack surface. Most teams maintain a list of commands their agent can run without asking permission — but an attacker can commit a benign-looking MCP config, get it approved through normal review, then swap the payload behind that already-trusted config entry. In one described case, a tool trusted the approved key name rather than the actual command content, letting an attacker's substituted command run without triggering a second review. Docker's pitch is that Docker Sandboxes — microVM-isolated environments — contain the blast radius even when the approval step itself gets fooled.
Key Takeaways
- The vulnerability isn't a bug in the agent's reasoning — it's a trust model bug: an allowlist checks whether something matches an approved name or pattern, not whether the actual content behind that name is still what was reviewed.
- The described exploit pattern: commit a harmless-looking MCP config → get it approved once → swap in a malicious payload later → the agent runs it because the identifier is still on the allowlist, even though the content has changed.
- Coding agents already install packages, run shell commands, and make network calls that no human explicitly typed — which is the whole point of using them, but also means an attacker who gets one command approved can potentially pivot from there.
- Docker's mitigation is isolation over inspection: a microVM sandbox limits what a compromised action can actually reach (filesystem, network, credentials) regardless of whether the approval step itself was fooled, so a bypassed allowlist doesn't automatically mean a compromised host.
Reel Script
Hook (~18s): You reviewed that command once and approved it — so your coding agent runs it every time without asking again. That's exactly the gap attackers are now exploiting.
Core Concept (~90s): Most people running an AI coding agent give it an allowlist — a set of commands or config entries it's allowed to run without stopping to ask permission each time, because asking for every single action would make the agent useless. The problem Docker describes is that the allowlist typically checks an identifier — a command name, a config key — not the actual content sitting behind that identifier at the moment it runs. So an attacker's move isn't to trick the agent into running something obviously malicious; it's to get something boring and legitimate-looking approved first, wait, then swap what's actually behind that approved entry. The agent isn't being fooled by clever reasoning — it's correctly following a rule ("this key is on my allowlist, run it"), and the rule itself is what's broken, because "approved" got defined as "this name" instead of "this exact content." It's the software equivalent of approving someone's ID once and then never checking their face again.
Hands-On (~55s): The specific scenario Docker walks through: an attacker commits an MCP config — the kind of small config file that tells an agent which external tool to call — under a name that looks routine enough to sail through review. It gets approved. Later, the attacker swaps the actual command that config points to. The agent's approval check looks at the config's key name, sees it's on the allowlist, and runs it — the substitution never gets re-reviewed because nothing about the check was designed to notice content had changed underneath an already-trusted name. Docker's containment answer is a microVM sandbox around the agent's execution environment: even if that swapped command runs, its filesystem access, network reach, and credentials are scoped down by the sandbox boundary, not by the (already-bypassed) allowlist — so a fooled approval step doesn't automatically mean a compromised machine.
Takeaway (~25s): An allowlist that checks names instead of content is a lock that only checks the shape of the key, not whether it's actually yours. If you're running coding agents with any kind of auto-approved commands, the fix isn't a smarter allowlist — it's assuming the allowlist will eventually be beaten and sandboxing what happens next.