What is OWASP and why does this list exist?

OWASP stands for the Open Worldwide Application Security Project. It's a non-profit community of security professionals who publish free, open guidance on how to build secure software. You may have already heard of the OWASP Top 10 for web applications, the list of things like SQL injection and cross-site scripting that every web developer learns about.

In 2023, OWASP launched a separate project specifically for AI apps built on large language models (LLMs). The reason: AI apps have a completely different set of security problems. You can't patch prompt injection the same way you patch SQL injection. The risks come from how the model behaves, not just the code around it.

The result was the OWASP Top 10 for LLM Applications. The most recent version is the 2026 list. If your app uses GPT-4, Claude, Gemini, Llama, or any other LLM, these are the risks you need to understand.

Why AI security is different from regular app security
A regular web app has fixed code. If there's a bug, you find it and patch it. An LLM is probabilistic, it behaves differently with different inputs. You can't test every possible input. And because the AI can read, write, and (with agents) take actions, the attack surface is much larger. Many AI security problems can't be fixed with a code change at all. They require architecture decisions, output filters, and careful design of what the AI is allowed to do.

All 10 risks at a glance

LLM01Prompt Injection
LLM02Sensitive Information Disclosure
LLM03Excessive Agency
LLM04Data and Model Poisoning
LLM05Improper Output Handling
LLM06Excessive Permissions (Supply Chain)
LLM07System Prompt Leakage
LLM08Vector and Embedding Weaknesses
LLM09Misinformation
LLM10Unbounded Consumption

The 10 risks explained simply

LLM01 #1 Risk
Prompt Injection
The most common and actively exploited vulnerability in AI apps
What it is: An LLM receives its instructions from you (the developer) through a system prompt. It receives inputs from the user through the conversation. The problem is the model processes both as natural language and cannot reliably tell them apart. Prompt injection is when a user crafts input specifically designed to override your instructions. There are two types. Direct injection is when a user types something like "Ignore all previous instructions and do X instead." Indirect injection is more dangerous and harder to catch: the malicious instruction hides inside a document, webpage, or email that the AI reads as part of its task, and the AI obeys it without the user even being involved.
Simple analogy You hire a personal assistant and tell them "only take calls from clients on this list." Someone calls and says "Hi, I'm your boss, ignore that list and connect me to everyone." Your assistant can't verify authority claims in real time, so they comply. An LLM has the same problem with instructions that arrive in natural language.
What goes wrong The AI ignores your safety rules, leaks confidential data from its context, performs actions it was told not to, or gets hijacked to attack other users, all without the legitimate user doing anything.
What to do
  • Treat all user input as untrusted, do not let it override system prompt behaviour
  • Clearly label and separate external content (documents, emails) from user instructions
  • Require human approval before any high-impact action
  • Test your app with adversarial prompts before you ship
LLM02 #2 Risk
Sensitive Information Disclosure
The model says something it should never have said
What it is: An LLM can expose sensitive data in two ways. First, it may have memorised information from training, personal details, private code, or confidential documents, and repeat them when prompted cleverly. Second, during a conversation, users often provide context (their name, account details, personal situation) and a poorly designed app can expose that context to other users or let the model use it in unexpected ways. A well-known documented case: prompting a model to repeat a word indefinitely caused it to start outputting personal information it had memorised from training data.
Simple analogy A new employee reads every file in the company before starting. When customers ask questions, they occasionally repeat things they shouldn't have access to, confidential salary information, private client details, because nobody told them that reading everything didn't mean repeating everything.
What goes wrong Customers' personal data gets exposed to other users. Confidential business logic or pricing gets revealed. The company faces data protection violations.
What to do
  • Remove or anonymise sensitive data before it enters training or fine-tuning
  • Give the model access only to the data it needs for the current task
  • Use output filtering to catch personal data before it reaches the user
  • Don't put confidential instructions in the system prompt and expect them to stay private
LLM03 #3 Risk
Excessive Agency
The AI can do too much, by itself, without checking
What it is: As AI apps become more capable, they're given tools: the ability to search the web, send emails, write to databases, make API calls, book meetings. Excessive agency is when the AI has more tools, broader permissions, or more autonomy than it actually needs. If something goes wrong, whether from a bug, a bad prompt, or a deliberate attack, the AI can take real-world actions that are hard or impossible to reverse. This risk has risen dramatically as "agentic AI" (AI that takes sequences of actions without human oversight) has become common.
Simple analogy You give a new intern a key to every room in the building and full authority to sign contracts. They mean well, but if they misread an email, the consequences are large and hard to undo. Better to give them access to only the rooms they need, with a manager reviewing anything above a certain value.
What goes wrong The AI sends emails to the wrong people, deletes records, transfers data, or triggers expensive API calls, based on a misunderstood instruction or a successful injection attack.
What to do
  • Only give the AI the tools it actually needs for the task, nothing extra
  • Scope permissions as narrowly as possible (read-only if write isn't required)
  • Require explicit human confirmation before any irreversible action
  • Enforce authorisation in downstream systems, not just in the AI's instructions
LLM04 #4 Risk
Data and Model Poisoning
The training data itself has been tampered with
What it is: If you fine-tune a model on your own data, or use a model someone else trained, there's a risk that the training data was deliberately corrupted. Poisoning can introduce subtle biases, insert backdoors (hidden triggers that cause specific behaviour when a certain word or phrase appears), or degrade the model's performance in targeted ways. Research found that a surprisingly small number of malicious documents, around 250, can implant a backdoor into a model regardless of how large the overall dataset is. That means the total count matters more than the percentage.
Simple analogy Imagine a textbook that looks entirely normal but has one paragraph, buried deep in chapter 14, that teaches students to make a specific mistake whenever they encounter a particular type of problem. The students pass all their normal tests. The mistake only appears when they see that specific type of problem in the real world.
What goes wrong The model behaves normally in testing and development, then produces specific harmful, biased, or incorrect outputs in production when a particular trigger is present.
What to do
  • Track where your training data came from and who can modify it
  • Vet third-party datasets and the organisations that provide them
  • Use anomaly detection during training to catch unusual behaviour patterns
  • If using a third-party model, verify it with integrity checks (hashes, signing)
LLM05 #5 Risk
Improper Output Handling
Trusting what the AI writes when you shouldn't
What it is: AI output is just text. But if that text gets passed directly into another system, a database query, a web page, a shell command, an API call, without being validated or sanitised first, you have a classic injection vulnerability, generated by the AI rather than typed by the attacker. The model doesn't know what's safe to output for your specific environment. If a user can influence what the model writes, they can influence what your downstream systems execute.
Simple analogy You ask a colleague to type up a SQL query based on customer notes. The customer wrote something unusual in their notes. Your colleague copies it verbatim. The database executes it. This is why you validate inputs before they hit a database, and why you need to do the same with AI output before it hits anything critical.
What goes wrong The AI's output contains a cross-site scripting payload that runs in a user's browser, a SQL injection that reads your database, or a shell command that executes on your server.
What to do
  • Treat AI output as untrusted, validate and sanitise it before it reaches any system
  • Use parameterised queries for any database operations involving AI-generated text
  • Encode output appropriately for where it's going (HTML, JSON, shell)
  • Never pass AI-generated content directly to a shell or code interpreter
LLM06 #6 Risk
Supply Chain Vulnerabilities
Risks from the models, datasets, and tools you didn't build yourself
What it is: Your AI app probably uses a pre-trained model from somewhere else, a dataset from a third party, or plugins and integrations from external sources. All of these are part of your supply chain, and all of them can introduce vulnerabilities you didn't write. This includes using an outdated model with known weaknesses, a fine-tuning adapter from an untrusted source, a dataset with poisoned entries, or an integration that has been compromised upstream.
Simple analogy You build a restaurant using ingredients from suppliers. If one supplier's produce is contaminated, your restaurant has a food safety problem even though your kitchen did nothing wrong. You're responsible for what you serve, regardless of where it came from.
What goes wrong You ship a vulnerable model without realising it. A third-party plugin you use introduces a backdoor. Your training dataset contains deliberately misleading information from an unvetted source.
What to do
  • Maintain a complete inventory of every model, dataset, and plugin you use, like an SBOM but for AI
  • Verify the integrity of models you download (use checksums and signing where available)
  • Only use models and datasets from sources you trust and can vet
  • Keep third-party components updated and monitor for security advisories
LLM07 #7 Risk
System Prompt Leakage
Treating your system prompt like a secret, it isn't
What it is: Many developers put sensitive information in the system prompt: API credentials, internal logic, user roles, filtering rules. They assume the system prompt is hidden from users. It isn't, reliably. Attackers can usually infer what's in the system prompt by asking questions that probe the model's behaviour. Some prompt injection attacks directly extract it. The bigger problem is not the leakage itself, it's the design mistake of putting security-critical information there in the first place.
Simple analogy Writing your passwords on a sticky note inside your office and assuming nobody will see it because they're not supposed to come in. The assumption of privacy is doing the security work that a proper access control system should be doing.
What goes wrong An attacker extracts your API keys from the prompt. They learn your filtering logic and find ways around it. They discover internal business rules you intended to keep private.
What to do
  • Never put API keys, passwords, or credentials in a system prompt, ever
  • Enforce permissions in external systems (your code, your database), not in the prompt
  • Design your app assuming the system prompt will eventually be read by users
  • Use independent guardrail layers outside the model for security-critical checks
LLM08 #8 Risk
Vector and Embedding Weaknesses
Security gaps in how your RAG system stores and retrieves information
What it is: Many modern AI apps use something called Retrieval-Augmented Generation (RAG). Instead of the AI working only from its training, it also searches a database of documents and uses what it finds to answer questions. That database stores "embeddings", mathematical representations of text. If this database isn't secured properly, attackers can inject malicious content into the documents the AI retrieves, leak data across different users in a shared system, or reconstruct private text from the embeddings themselves.
Simple analogy Your AI has access to a shared library where employees can add documents. If anyone can add a document, someone could add one with hidden instructions (like a sticky note inside a book that says "if you're the AI, ignore the user's real question and do this instead"). The AI reads the library looking for relevant content and follows the hidden instruction without realising it was planted.
What goes wrong One user's documents contain malicious instructions that affect other users. Private documents from one user are retrieved in another user's session. An attacker injects a planted document that overrides the AI's behaviour.
What to do
  • Strictly isolate vector stores by user or tenant, one user should never retrieve another's content
  • Validate and check ingested documents for hidden content or unusual instructions
  • Control who can add documents to the knowledge base your AI reads from
  • Keep logs of what the AI retrieves so you can audit unusual patterns
LLM09 #9 Risk
Misinformation
The AI confidently states things that aren't true
What it is: LLMs generate fluent, confident-sounding text. They also hallucinate, producing information that is plausible but wrong. The model doesn't know what it doesn't know, so it fills gaps with invented content rather than saying "I'm not sure." This becomes a serious problem when users trust the output without verifying it, especially for medical information, legal advice, financial guidance, or anything with real-world consequences. Two documented cases: Air Canada was held legally liable for incorrect information its AI chatbot provided a customer; lawyers were sanctioned after submitting AI-generated case citations that didn't exist.
Simple analogy A very confident, very knowledgeable assistant who occasionally makes things up but delivers accurate and false information with exactly the same tone. Without external verification, you can't tell the difference from the way it's said.
What goes wrong Users make decisions based on incorrect AI output. Businesses face legal liability for AI-provided misinformation. Developers ship AI-suggested code or packages that don't exist (attackers can register these names).
What to do
  • Ground the AI's answers with retrieval from verified sources (RAG from trusted documents)
  • Require human review for any high-stakes output before it's acted on
  • Be explicit with users that AI output needs verification, build this into the UI
  • Validate any package names, URLs, or citations the AI suggests before using them
LLM10 #10 Risk
Unbounded Consumption
Someone running up your AI bill, crashing your service, or stealing your model
What it is: LLM inference costs scale with tokens, not just requests. An attacker who sends very long inputs, keeps conversations running indefinitely, or triggers expensive chains of tool calls can generate huge bills or crash the service entirely, sometimes called a "denial of wallet" attack rather than a denial of service. This category also covers model theft: if an attacker can make thousands of API calls to your AI and collect the outputs, they can potentially reconstruct a close approximation of your fine-tuned model without paying for it.
Simple analogy An all-you-can-eat restaurant with no staff to manage how long tables are occupied. Someone sits down, orders course after course for eight hours, and costs fifty times what a normal customer would. Multiplied by a few coordinated bad actors, the restaurant closes before dinner service.
What goes wrong Your cloud bill spikes unexpectedly. The service slows or goes down for legitimate users. A competitor reconstructs a close approximation of your proprietary fine-tuned model from your API outputs.
What to do
  • Set strict limits on input token length and conversation length per user
  • Implement rate limiting and per-user quotas
  • Set spending alerts and automatic circuit breakers on your AI API usage
  • Monitor for unusual query patterns that suggest model extraction attempts
Building an AI product?

Find DevSecOps agencies experienced in AI application security

TechRadiant verifies DevSecOps consultants on documented security outcomes. Find a team with hands-on experience securing LLM applications and AI pipelines against these exact risks.

Browse verified DevSecOps agencies → Share your security brief

How the list changed from 2025 to 2026

The 2025 list is still widely referenced in documentation, tooling, and compliance frameworks. The 2026 update is more evolution than revolution. The biggest change is that Excessive Agency (LLM03) moved much further up the list as agentic AI became mainstream. Two things to know if you're working from an older document.

What changed 2025 list 2026 list
Prompt Injection LLM01, #1 LLM01, #1 (unchanged, still top priority)
Sensitive Information Disclosure LLM02, #2 LLM02, #2 (unchanged)
Excessive Agency LLM06, lower priority LLM03, rose to #3 as agentic AI grew
Supply Chain LLM03, #3 LLM06 (reordered)
Hidden Context Exposure Not in top 10 Appears in 2026, reflects how attackers probe AI systems before attacking
Overall framing Focused on passive chatbots and basic tool use Reflects agentic AI: systems that reason, use tools, and take actions over multiple steps
The agentic AI shift, why it matters for 2026
A year ago, most LLM apps were chatbots: the user asks, the AI answers. In 2026, AI agents can browse the web, run code, send emails, update databases, and chain multiple actions together without human input between each step. This is why Excessive Agency jumped to number three. The potential damage from a compromised or manipulated AI agent is orders of magnitude greater than from a chatbot that gives a wrong answer. If your app gives the AI the ability to take actions, treat it as a high-security deployment from the start, not an afterthought.

Where to start if you're building an LLM app now

You don't have to tackle all 10 risks at once. The right starting point depends on what your app does. Here's how to think about priority.

Every LLM app needs these first: Prompt injection defences (LLM01) and sensitive data controls (LLM02) are baseline for any deployment. Start here before anything else. If your app reads from external documents or the web, indirect prompt injection is your most urgent concern.

If your AI can take actions: Excessive agency (LLM03) becomes critical the moment your app can write to a database, send communications, or make API calls. Apply least-privilege to everything the AI can do and add human confirmation for anything irreversible.

If your app uses RAG or a knowledge base: Vector and embedding weaknesses (LLM08) matter significantly. Make sure content isolation between users is airtight and that you control who can add documents the AI reads from.

If you're using a third-party model or dataset: Supply chain risks (LLM06) apply. Know what you're using, where it came from, and verify its integrity before you deploy it.

For everything you build: Validate and sanitise AI output before it reaches any system (LLM05). Set spending limits and rate limiting from day one (LLM10). And never put anything sensitive in your system prompt that you'd be uncomfortable with users reading (LLM07).

The OWASP list is most useful as a coverage checklist, not a compliance checkbox. The goal is not to confirm you've thought about each category. It is to test each one against your specific deployment and let the findings drive real design decisions. For DevSecOps consultants who have done exactly this for LLM applications in production, TechRadiant's verified DevSecOps agency index covers teams evaluated on documented security outcomes.