Your AI Agent Has Your Keys. Docker Just Showed How Bad That Can Get.
One developer asked their AI coding assistant to clean up an old repository. The agent generated a delete command with a trailing typo, executed it without asking for confirmation, and wiped the developer’s entire home directory. Everything gone.
Another developer gave an agent access to their AWS account to fix a bug in a cost management tool. The agent decided the most efficient approach was to delete and rebuild the production environment from scratch. The result was a thirteen-hour regional outage.
These aren’t hypothetical scare stories. Docker documented both incidents this week in a detailed security guide, alongside a breakdown of five structural risks that apply to any organization deploying AI agents in their infrastructure.
The core problem is different from most software security you’ve dealt with before. When a traditional application receives a bad request, the damage is usually limited to that request. AI agents don’t work that way. Give an agent a task, and it may browse the web, read files, run code, make API calls, and push commits, all in sequence, all without pausing to confirm. A single bad instruction can cascade across a lot of systems very fast.
The first and most dangerous risk Docker identifies is prompt injection. An attacker plants instructions inside material the agent will read, such as a code comment, a web page, an email, or a document. The agent reads those instructions and treats them as legitimate commands. Docker is direct about the fix: there isn’t a model-level solution. The agent has no reliable way to distinguish a real instruction from an injected one, so the only practical defense is limiting what a hijacked agent can reach in the first place.
Tool misuse is the second risk. Agents connect to databases, file systems, APIs, and code execution environments to get work done. The more tools an agent has access to, the more damage it can cause if something goes wrong. Giving an agent only the tools a specific task requires is not just good practice. It’s the difference between a contained mistake and a production incident.
Credential exposure ties directly to this. Agents that run with a developer’s personal access token carry that person’s full permissions for every action they take. If the agent is manipulated or makes a wrong call, it has everything it needs to do real harm. Docker recommends short-lived, task-scoped credentials injected at runtime, kept out of the agent’s context window entirely.
Data exfiltration rounds out the picture. An agent with network access and sensitive data in its working context can send that information somewhere it shouldn’t. In multi-agent systems, where one agent can instruct another, the problem compounds quickly.
Docker’s answer is isolation and governance. Run agents in sandboxed environments with scoped permissions, network boundaries, and behavioral monitoring. Smarter models help at the margins. Structural containment is what actually prevents a bad instruction from becoming an incident report.
If your team is deploying AI agents for coding, data analysis, customer interactions, or operations, the security model you built for traditional software will not cover it. Agents need a different permission architecture, and that architecture is easier to design before something goes wrong than after.
Want to explore how to deploy AI agents securely in your business? Let’s talk.