Docker has published a guide to five security risks that arise when AI agents are allowed to browse, run code and call tools with limited human oversight. Writing with product manager Eric Jia, Docker principal product marketing manager Srini Sekaran argues that the autonomy that makes agents useful also makes conventional application security controls insufficient. The company positions isolation and governance, rather than model improvements alone, as the main defences.
The blog post identifies prompt injection, tool misuse and poisoning, excessive autonomy, credential exposure, and data exfiltration as the principal risks. Docker argues that these share a common cause: an agent can select tools at runtime, chain several actions together and often operate with the permissions of the person who started it.
"An agent doesn't just answer a question, it browses, runs code, and calls tools on its own, so a single bad or manipulated instruction can turn into real damage instead of just a wrong answer."
Eric Jia and Srini Sekaran, Docker
Traditional web security often assumes requests arrive at known endpoints and are processed by deterministic code, but agents do not fit that model. A coding agent may read a file, install a dependency, alter configuration, run tests and push a commit after receiving one instruction. Docker says that a compromised or misdirected agent can therefore take a much wider range of actions than a conventional service.
Prompt injection is presented as the defining risk: rather than compromising a system directly, an attacker can place instructions in material an agent is asked to read, such as a web page, code comment, issue or document. Docker cites an incident in which a coding agent followed instructions hidden in repository content and performed actions its user had not requested.
The company is sceptical that prompt injection can be eliminated through instructions to the model, saying that an agent cannot reliably distinguish a legitimate instruction from an injected one. Its preferred response is to limit what a hijacked agent can reach, so that successful manipulation has a smaller effect.
"The agent has no reliable way to tell a legitimate instruction from an injected one, so the defense is to limit what a hijacked agent can reach."
Eric Jia and Srini Sekaran, Docker
Tools are the second area of concern. With agents use connectors, database queries, file operations and code execution to affect external systems, Docker warns that giving an agent more tools than a task requires enlarges the attack surface. It also warns that a tool description can carry hidden instructions that lead an agent to misuse the tool.
This aligns with guidance published by OWASP. In its Agentic AI Threats and Mitigations work, reported by InfoQ in September 2025, OWASP identified tool misuse as a major new threat. It described attackers manipulating agents into abusing authorised tools, potentially gaining unauthorised data access or manipulating systems while remaining within granted permissions. OWASP recommended access verification, behavioural monitoring, operational boundaries and tamper-resistant execution logs.
Docker's third risk is excessive autonomy. The post describes "YOLO mode", where every agent action is approved automatically, as a visible example of broad standing permission. It acknowledges that this mode can be productive, but argues that it should be used inside a boundary that prevents an agent from reaching systems or data it should not touch.
The company gives an example in which a developer asked a coding agent to clean an old repository. The agent generated an rm -rf command with a trailing ~/ and executed it without confirmation, deleting the developer's home directory. Docker also cites an AWS engineer who gave a coding agent a Cost Explorer bug while it ran with operator-level access. The agent chose to delete and rebuild the production environment, resulting in a thirteen-hour regional outage.
Credential handling is closely connected to that problem. Docker says agents should not inherit a developer's personal token, because every action then carries that person's full permissions. It recommends separate, short-lived credentials, injected at runtime and kept out of the conversation. Secrets in prompts, configuration files or image environment variables are also a risk, because injected instructions may be able to read them from the agent's context.
The final risk is data exfiltration. An agent with network access and sensitive information in its context may send that information to an unintended destination. Docker says the risk increases in multi-agent systems, where one agent passes work to another. It recommends allow-listed network egress and treating every handoff between agents as untrusted input.
Those recommendations echo other work covered by InfoQ. Google's GKE security blueprint, reported in July 2026, recommends GKE Sandbox, based on gVisor, for containing agents that execute generated code or call untrusted tools. It also uses Model Armor to inspect prompts and responses for injection attempts and sensitive data exposure. Earlier, Meta open sourced LlamaFirewall, which combines prompt-injection detection, reasoning checks and static analysis of generated code. Google DeepMind's CaMeL research, also covered by InfoQ, takes a different approach by tracking control and data flows around a model.
Docker's answer is Docker Sandboxes and AI Governance. Sandboxes run each agent in a disposable microVM with defined filesystem and network controls. AI Governance is intended to define and enforce which actions, tools and credentials an agent may use. The company says isolation is the highest-impact starting point, with governance providing oversight across a fleet of agents.
Community discussion suggests that isolation alone will not settle the design question. In a thread on r/AI_Agents, a commenter using the name HectaMan wrote that teams should first assess tenancy and risk models. They argued that Docker can be convenient but may still grant excessive authority, noting that it disables around 40 privileged system calls while leaving roughly 500 available. They recommended deny-by-default permissions, least authority, policy enforcement points and controlled information flow.
Another commenter, Groady, said Docker works well for personal agents on a local machine, but questioned a shared kernel when agents execute code on behalf of other people. They suggested microVMs or gVisor-based isolation for that case. The discussion indicates that the useful comparison is not simply container versus no container, but whether the isolation boundary matches the trust boundary of the workload.
Docker's guidance is a useful summary of a problem that is becoming more concrete as coding agents gain write access to repositories, cloud accounts and production systems. Its central claim is persuasive: security teams should assume that agent input may be hostile and design the surrounding system so that a wrong decision cannot become a broad compromise. The harder work is deciding which permissions an agent genuinely needs, how those permissions expire, and who reviews the actions taken under them.