OWASP Top 10 for LLM Applications: What Security Teams Need to Know

Most application security teams have OWASP's original Top 10 memorized. Fewer have internalized the LLM-specific list, even though most of us shipped an LLM-backed feature this year. The categories are different enough from classic web risks that they deserve their own mental model, here's ours, with the failure modes we see most often in real engagements.

Prompt injection

The headline risk, and the one most teams underestimate. Untrusted input, a user message, a scraped webpage, a document the model is asked to summarize, can contain instructions that override the system prompt's intent. Indirect prompt injection, where the malicious instruction rides in through a tool call's output rather than the user's own message, is the variant we see bypass naive defenses most often.

Insecure output handling

Treating an LLM's output as trusted content is the new version of trusting user input. If a model's response gets rendered as HTML, executed as code, or passed unsanitized into a downstream API call, you've reintroduced classic injection classes, XSS, SSRF, command injection, with the model as the delivery mechanism instead of a form field.

Training data & retrieval poisoning

For RAG systems especially: if an attacker can influence what gets indexed into your retrieval store, a support ticket, a wiki page, a public doc, they can influence what the model treats as authoritative context later. This is a supply-chain problem wearing an AI costume, and it needs the same access controls you'd apply to any other write path into a trusted data source.

Excessive agency

The category that matters most as products move from chatbots to agents. An LLM wired to send emails, execute code, or call internal APIs inherits every prompt-injection risk above, but now the "output" is an action with real-world consequences. The fix isn't smarter prompts, it's the same least-privilege scoping you'd apply to any service account, plus human confirmation for anything irreversible.

Sensitive information disclosure

Models memorize, and fine-tuned or heavily-prompted systems can be coaxed into repeating training data, system prompts, or context they were given earlier in a session. If your system prompt contains anything you wouldn't want a user to see verbatim, internal policy text, other customers' data, credentials, assume it will eventually leak.

Supply chain

Third-party models, fine-tunes, plugins, and embedding pipelines all extend your trust boundary. A compromised or malicious model artifact from an open weights repository is functionally similar to a compromised npm package, except the "code" is a few billion opaque parameters, which makes review much harder.

Every one of these categories has one thing in common: the fix is rarely a smarter model. It's the access control, output handling, and scoping decisions your team already knows how to make for classic web systems, applied to a new attack surface.

How this changes testing

Testing for these risks looks less like a signature scan and more like adversarial conversation: crafting inputs designed to hijack intent, checking whether outputs are sanitized before reaching a sink, and probing whether an agent's tool access can be abused beyond its intended scope. That's exactly the kind of multi-step, hypothesis-driven testing we cover in our guide to agentic penetration testing, and it's why LLM and agent surfaces are one of the fastest-growing categories in our own engagements.