OWASP LLM Top 10 Controls Translated Into Agent Policy

The OWASP Top 10 for LLM Applications gives security teams a shared vocabulary for talking about model risk. But vocabulary doesn't stop an attack. It names the risk; it doesn't tell a platform team where to actually put the fence. That gap, between naming a risk and enforcing a control, is what this piece works through, control by control.

The 2026 edition, published in August 2026, marks the first time this ranking pulled from real incident data instead of running purely on expert consensus. OWASP collected 7,714 AI security incidents, got enough detail on 6,639 of them to classify by risk type, and weighted that data at 25% against a 75% community vote. That's a meaningful shift. It means the list now reflects where damage has actually happened, not just where security researchers assumed it would.

Here's where in the agent stack to actually enforce a defense. Each OWASP entry names a risk class: prompt injection, sensitive data disclosure, excessive agency. None of them tell you where in the agent stack to actually enforce a defense. A web application firewall doesn't understand prompt intent. A DLP tool has no idea the model just summarized a file it was never supposed to touch. An API gateway sees a well-formed request and has no way of knowing a manipulated model generated it. For a company running autonomous agents in production, that ambiguity is the whole ballgame.

A companion framework helps close part of that gap. The OWASP Top 10 for Agentic Applications, published December 9, 2025 with contributions from over 100 people and a review board pulling from NIST, Cisco, Microsoft, and AWS, covers what autonomous systems do, not just what models say. The two lists are meant to be read together. And the core insight running through both: agent security can't live inside the agent. The model can be tricked, the prompt can be overridden, the framework itself can be compromised. The controls that actually hold are the ones enforced outside the agent's reasoning entirely, at the infrastructure layer that governs identity, permissions, communication, and resource limits.

What follows is a translation of all ten 2026 controls into concrete enforcement decisions, the kind security and platform teams can put into a policy document this quarter.

How the 2026 ranking changed

Three movements define this year's reorder, and all three point at the same underlying trend: risk has moved from what a model says to what a system does.

Excessive Agency jumped from sixth to third. This movement is the clearest signal in the whole list. Loss is now concentrated in autonomy and tool access, not bad text output.

Unbounded Consumption climbed significantly up the list. That movement reflects growing concern about inference cost and resource exhaustion as agents operate at scale.

Misinformation moved up the list based on incident data. That's a case where the real-world evidence carried significant weight in the final ranking. That's especially important for anyone running downstream agent pipelines that act on a model's output without a human in the loop.

Improper Output Handling fell to the bottom of the list. Don't read that as the risk disappearing. It's that agent-era failures involving bad output have migrated upward into other categories, mostly agency and injection, where the consequence of a bad output is now an action, not just a string of text.

System Prompt Leakage, the 2025 entry, got renamed Hidden Context Exposure for 2026 (LLM08). The scope widened on purpose: it's no longer just about someone extracting your system prompt. It now covers retrieved documents, memory artifacts, tool schemas, and application state, all the things an agent might expose that were never meant to leave the session.

And Prompt Injection held the number one spot, despite incident data alone suggesting it should rank lower. The community's read on that: the ranking reflects the enduring scale of the attack surface, even as the list's weighting methodology balanced incident data against the practitioner vote. The threat didn't shrink.

Read the whole reorder through one lens: everywhere models gained tools, permissions, and autonomy, the failure mode stopped being "the model said something wrong" and became "the agent did something wrong." That's the frame for every translation below.

LLM01 Prompt Injection: separating instruction paths from data paths in the agent stack

Prompt injection holds the top spot because of a structural fact about how LLMs work: they process instructions and untrusted content in the exact same context window. There's no separate channel. In an agentic system, that problem gets bigger fast, because the attack surface includes every document the agent retrieves, every tool response it reads, every memory artifact it pulls back into context, not just what a user types. It's every document the agent retrieves, every tool response it reads, every memory artifact it pulls back into context.

The mental model to work from: anything an agent reads is potentially adversarial. That includes its own memory store.

Indirect injection is the threat that matters most here. An attacker doesn't need to talk to the agent directly. They embed an instruction inside content the agent will retrieve later, a PDF, a webpage, an email thread, a database record, and when the agent processes that content, the buried instruction executes as if it came from a trusted source.

So where does the control actually live?

• Instruction-hierarchy separation. Keep user input, system instructions, and retrieved content in distinct control planes, so a poisoned document can't quietly become a command channel.
• Input filtering at the gateway. Classification models trained to catch known injection patterns and toxic intent before a prompt ever reaches the model.
• Output filtering. Catch responses that suggest a system prompt got overridden or sensitive content leaked through.
• Least-privilege tool access. Filtering only catches known patterns, not novel ones. So the real defense is bounding what a compromised model can actually reach.
• Human approval gates on any action that's high-impact or hard to undo.
• Runtime monitoring for outputs that don't match expected patterns.

Filtering cannot patch the underlying design flaw. LLMs cannot reliably tell instruction apart from content, full stop. The durable control sits outside the model, in policy.

In practice, that means validating anything before it gets written to persistent memory, scoping context tightly per task, and requiring confirmation screens that show the raw action an agent is about to take, not a summary the agent wrote about its own action.

LLM02 Sensitive Information Disclosure: moving authorization outside the model

Models leak sensitive data in a few distinct ways: memorized training data resurfacing, sensitive inputs that end up persisted in provider logs, and confidential content ending up in an output that a downstream system then stores somewhere it shouldn't.

The failure pattern shows up constantly: a system prompt holds business logic, API endpoints, maybe credentials, treated as a secret, and then someone finds a way to talk the model into reciting it back.

OWASP's guidance here is specific. Extensions and tools should run in the requesting user's own security context, not under some generic high-privilege service identity. And authorization decisions need to happen in a deterministic external system, never inside the model's own generated reasoning.

Where the control lives:

• Data classification upstream of the model. Know what's sensitive before it ever enters a context window.
• Strict access control on what the model can query. If a user can't see a piece of data directly, the model acting on their behalf shouldn't be able to either.
• DLP scanning on both inputs and outputs, enforced at the gateway.
• PII filtering at the gateway, catching names, contact details, government IDs, and similar identifiers before they reach the model provider. For regulated workloads under HIPAA, PCI, or GDPR, this gateway check is the actual compliance boundary, not a nice-to-have.
• Redaction before a response reaches a user or gets passed to another agent downstream.

DLP catches known patterns, not inference. A model can reconstruct a fact from scraps of context without ever quoting the original source verbatim, and no pattern-matcher catches that. Access scoping at ingestion, before the data ever enters the pipeline, is the defense that actually holds.

The policy decision that matters most: an agent's credential scope has to mirror the permissions of the person who delegated to it, and that mirroring has to be enforced in an external system. Not asserted in a prompt, where it can be argued with.

LLM03 Excessive Agency: enforcing least privilege at tool call depth

OWASP identifies multiple root causes here, and each one needs its own fix: agents reaching tools unrelated to their actual job, tools running with more privilege than tasks require, and high-stakes actions executing without any human check.

The attacks that come out of this aren't exotic. An agent with email access gets manipulated into sending phishing messages. An agent with database write access gets talked into deleting records it had every legitimate right to touch. The agent's authorized permissions become the weapon. Nobody had to break in.

That creates an accountability mess, too. When an autonomous agent takes a harmful action, figuring out whether the root cause was the prompt, the model, a tool, the user, or a design flaw in the application becomes a legal and operational headache fast.

The fix has to operate at four separate points:

• Least-privilege tool scoping per agent. Each agent gets access only to the tools its specific task requires, never a shared high-privilege identity everyone borrows.
• Per-agent tool allowlists enforced at the infrastructure layer, not buried in a system prompt where anyone can talk the model out of following it.
• Approval gates on anything irreversible. These need to display the raw action, not an agent's own summary of what it's about to do.
• A durable agent identity, separate from the underlying model, so actions can actually be attributed, and permissions can be scoped down or revoked without touching the model itself.

OWASP's Agentic framework has a name for the underlying principle: Least Agency. Grant an agent only the autonomy required for the specific, bounded task in front of it. Autonomy itself is now a dial to govern, the same way access has always been governed.

Platforms enforcing MCP authorization at the method level, with fine-grained rules scoping what an agent can call and on whose behalf, are addressing OWASP's root causes at once, not just one of them.

LLM04 Supply Chain: extending vendor review to runtime tool discovery

The classic supply chain risks still apply in full: compromised third-party models, poisoned training datasets, malicious packages, vulnerable frameworks. The same discipline that's existed in traditional software for years, verified sources, signed artifacts, dependency scanning, runtime monitoring, applies just as much to AI components.

Agents add a new wrinkle: they discover and wire up tools during execution, not just at deploy time. That turns supply chain risk into something dynamic. Malicious MCP servers, tampered agent cards, unvetted tool registries, connectors pulled in on the fly, all of it can introduce untrusted code into a session that's already live.

There's a real example that shows exactly how this plays out. CVE-2025-6514 carried a CVSS score of 9.6, discovered by the JFrog Security Research Team and disclosed in mid-2025. It hit mcp-remote, a package sitting between MCP clients and remote servers, in versions 0.0.5 through 0.1.15. The vulnerability allowed a trusted-looking protocol step to become an injection point.

Tool poisoning, sometimes called a rug pull, is the subtler version. A tool's description looks fine, or passes an initial review, and then gets quietly updated later to do something else. The model trusts tool metadata by default, so a deceptive description is an attack vector all on its own, no code exploit required.

Two controls have to run side by side here, because neither one covers for the other. Artifact verification, scanning, signing, checking provenance, tells you a component was safe at the moment it came in the door. It says nothing about which agents should be allowed to call that server later, at runtime. Access enforcement, allowlists and runtime authorization, governs who can call what, but it doesn't tell you the tool itself is trustworthy.

The policy translation: MCP server registries need curation and allowlisting, runtime tool discovery has to stay scoped to pre-approved sources, and any change to a tool's schema should trigger a re-review before agents are allowed anywhere near the updated version.

LLM05 Data and Model Poisoning: controlling what enters vector stores and RAG pipelines

Poisoning can happen at pre-training, at fine-tuning, during RAG ingestion, or through a compromised adapter someone plugged in without a second look. The unsettling part is that a poisoned system can behave completely normally right up until a specific trigger condition sets off the planted behavior.

For most agent deployments, RAG is where this risk actually lives day to day:

• Attackers slip malicious content into a vector database, knowing it'll surface during an ordinary, legitimate query later.
• Weak access controls on the vector store let sensitive data leak across tenant boundaries that were supposed to be sealed off from each other.
• Embedding models themselves can be manipulated to return misleading similarity results, which quietly degrades everything the RAG system retrieves afterward, without any single query looking wrong on its own.

Any organization pulling in a third-party model inherits whatever's baked into its training data and weights, often without any visibility into what that is. Verifying data provenance and testing for behavior that doesn't match expectations are the primary defenses at the point of intake.

Where the control lives:

• Data provenance verification before anything enters a RAG pipeline or a fine-tuning run.
• Clean, auditable training pipelines, with integrity checks built into each stage rather than one check at the end.
• Access controls on vector stores enforced at query time, not just when data is first ingested.
• Agent identity propagated into vector store authorization, so a cross-tenant retrieval gets blocked at the query itself, not caught after the fact in a log review.
• Runtime monitoring for behavior that doesn't match the model's baseline, which can be the first sign of a planted trigger.

The policy decision, stated plainly: vector store access follows the same identity and scoping rules as tool access. An agent should never be able to query a document store with broader reach than the human who delegated the task to it in the first place.

LLM06 through LLM10: the five controls that govern agent output, resource use, and context exposure

LLM06, Unbounded Consumption, is the cost and availability control, and it earned its jump from tenth to sixth for a practical reason: agentic fan-out. A single user request can spin off multiple agent sub-tasks, each one making its own model calls, its own tool invocations, its own API hits. Rate-limiting the original request does nothing to contain that. The policy answer is per-agent token budgets, per-agent rate limits, and cost attribution tied to individual agent identities, sized to the fan-out multiplier, not the rate of the request that started the chain.

LLM07, Misinformation, moved from ninth to seventh on incident data alone, even with a lower expert-vote ranking. That gap matters. It means real harm is showing up when a fabricated output gets acted on downstream, by another agent or by a human who trusted the summary instead of checking the source. The policy lever here is grounding: outputs feeding into downstream automated decisions need a verification step before anything acts on them, not after.

LLM08, Hidden Context Exposure (the renamed System Prompt Leakage), now covers a wider surface: retrieved documents, memory contents, tool schemas, and application state, anything an agent might expose beyond the literal system prompt. Enforcement means auditing what actually flows into a model's context window per session, and treating that context as sensitive by default, not just the prompt template itself.

LLM09, Misinformation's neighbor in the excessive-agency family, and LLM10, Improper Output Handling, round out the list. Output Handling fell from fifth to tenth this year because so many of its failure modes have effectively been absorbed into agency and injection risk higher up the list. Bad output used to just be embarrassing. Now, when an agent acts on its own bad output without a human checking first, it's an incident.

Across all five of these, the pattern from earlier holds: the fix is never inside the model. It's a budget enforced at the identity layer, a grounding check enforced before an action fires, an audit of what context actually reaches the model, and an approval gate before output turns into action. Ten risk categories, one repeated architectural answer: govern it outside the agent, or don't count on governing it at all.