Giving an AI agent access to your systems is not the same as giving a person access. Not even close. It’s closer to giving a very capable, very literal-minded intern access to your credentials, your files, your APIs, and your production environment, with no hesitation and no self-doubt about whether a command is a good idea.
Docker published a detailed breakdown this week of five security risks that show up when AI agents are allowed to browse, run code, and act on instructions with limited human oversight. The risks are prompt injection, tool misuse, excessive autonomy, credential exposure, and data exfiltration. Let’s break each one down.
Prompt injection is the most important one to understand. An agent reads content to do its job, whether that’s a file, a webpage, a code comment, or a repository issue. If that content contains hidden instructions, the agent may follow them without knowing they’re not from you. Docker cited a real case where a coding agent was manipulated by instructions hidden in a repository it was reading, performing actions the developer never requested. The agent had no way to distinguish a legitimate instruction from an injected one.
Tool misuse follows from the same logic. Agents use connectors like database queries, file operations, API calls, and code execution to get work done, and giving an agent more tools than a task requires widens the attack surface considerably. Docker also warns that a tool’s own description can carry hidden instructions, causing the agent to misuse it in ways that go well beyond what any developer intended.
The excessive autonomy risk is easiest to see through examples. Docker described a developer who asked a coding agent to clean an old repository. The agent generated a delete command with a typo and executed it without asking for confirmation, wiping the developer’s entire home directory. In a separate incident, an agent with operator-level access to an AWS account decided to delete and rebuild a production environment, causing a thirteen-hour regional outage.
Credential exposure compounds every other risk. When an agent runs with a developer’s personal credentials, every action it takes carries that person’s full permissions, meaning a compromised or misdirected agent can delete databases, modify production configurations, and access any system that developer can reach. Short-lived, purpose-specific credentials that expire after a task are far safer.
Data exfiltration closes the list. An agent that holds sensitive data in its working memory and has network access can send that data somewhere unintended, a risk that grows significantly in multi-agent pipelines where one agent hands work to another.
Docker’s recommended answer is isolation, meaning running agents in contained environments with defined limits on what they can access, combined with governance policies that specify which tools and credentials each agent is permitted to use. These are infrastructure decisions, not model decisions. No amount of careful prompting fixes a permissions problem.
If your team is deploying AI agents, treat them like a new application category that needs its own security review, its own permissions model, and its own monitoring setup. The speed gains are real. So are the risks.
Want to explore how AI agents could be deployed safely in your business? Let’s talk.