OWASP Top 10 for LLM Applications: A Practical Guide to Controls

Putting a large language model into production doesn’t just add a feature. It opens a security surface your existing stack was never built to see.

Your WAF doesn’t know what a prompt injection looks like. Your DLP tool doesn’t know the model just summarized a document it was never supposed to read. Your API gateway sees a request. It has no idea the request was generated by a model that got tricked thirty seconds earlier.

The OWASP Top 10 for LLM Applications gives the industry a shared vocabulary for this problem. It’s a genuinely useful way to name and rank these risks. But naming a risk isn’t the same as controlling it.

The question that actually matters for a security team isn’t “which OWASP risk applies to my application.” It’s more specific than that: which control addresses this risk, where does that control live in the stack, and who owns it when something goes wrong.

This guide maps each of the current OWASP LLM risks to the controls that actually reduce them, where those controls operate, and where they stop being sufficient. Then it looks at what changes once that LLM stops answering questions and starts taking actions as an autonomous agent.

What Is the OWASP Top 10 for LLM Applications?

OWASP’s GenAI Security Project is the open-source community effort tracking security risk across generative AI, from LLMs to agentic systems, and the Top 10 for LLM Applications is its most widely cited output. The Top 10 for LLM Applications is its flagship output: a ranked, community-reviewed list of the most critical risks in systems built on LLMs.

The list has moved fast. The OWASP GenAI Security Project has released the 2026 edition of its Top 10 for LLM Applications, and for the first time, the ranking was shaped by real-world incident data rather than community vote alone. For the first time, the 2026 ranking combines practitioner consensus with real-world incident data. The community vote accounts for 75% of the weighting, while the remaining 25% comes from incidents drawn from public vulnerability databases and an AI-harm database.

The incident dataset included 7,714 collected incidents, of which 6,639 contained enough detail to be classified.

The 2026 ranking is: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses, and LLM10 Improper Output Handling. The biggest change is Excessive Agency, which moved from sixth place in 2025 to third in 2026. 

None of this is a compliance standard. It’s a coverage framework, a way to make sure you’ve thought about the right categories of failure before you ship, the kind of structured thinking that also underpins broader AI risk management frameworks like NIST’s AI RMF. It doesn’t tell you which controls to buy, how to configure them, or who on your team owns each one. That’s the part most teams skip.

The OWASP Top 10, Mapped to Controls

The useful question isn’t simply what each risk means. It’s what you can actually put in place to reduce it, where that control operates, and what it still can’t guarantee.

LLM01: Prompt Injection

What it means: Crafted input, typed by a user or hidden in a document, image, or tool response, pushes the model to ignore its instructions and follow the attacker’s instead.

Controls: Input filtering, instruction-hierarchy separation between system and user content, least-privilege tool access, human approval before high-impact actions, and runtime monitoring for anomalous outputs.

Limitation: You can’t patch your way out of prompt injection. It exploits LLM design itself. Filtering catches known patterns, not novel ones. The real defense is bounding what a compromised model can reach, a topic covered in more depth in this breakdown of why prompt injection isn’t solved by input filtering alone.

LLM02: Sensitive Information Disclosure

What it means: The model reveals PII, credentials, or proprietary data pulled from training data, connected systems, or session memory.

Controls: Data classification, strict access control on what the model can query, DLP scanning on both inputs and outputs, and redaction before a response reaches the user.

Limitation: DLP catches known patterns of sensitive data, not inferred or paraphrased leaks. A model can reconstruct a fact from partial context without ever quoting the source.

LLM03: Excessive Agency

What it means: The system grants a model more functionality, permission, or autonomy than its task requires, so a manipulated output turns into a harmful action instead of just a bad sentence.

Controls: Least-privilege tool scoping, approval gates on irreversible actions, a durable agent identity separate from the underlying model, and policy enforcement outside the model itself.

Limitation: Excessive agency also creates an accountability problem. If an autonomous agent makes a harmful decision, it may be difficult to determine whether the issue came from the prompt, the model, the tool, the user, or the application design, which raises legal, operational, and compliance risk.

LLM04: Supply Chain

What it means: A vulnerable or malicious component, a third-party model, a poisoned dataset, a compromised package, enters your application through the dependency chain.

Controls: Dependency scanning, model provenance documentation, artifact signing, and strict version control across every model and library in use.

Limitation: Scanning catches known vulnerabilities. It won’t catch a backdoor deliberately built into a model’s weights or a dataset that looks clean but isn’t.

LLM05: Data and Model Poisoning

What it means: Manipulated training, fine-tuning, or embedding data introduces a backdoor, a bias, or a trigger phrase that changes model behavior on demand.

Controls: Data provenance tracking, dataset validation before training, restricted write access to training pipelines, and integrity checks like hashing.

Limitation: Poisoning is often invisible until the trigger condition fires in production. Pre-deployment testing only catches what you thought to test for.

LLM06: Unbounded Consumption

What it means: An attacker, or a misbehaving agent loop, drives excessive inference requests, running up cost or degrading service for everyone else.

Controls: Per-user rate limits, budget caps on every agent invocation, resource quotas, and complexity checks on oversized prompts.

Limitation: Limits protect the budget, not the workflow. A capped agent that’s stuck in a loop still fails the task, it just fails cheaper.

LLM07: Misinformation

What it means: The model produces fluent, confident output that’s simply wrong, and a human or downstream system acts on it without verification.

Controls: Retrieval grounding, automated evaluation against known-good answers, confidence signaling in the interface, and mandatory human review for high-stakes outputs.

Limitation: Evaluation catches the errors you thought to test for. A confident wrong answer in an untested edge case still reaches the user.

LLM08: Hidden Context Exposure

What it means: This category replaces the older system prompt leakage entry. It now captures retrieved documents, memory, user information, application state, and tool responses as attack surface, not just the literal system prompt text.

Controls: Treating the system prompt as code rather than a secret store, keeping credentials out of prompts entirely, and isolating memory and retrieved context from directly influencing instructions.

Limitation: Isolation reduces exposure, it doesn’t eliminate it. Anything the model can see, it can potentially be coaxed into repeating.

LLM09: Vector and Embedding Weaknesses

What it means: Attacks against the retrieval layer itself, including reconstructing source text from embeddings or poisoning retrieval results through proximity manipulation.

Controls: Access control and tenant isolation on vector stores, embedding-level monitoring, and validation of what gets indexed in the first place.

Limitation: Most teams treat the vector database as infrastructure, not attack surface. Access controls only work if someone actually applied them there.

LLM10: Improper Output Handling

What it means: The application trusts model output and passes it downstream, into a browser, a database query, or an API call, without validating it first.

Controls: Schema validation on structured output, sanitization before rendering, and downstream authorization that re-checks permissions regardless of what the model produced.

Limitation: Validation only works against outputs you anticipated. A model that generates a plausible-looking but subtly malicious payload can slip past a schema check that only validates shape, not intent.

OWASP Top 10 for LLM Applications: Risk-to-Control Summary

Which OWASP Risks Matter Most for AI Agents?

A chatbot can generate an unsafe answer. An AI agent can turn that answer into an action, through a tool call, an API request, a database write, or a message sent on your behalf.

That shift concentrates risk in five categories: prompt injection, because an injected instruction now triggers a real-world action instead of just a bad sentence. Excessive agency, which becomes the central failure mode once a model has tools. Hidden context exposure, since agents carry memory across sessions. Sensitive information disclosure, amplified when an agent can correlate data across multiple connected systems. And supply chain risk, because an agent’s configuration, its model, tools, and permissions, is itself a chain of dependencies.

The numbers back this up. One global survey found that 80% of organizations using AI agents admitted their agents took unintended actions, including unauthorized system access and data sharing. Separate research found the gap sits between confidence and practice: 94% of enterprise IT and security leaders are confident their AI agents do not have more access than they need, yet only 33% actually provision agents with least-privilege access.

The more autonomy a system has, the less the question “what did the model generate” matters on its own. What matters is which agent generated it, what that agent was allowed to access, and what it was permitted to do with the result.

Where Do Traditional Security Controls Stop?

Most of the controls above aren’t new. IAM controls identity and access. API gateways control traffic. DLP controls sensitive data movement. WAFs protect application endpoints. These tools work, and they still matter.

What they don’t do is govern the agent as an object. An agent has an identity, a configuration, a model, a set of tools, permissions, memory, a deployment state, an evaluation history, and runtime behavior that can drift over time. None of your existing tools were built to track that object across its lifecycle, only the traffic and data it touches at any given moment.

That’s the gap OWASP itself has started to formalize. Alongside the 2026 Top 10 for LLM Applications, the OWASP GenAI Security Project debuted an Agent Control Standard and new resources for securing generative and agentic AI. Separately, on December 9, 2025, the OWASP GenAI Security Project released the Top 10 for Agentic Applications, a peer-reviewed framework built by more than 100 security experts, researchers, and practitioners. As the project’s own leads describe the boundary between the two lists: “The moment that model becomes an actor, with tools it can call, memory it carries between sessions, and consequences it sets in motion downstream, the risk moves to the OWASP Agentic Top 10.”

Reasoning follows naturally from there: when an agent calls a tool, accesses a system of record, or changes a business record, you need controls that identify the agent, evaluate the requested action, enforce policy before execution, and produce evidence afterward. Discovering which agents exist in the first place, including the ones nobody registered, is itself becoming its own control category, as covered in this look at read-only cloud scanning for AI agent discovery. That’s a governance layer sitting across your existing controls, not a replacement for them.

How Does an AI Control Plane Help Address OWASP Risks?

An AI Control Plane doesn’t solve the OWASP Top 10. What it does is give you a place to enforce and audit the agent-centric risks that traditional tools can’t see on their own.

The agent registry in particular addresses a problem most organizations underestimate: agents built outside any central inventory, running with permissions nobody is tracking. Bringing every agent into one registry, with a defined control plane architecture underneath it, is what makes the rest of these governance controls actionable.

This is one layer in a larger security architecture. It complements application security, IAM, data security, model security, and infrastructure controls. It doesn’t replace the input filters used for LLM01 or the DLP controls used for LLM02. It governs the agent operating across those controls: the identity behind it, the permissions it has, the changes made to it, and the actions it takes.

For organizations looking to put this governance layer into practice, Lyzr’s OpenController provides the agent registry, identity, evaluation, policy, observability, and audit capabilities described above.

Explore OpenController to see how it can fit into your existing AI security architecture, or book a demo to see how these controls work across your agent estate.

Where This Leaves You

The OWASP Top 10 tells you what to worry about. It doesn’t tell you who owns the fix, where it runs, or what happens when it fails quietly instead of loudly.

That’s the harder question, and it’s the one worth asking about every LLM application or agent currently in your pipeline: for each risk on this list, can you name the specific control, the layer it operates at, and the team accountable for it? If the answer is a shrug for even one of the ten, that’s where to start.

Review your current agent inventory against the checklist below, one risk at a time, before you add the next one to production.

OWASP Top 10 Controls: A Practical Checklist

Frequently Asked Questions

Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here