AI coding agents are now part of the execution path#
Docker’s latest blog post opens a new series on “Coding Agent Horror Stories,” but the useful part is not the horror framing. It is the trust model.
AI coding agents are no longer just autocomplete with a better interface. In many teams, they now read local files, run shell commands, edit code, query services, and operate inside real developer environments. Docker cites Anthropic’s 2026 Agentic Coding Trends Report, which says developers are using AI in roughly 60% of their work. The post also points to a broader shift from single agents to coordinated groups of agents that can compress work that once took hours or days into minutes.
That productivity story is real. It is also why the security problem matters.
A tool that can ship a feature quickly can also make a bad change quickly. A coding agent that can refactor a large codebase can also remove files, run destructive commands, or touch systems it should never have reached. Docker’s post argues that incidents over the past sixteen months show this is no longer a theoretical class of failure.
The company says publicly documented failures have involved named victims, screenshots of agent behavior, and vendor apologies in some cases. It also says that, as of February 2026, at least ten documented incidents across six major AI coding tools had been publicly attributed to agents acting with insufficient boundaries. The named tools include Amazon Kiro, Replit AI Agent, Google Antigravity IDE, Claude Code, Claude Cowork, and Cursor.
Those claims should be read with the right caution. Docker is a vendor selling a containment story through Docker Sandboxes. But the central risk model does not depend on Docker’s product pitch. It follows from how these tools run.
The main risk is inherited privilege#
Docker describes the common agent loop as: observe, plan, act, repeat.
A developer gives an agent a task. The agent gathers context. It reads files. It may inspect logs. It may see environment variables. It may call tools. It may write files, run tests, execute shell commands, hit APIs, and then decide what to do next based on the result.
The important detail is simple: the agent usually runs as the developer.
If the shell session has access to a repository, the agent has access to that repository. If cloud credentials are present in the environment, the agent may be able to use them. If a production database connection string is inside a local file that gets pulled into context, the agent may process it. If the developer has admin rights, the agent may inherit the practical effect of those rights.
There is often no clean identity boundary between “the human developer” and “the agent acting on behalf of the developer.” In many setups, the agent is just another process operating with the permissions already available in the workspace.
That changes how teams should think about approval. A chat assistant suggests. A coding agent acts. Once a tool can execute commands, edit files, and call services, it belongs in the same security conversation as build scripts, CI runners, deployment bots, internal automation, and contractor laptops.
The agent is not dangerous because it is malicious. It is dangerous because it is useful, fast, and often over-permissioned.
Autonomy changes the failure mode#
Traditional software can still surprise users, but its behavior is bounded by written code paths. An AI coding agent is different. It makes decisions at runtime from a changing prompt, changing context, and available tools.
That means the risky step may not be a known malicious instruction. It may be an apparently reasonable plan formed inside the task loop.
Docker gives examples of the kind of decisions that matter: an agent deciding that dropping and recreating a table is the clean way to resolve a schema issue, or that deleting a directory is faster than pruning it carefully. These examples are framed as failure modes, not necessarily as specific new incidents in the excerpted source material.
The pattern is still valid. The model decides. The execution layer carries out the decision. If there is no confirmation step, no policy boundary, and no sandbox, the human may only see the result after the action has already happened.
This is where normal developer habits become weak controls. A developer may trust their own terminal because they know what they are typing. But an agent-driven terminal changes the actor. The command still runs locally. The credentials may still be local. The logs may still show the developer identity. But the immediate decision was made by software interpreting a task.
That makes auditing harder. It also makes blast-radius control more important.
The security categories are familiar#
Docker says the documented failures cluster around critical risk categories, with the visible excerpt naming unrestricted filesystem access and excessive privilege inheritance before cutting off.
Even from that partial list, the shape is clear. These are not exotic AI-only problems. They are old infrastructure problems pushed into a faster interface:
- too much filesystem access
- too much cloud or database privilege
- secrets exposed through local context
- destructive commands without approval gates
- unclear separation between human and agent identity
- weak logging for agent-initiated actions
The novelty is not that a process can delete files or misuse credentials. The novelty is that developers are now delegating multi-step reasoning and execution to a system that can discover tools and act through them.
That makes “least privilege” harder to treat as a slogan. It has to become a working setup.
What teams should check now#
The first practical step is to map where agents are actually running. Many organizations will not get a clean answer from procurement records alone. Developers may use agents inside IDEs, terminals, hosted workspaces, local repositories, and experimental side workflows.
A useful inventory should answer four questions:
- Which coding agents are in use?
- Where do they run: local machine, container, remote workspace, CI, or cloud IDE?
- What credentials are visible from that environment?
- What commands, files, networks, and services can the agent reach?
The second step is to reduce default access. Do not launch agents from shells that carry broad production credentials. Do not keep long-lived secrets in local files that can be swept into project context. Do not let an agent operate in a directory tree wider than the task requires.
The third step is to add approval boundaries around destructive actions. File deletion, database migrations, cloud resource changes, credential access, production deploys, and outbound network calls deserve stricter handling than ordinary code edits. In some environments, that means sandboxing. In others, it means containerized workspaces, separate low-privilege accounts, network egress controls, read-only mounts, or human approval for specific tool calls.
Docker’s answer is Docker Sandboxes. That is expected from Docker. The broader lesson is not tied to one product: run agents inside constrained environments and assume the constraint will matter.
What not to overclaim#
The Docker post is a security warning from a vendor with a product interest. It should not be read as neutral academic measurement of the whole agent ecosystem. The excerpted source material does not provide the full incident list, the detailed methodology for the “at least ten” figure, or a complete breakdown of every category mentioned.
It also does not prove that every coding agent setup is unsafe. Risk depends on permissions, workflow, guardrails, network access, secrets handling, and how much autonomy the tool is given.
But the core claim is strong enough without exaggeration: if an AI coding agent can act with your permissions, then it can cause damage with your permissions. Treating it like a smarter chat window is the wrong model.
Practical takeaway#
AI coding agents should be onboarded like privileged automation.
Give them narrow workspaces. Strip ambient credentials. Separate development access from production access. Put destructive actions behind approvals. Log what the agent does. Prefer isolated environments over direct access to a developer’s full machine.
The productivity gains are real. So is the blast radius when the agent gets the wrong context and still has the right permissions to act.