A developer asked their AI coding agent to clean up an old repository. The agent generated a delete command with a subtle typo and executed it without asking for confirmation. The developer’s entire home directory was gone. A separate incident involved an AWS engineer who handed a production bug to a coding agent running with operator-level access. The agent decided the cleanest solution was to delete and rebuild the production environment. The outage lasted thirteen hours.
Docker published a detailed analysis of exactly why incidents like these happen, and the core argument is clear. AI agents are not like normal software. A conventional application receives a request at a known endpoint, runs deterministic code, and produces a predictable output. An agent reads files, browses the web, installs packages, calls external APIs, and chains all of those actions together from a single instruction. That is what makes them useful, and that is also what makes the security picture fundamentally more complicated.
The analysis identifies five risks worth understanding.
The first is prompt injection. An attacker does not need access to your systems directly. They simply need to place instructions somewhere the agent will read them: inside a code comment, a document, a webpage, or a repository issue. The agent reads the content and treats the embedded instructions as legitimate. Docker makes an uncomfortable point about this. Telling the model to ignore injected instructions does not reliably work. The agent cannot tell the difference between a legitimate instruction and a planted one, so the real defense is limiting what a hijacked agent can reach in the first place.
The second risk is tool sprawl. Agents use connectors to databases, file systems, APIs, and code execution environments. Each tool is a potential attack surface. Giving an agent more tools than a task actually requires makes the blast radius of any mistake or compromise much larger.
Third is excessive autonomy, what Docker calls “YOLO mode,” where every agent action is automatically approved. The developer who lost their home directory and the engineer who caused a thirteen-hour outage were both running agents with no meaningful constraint on what those agents could execute. This is not an edge case. It is what unconstrained autonomy looks like in practice.
Fourth is credential exposure. Agents that run under a developer’s personal access token carry that person’s full permissions for every tool call, every API request, every file operation. If a prompt injection attack succeeds while the agent holds a developer’s credentials, every system that developer can access is suddenly in play.
Fifth is data exfiltration. An agent with network access and sensitive data in its working memory can send that data to unintended destinations. The risk compounds in multi-agent systems, where one agent passes work to another and each handoff becomes an opportunity for unintended disclosure.
Docker’s recommended fix is structural. Run agents inside isolated sandboxes, disposable environments with defined file system and network access, and enforce governance policies on what tools and credentials each agent is allowed to use. The fix is not a better model. The fix is a better container.
Building AI-powered workflows into your business is a sound investment. Building them without thinking through the security architecture is just building a faster path to a larger incident.
Want to explore how to deploy AI agents securely in your business? Let’s talk.