Docker published the second entry in its Coding Agent Horror Stories series on July 20, and the operational read is short: on a stock developer laptop, an AI coding agent runs with the engineer's filesystem permissions and the engineer's credentials, with nothing sitting between it and the host. The post frames a scenario in which the agent deletes production and works backward through why that outcome is not exceptional. Docker names the piece as part two of a series that will cover six categories of coding-agent failure.
Two claims carry the argument. First, the agent inherits the developer's shell posture: whatever the developer can touch on disk, the agent can touch; whatever token is exported into the environment, the agent can spend. Second, that default is not a sandbox. Docker's phrasing is that nothing sits between the agent and the host unless the operator puts it there. The piece does not attribute the scenario to a named incident; it is a category, not a case study. Anyone extrapolating specific companies, victims or numbers is filling in blanks the source did not.
For CI operators this shape is familiar. A self-hosted Actions runner or a Jenkins agent that mounts the workspace, holds a checkout token and can call the host shell is a service you already isolate on purpose. You isolate it because the workflow you invited in is not always the workflow that runs. You isolate it because the token in the environment can do more than the job description. You isolate it because rollback of a bounded container is cheaper than reasoning about everything a process touched on a shared box. A coding agent living on the developer laptop occupies the same trust position, one machine earlier in the pipeline. It reads and writes the working tree. It holds session credentials to cloud APIs, the cluster and the registry. It executes instructions the developer did not always write, sometimes routed from a model, sometimes from a repository the agent just cloned. If a self-hosted runner without a sandbox is treated as a known-bad pattern in CI, the same box in the inner loop is a known-bad pattern for the same reasons.
The Docker post is a framing piece, not a runbook, but the practical layer it points at is the sandbox between agent and host. In real deployments that layer takes a few honest shapes, and no single one is a fit for every team.
A container is the cheapest cut: run the agent inside an image that mounts only the working tree, exposes only the credentials the current task needs, and drops back to a known-good filesystem when the task exits. It is the same posture already applied to ephemeral CI runners, minus the scheduler. The catch is that a container shares a kernel with the host, so kernel-level escapes and shared-mount surprises remain in scope.
A microVM raises the wall higher: the agent runs in its own kernel with its own device model, and a filesystem or network escape has to cross a hypervisor boundary. Startup cost is higher and tooling is less familiar on a laptop than in a build cloud, which is why VM-based agent sandboxes are showing up first in hosted developer environments rather than on personal machines.
A per-task sandbox is the strictest reading: each agent action or plan step runs in a fresh, credentialless environment, and any capability the task needs is granted on the way in and revoked on the way out. It is close to how good CI jobs already scope OIDC-issued tokens per run. The trade-off is friction, since a task that touches many systems has to declare that up front instead of relying on a signed-in developer identity to cover the gap.
Two residual points are worth naming, because a sandbox is easy to talk about and hard to keep honest. The first is credential inheritance: if the agent's sandbox is a fresh filesystem but the shell that starts it exports a long-lived cloud key, the wall is a decoration. Short-lived, task-scoped credentials issued into the sandbox at start are the version that actually holds. The second is exit surface. Any agent that can write back into the working tree, or open a pull request, or push a container, has a path out of the sandbox by construction. Isolation raises the cost of an unattended blast, but code that leaves the sandbox is still code that runs in your pipeline downstream, at whatever trust the pipeline gives it.
The Docker post's contribution is to name the default posture as the problem, not the last incident. The next four entries in the series will land against the same baseline. For CI teams, the reason to read it now is the same reason they hardened the runner in the first place: the machine at the other end of the credential is still yours, whoever is at the keyboard.