OWASP Top 10 for LLMs Applied to Coding Agents

The OWASP LLM Top 10 is the shared language for talking about AI risk, but it was written with a chat assistant in mind, where "output" means text that lands in a chat window and a person reads it before anything happens. Coding agents break that assumption completely. Their output is code, shell commands, and tool arguments that get executed by downstream systems with no person standing in the way. OWASP's own GenAI Security Project saw the gap, so it published a separate Top 10 for Agentic Applications, one that covers systems that reason, remember things across sessions, and use tools across trust boundaries. So OWASP itself is admitting that the original LLM list doesn't fully cover agents on its own.

Three things about coding agents turn mild risks into ones that actually execute. First, they collapse the line between instructions and data: a model reads a file or a web page the same way it reads a command, so the two blur together. Second, they hold state across sessions, so a bad decision today can shape tomorrow's. Third, they call real tools with real consequences: file writes, shell commands, deployments. Every category on the OWASP list runs through at least one of these three amplifiers. You still need to go through the list category by category, because practitioners, compliance reviews, and security tooling already use that vocabulary. The job here is to translate each entry into what it actually looks like when a coding agent is the one holding the keyboard, and to flag which risks get worse, and by how much.

Prompt injection (LLM01) and the dominance of the indirect variant in agent contexts

Prompt injection is at the top of the 2025 list because of a basic architectural fact: large language models process instructions and data through the same channel, with no hard wall between them. It's baked into how the model reads text at all, not something a point release can patch. Readers of this piece already know the direct version, where someone types "ignore previous instructions" into a chat box. Coding agents mostly shrug that one off, because security tooling has been tuned to catch it for a couple of years now.

The variant that actually matters for agents is indirect injection. An agent doing normal work reads web pages, opens files, calls APIs, and receives tool outputs, and any one of those can carry hidden instructions mixed in with legitimate content. The agent can't tell a data file from a command, so it follows the embedded instruction and acts on it through a tool call. Nobody reviews a chat response here, because there often isn't one: the action just happens. The 2025 edition also flags multimodal injection, where the hidden instruction rides in an image, a PDF, or a structured data file rather than plain text, which matters directly for agents that read those formats as part of their job.

The clearest real-world case of this escalation is EchoLeak, tracked as CVE-2025-32711 with a CVSS score of 9.3, found in Microsoft 365 Copilot in June 2025. An injection got weaponized into actual data exfiltration, and it needed zero clicks from the user. The team that found it called it an "LLM Scope Violation": untrusted content from outside the system got pulled into the same context as privileged internal data, and the model treated both as equally trustworthy. Nobody can patch prompt injection out of existence, because it exploits how LLMs are built at a fundamental level. The honest position on defense is layering: privilege separation, keeping untrusted data out of the instruction channel through structural queries, and defaulting to deny before anything gets consumed downstream. None of that claims to eliminate the risk. It just shrinks the target.

Sensitive information disclosure (LLM02) and the expanded exfiltration surface agents create

Once an injection lands, the next question is what it can reach, and for a coding agent that answer is a lot more than a chat assistant ever holds. At any given moment, a coding agent's context window might contain source files, commit history, environment variables, API keys, tool credentials, and whatever retrieval-augmented content it pulled in to do the task. If a chat assistant leaks, you usually get a paragraph of text at worst. But if an agent leaks, you get a working set of secrets wired into live infrastructure.

OWASP's 2025 edition notes that sensitive information disclosure jumped from sixth place to second, which tracks with how models can memorize and reproduce fragments of their training data, including PII, proprietary material, and confidential documents. If an attacker talks the model into revealing the system prompt, the business logic, API endpoints, and access secrets behind it get exposed too. For agents, the exfiltration path rarely looks like a leaked chat reply. An injected instruction can direct the agent to tuck secret material into a tool argument, a URL query parameter, or a comment buried in generated code. Output filters built to scan chat responses for sensitive language miss all of that, because none of it reads like a sentence a human would flag.

System prompt leakage, LLM07 on the original list, belongs in this conversation rather than off on its own, because it's the same disclosure problem aimed at a specific target. OWASP is blunt about this: the system prompt should never be treated as confidential, and it should never function as a security control, because prompt injection and related techniques can extract or infer its contents regardless. In coding-agent setups, that system prompt frequently carries the full tool catalog, the permission structure, and sometimes credentials. Treating it as a vault is the mistake. Treating it as already public is the safer assumption.

Supply chain risk (LLM03) as it extends across model weights, MCP servers, plugins, and emitted dependency manifests

Coding agents don't just consume a supply chain the way a normal application does. They also emit one, which doubles the places something can go wrong. The consuming side includes model weights pulled from third-party hubs, MCP servers the agent connects to, and skills or plugins that extend what it can do. The emitting side is the dependency manifests the agent writes into codebases on your behalf. A tampered package or a floating version range that slips into one of those manifests inherits whatever privileges the agent itself runs with, which in a lot of setups is considerable.

A real incident makes the consuming side concrete. The Amazon Q Developer Extension for VS Code was affected by an issue tracked as CVE-2025-8217, published in an AWS Security Bulletin on July 23, 2025, and confirmed independently by security researchers around the same date. Malicious code was injected into the extension itself, not into some downstream app that merely used it, which is the kind of upstream compromise that supply chain risk is actually warning about: the tool you trust to write your code is itself a target. OWASP's 2025 edition backs this up with scale: supply chain vulnerabilities rose from fifth place to third, a single compromised model on a popular hub can ripple out to thousands of downstream applications, and newer fine-tuning methods like LoRA and PEFT open attack paths the 2023 edition never anticipated.

The MCP layer adds its own wrinkle. A malicious MCP server can impersonate a legitimate one, and once an agent connects, that server quietly redirects data to the attacker. Most existing security tooling doesn't inspect that layer at all, which makes it a blind spot by default rather than by neglect. Controls need to match a surface this wide: signed artifacts, an AI Bill of Materials that covers models, frameworks, and connectors together, verification of MCP server identity before any connection is trusted, and pinned dependency versions in anything the agent writes, rather than floating ranges that can drift toward a compromised release.

Data and model poisoning (LLM04) for agent builders who consume vendor APIs rather than control training

LLM04 was written with training pipelines in mind, and most teams building coding agents never touch a training pipeline. They call a vendor's model API and get back whatever that vendor shipped. Applying LLM04's original controls, the ones aimed at securing pretraining and fine-tuning data, to a team that has no access to either, is effort spent on a door nobody in the building can open.

The 2025 edition does expand LLM04 from "Training Data Poisoning" to cover model poisoning more broadly, and it's right to flag that organizations pulling third-party models inherit whatever problems exist in that model's training data and weights. If you run fine-tuned or hub-hosted models directly, that matters to you. But for the larger group of agent builders working through vendor APIs, the real exposure sits downstream of training entirely: it's the RAG corpus, the knowledge graph, and the persistent memory the agent reads from at runtime. If an attacker poisons that retrieval content, they don't need to touch a single training run. The agent pulls the poisoned material back out and treats it as authoritative, because nothing in its process tells it otherwise.

Persistent memory makes this worse in a quiet way. A coding agent that keeps task history or learned preferences across sessions builds a memory layer that can be poisoned a little at a time. Each poisoned retrieval reinforces the next, so nothing trips an alarm the way one dramatic failure would. It just drifts. Defenses here look less like training-data hygiene and more like supply chain hygiene applied somewhere new: verify where RAG sources actually come from, treat anything retrieved as untrusted input rather than ground truth, and run the same integrity checks against memory stores that you'd run against a dependency manifest.

Improper output handling (LLM05) when the sink is a shell or a build system

The opening section flagged this distinction, and here's where it actually plays out. For a chat assistant, improper output handling usually means unsanitized text reaching a browser or a database query. For a coding agent, the sink is a shell, a build system, or a CI/CD pipeline, and what's reaching it isn't a string of text but generated code, shell commands, and tool arguments that get run without a person checking them first. The blast radius is infrastructure.

OWASP's own framing lays out the core problem: when an application passes LLM output straight to another component without validation, it's trusting the model not to generate anything malicious. That trust doesn't hold up under pressure, and for agents the component on the receiving end often has the authority to modify servers, merge code, or trigger a deployment. An injected instruction that causes the agent to emit a destructive shell command is an output handling failure, and it needs defenses built for that specific failure: structural verifiers that check generated code before anything runs, a default-deny posture that forces explicit approval for high-impact commands, and sandboxed execution environments that contain the damage if a bad command slips through anyway. Agent code-execution scenarios, where generated or externally influenced code runs somewhere it shouldn't, can escalate into persistence, sandbox escape, or outright remote compromise. The output handling failure is just the delivery mechanism for something much larger.

Excessive agency (LLM06) as the structural amplifier that determines how much damage every other risk can cause

Excessive agency is the dial that sets how loud all the other nine risks get. A coding agent running with narrow permissions, minimal tool access, and a human checkpoint before anything irreversible happens caps the damage any single failure above can cause. But if that same agent runs with broad permissions, wide tool access, and full autonomy, every one of those failures turns critical, often without a single new vulnerability added to the system.

The 2025 edition expanded this entry substantially and broke it into three root causes. The agent can reach tools well beyond what its task actually requires: that's excessive functionality. Excessive permissions means those tools get more privilege than the task needs. Excessive autonomy means high-impact actions go through without a human checking any of them first. The 2026 rankings reflect how much this matters in practice: Excessive Agency climbed from sixth place to third, driven by the same shift the opening section described, output that used to be a conversation now feeds shell commands, support tickets, and production database writes directly.

A reported real-world failure shows the autonomy axis isn't theoretical: a social platform's AI assistant could relink a user's account email simply because the user asked it to, a sensitive and irreversible action the assistant was never meant to carry out on request alone. Controls map one-to-one onto the three root causes. You constrain functionality by treating task scope itself as a security boundary, not a suggestion. You constrain permissions by applying least-privilege to every tool the agent can call, not just the obviously dangerous ones. You constrain autonomy when you require a human to confirm anything irreversible or high-impact before it runs. Open-source, self-hosted agent platforms, where an organization defines and owns its own tool catalog and permission structure, make the functionality and permissions axes something a team can actually see and adjust, rather than trusting a closed system's word for it.

Slopsquatting and hallucinated dependencies: how LLM09 misinformation becomes a supply chain attack when agents install what they invent

Misinformation in a chat assistant is an annoyance: the model gives a wrong answer, a person reads it, and hopefully catches the error before acting on it. Misinformation in a coding agent skips that checkpoint. A hallucinated package name, a dependency version that was never released, a refactor the model states with total confidence and gets wrong, none of these stay harmless when the agent installs what it just invented instead of handing a suggestion to a developer who might have caught it.

That's the mechanism behind slopsquatting: attackers register packages under the names models are known to hallucinate, counting on agents to install them automatically. The 2026 edition's treatment of misinformation reflects exactly this shift: a wrong answer for a human reading a chat reply becomes an installation event in a live codebase. The fix runs through the same discipline as the supply chain section above: verify that a package actually exists and matches what it claims to be before anything gets installed, and don't let an agent's confidence stand in for a human's confirmation on anything that touches the dependency tree.