Your AI feature returns good answers, passes every functional test, and behaves as expected with the inputs your team tried. In a demo, it looks finished.
However, none of that means it is ready for production.
Traditional software testing asks whether an application behaves as intended. AI applications add a different layer of questions: can untrusted content change what the model does, can it expose data it shouldn’t, what can it access or execute, can its output become dangerous input elsewhere, and can someone exhaust its compute budget or manipulate what it retrieves?
An LLM is not just another application component: its behaviour can be shaped by the content it processes. A user prompt, retrieved document, or tool response can all influence what it does next, in ways a traditional function call cannot.
This is where the OWASP LLM Top 10 becomes useful. This article uses OWASP’s current 2026 edition of the Top 10 for LLM Applications
Start With the AI Feature’s Attack Surface
Before working through the ten categories in the OWASP LLM Top 10, it helps to map what the feature can actually receive, access, and affect. This is the groundwork for any AI feature security review, and it matters more than the checklist itself.
What goes into the model?
Inputs are not limited to what a user types. They typically include user prompts, uploaded documents, retrieved content, database records, conversation history, memory, API responses, tool outputs, and in multimodal features, images or other file types. Each of these is a potential channel for untrusted content to reach the model.
What does the model have access to?
Map what the feature can reach once it is running: APIs, databases, internal services, files, vector databases, SaaS systems, tools and functions, credentials, and cloud resources. This map is what turns an abstract worry about “the model doing something wrong” into a concrete list of systems that need their own controls, and it is where any useful AI security checklist should start.
Where does the output go?
Output rarely stays in a chat window. It can reach a database, another API, HTML rendered in a browser, a SQL query, a shell command, business logic, another model, or an agent that takes further action. Each destination has its own rules for what “safe” input looks like, and the model does not know those rules.
The OWASP LLM Top 10 Pre-Release Checklist
For each risk below, ask three questions: what can go wrong, how would we test for it, and what control needs to exist before release. This is the core of any practical LLM security checklist, and it is where the OWASP LLM Top 10 2026 earns its place on an engineering team’s release process. Treat it as the backbone of your AI application security work rather than a one-time audit before launch.
LLM01: 2026 Prompt Injection
Can untrusted content change what the model does? Direct injection comes from the user’s own prompt; indirect injection arrives through retrieved documents, tool or API responses, persistent memory, or multimodal content such as images. The 2026 treatment broadens the attack surface well beyond the text a user types.
Before release, verify:
- Malicious user prompts have been tested
- Malicious retrieved documents have been tested
- Uploaded files have been tested
- Tool and API responses containing instructions have been tested
- Persistent conversation and memory behaviour has been tested
- Trusted instructions are separated from untrusted content
- Authorization is enforced outside the model
- Tool permissions are restricted
- High-impact actions require human approval
No filtering approach fully prevents prompt injection. The realistic architectural goal is limiting what a successful injection can cause.
LLM02: 2026 Sensitive Information Disclosure
Can the feature reveal information the requesting user isn’t authorized to see? This covers PII, financial data, credentials, internal documents, proprietary information, cross-tenant data, sensitive retrieved context, and anything that ends up in logs or traces.
Before release, verify:
- Authorization is enforced before retrieval, not after
- Sensitive data sent to the model is minimised
- Tenant isolation is enforced
- Sensitive fields are redacted where appropriate
- Cross-user access has been tested
- Cross-role access has been tested
- Logs and traces have been reviewed for leaked data
- Attempts to extract restricted context have been tested
Do not use the LLM as the access-control mechanism. Authorization needs to happen in the application layer, independent of what the model decides to say. This is exactly the kind of gap a disciplined LLM security checklist is meant to catch before release.
LLM03: 2026 Excessive Agency
The OWASP LLM Top 10 2026 edition ranks this third, and it deserves the attention that ranking implies. The core question is simple: what can the AI actually do? Break it into excessive functionality, excessive permissions, and excessive autonomy.
Before release, verify:
- Unnecessary tools have been removed
- Tool operations are restricted to what is needed
- Tool identities use least-privilege access
- High-impact actions have approval gates
- Tool usage is rate-limited
- Tool calls are logged
- Reversible and irreversible actions are clearly defined
- Incorrect tool selection has been tested
LLM04: 2026 Supply Chain
Tracking dependencies is a routine part of AI feature security, but it is easy to skip under deadline pressure. Do you know what components your AI feature actually depends on? This extends beyond ordinary software supply-chain concerns to model providers, versions, open-source models, weights, frameworks, embedding models, external APIs, plugins, tools, and data sources.
Before release, verify:
- Model versions are tracked
- Dependencies are tracked
- Component provenance has been verified
- Third-party components have been reviewed
- Model changes go through a control process
- Production versions are recorded
- Rollback procedures exist
For AI application security purposes, the distinct part is the AI-specific dependencies: model artifacts, weights, and embedding models that a conventional software bill of materials usually misses.
LLM05: 2026 Data and Model Poisoning
Could compromised data or model behaviour affect what the application produces? Data and model poisoning can target persistent data, model behaviour, or data being continuously ingested, including training and fine-tuning data, RAG knowledge bases, embeddings, and other sources that influence future responses.
Prompt injection is different: it attempts to redirect the model through instructions encountered at inference time, such as user prompts, retrieved content, or tool responses.
Before release, verify:
- Data and model provenance is established
- RAG and other continuously ingested data is validated
- Trusted and untrusted sources are separated
- Changes to data, embeddings, or models are monitored
- Behaviour is retested after data or model updates
- Rollback capability is maintained
Data provenance rarely gets the same attention as prompt handling, which is why it belongs on every LLM security checklist rather than being assumed.
LLM06: 2026 Unbounded Consumption
Can a user or process make the feature consume excessive resources or generate uncontrolled costs? The 2026 category goes beyond denial-of-service thinking to include resource and cost exhaustion, sometimes called denial of wallet. Not every expensive request is an attack, but every feature needs limits regardless of intent, and enforcing them is basic AI feature security.
Before release, verify:
- Requests are rate-limited
- Input size is limited
- Output and token usage are limited
- Concurrency is controlled
- Expensive operations are limited
- Runaway tool or agent loops are prevented
- Inference costs are monitored
- Usage alerts are set
- Tenant or user budgets are defined where relevant
LLM07: 2026 Misinformation
What happens when the model produces information that sounds credible but is wrong? This is broader than “LLMs hallucinate,” covering incorrect, unsupported, incomplete, or outdated information, conflicting sources, and bad recommendations that trigger downstream decisions.
Before release, verify:
- High-impact claims have been identified
- Responses are grounded where appropriate
- Critical outputs are validated
- Conflicting information has been tested
- Stale information has been tested
- Unsupported responses can be detected
- Unverified outputs cannot trigger high-impact actions on their own
The useful pattern here is generate, verify, act, rather than generate and act directly.
LLM08: 2026 Hidden Context Exposure
This category is one of the more revised entries in the OWASP LLM Top 10 2026 edition. Can information deliberately kept outside the user’s visible context be exposed? This is broader than the older idea of system prompt leakage, covering system instructions, hidden workflow rules, tool schemas, internal context, retrieved information, and other context the user isn’t meant to see.
Before release, verify:
- Hidden context has been identified and catalogued
- Secrets are never stored in prompts
- Extraction attempts have been tested
- Tool and schema exposure has been reviewed
- Retrieved context has been reviewed
- Hidden instructions are assumed to be inferable, not permanently secret
A system prompt is not a secure secret store. Credentials, API keys, and similar secrets should never live in one.
LLM09: 2026 Vector and Embedding Weaknesses
Can the retrieval layer expose, distort, or incorrectly isolate information? In RAG applications, weaknesses can exist in how embeddings are generated, stored, searched, and retrieved. Beyond access-control failures, attackers may manipulate similarity search, exploit embedding exposure, poison retrieved content, or use retrieval behavior to uncover sensitive information.
Before release, verify:
- Authorization is enforced around retrieval
- Tenant isolation is enforced
- Metadata filters are validated
- Vector databases and indexes are protected
- Cross-tenant retrieval has been tested
- Embeddings cannot be exposed or inverted to reveal sensitive source information
- Similarity-search and retrieval manipulation have been tested
- Search results cannot reveal sensitive information through indirect or unintended matches
- Deleted-data behaviour has been tested
- Retrieval anomalies are monitored
Vector security extends beyond access control. So, embedding exposure, retrieval manipulation, and unintended information disclosure also need to be tested.
LLM10: 2026 Improper Output Handling
This is one of the most overlooked parts of AI feature security, precisely because the model’s job looks finished once it produces an answer. What happens after that output is produced?
Treat model output as untrusted input to whatever it reaches next, whether that is SQL, HTML, an API, a shell command, a file path, executed code, tool parameters, business logic, or AI-generated code.
Before release, verify:
- Structured output is validated against a schema
- Database queries are parameterized
- Output is encoded for its destination
- Output is sanitized where required
- Tool arguments are validated
- File paths are validated
- Generated commands are never executed blindly
- AI-generated code is reviewed, security-tested and validated before it is committed or deployed
- Malicious model outputs have been tested
The Risks Don’t Exist in Isolation
It is tempting to treat the OWASP LLM Top 10 as ten independent boxes on an LLM security checklist. In production, the more damaging failures usually come from risks chaining together.
For example, a malicious document can trigger prompt injection, which leads to sensitive information disclosure. Prompt injection can also trigger excessive agency and an unwanted tool action. Poisoned data can produce misinformation, while improper output handling can turn a plausible response into a downstream vulnerability.
That is why the threat model needs to cover the whole AI application, not just the model.
Need to validate your AI application before production?
Ariel Software Solutions provides software testing and QA across functional, regression, API, performance, and security requirements, helping teams validate the wider application rather than the model in isolation.
Explore Ariel’s Testing & QA Services →
Turn the OWASP LLM Top 10 Into a Production Gate
Once the LLM security risks above are understood, the next step is turning them into a repeatable process rather than a one-time review.
- Before development: Map data flows, identify trust boundaries, identify sensitive data, identify model inputs and outputs, identify tools and integrations, define unacceptable failure modes, and define which actions require human approval.
- During development: Implement least privilege, add authorization, validate model inputs and outputs, add retrieval controls, add cost controls, add monitoring, and build automated and security tests alongside the feature itself.
- Before release: Validate across four buckets. Functional asks whether the feature does what it is supposed to. Security asks whether it can be manipulated, abused, or made to expose data. Integration asks whether model output can cause problems in downstream systems. Operational asks whether it can handle scale, failure, cost, and recovery.
Each release gate should produce evidence that the relevant control works. Depending on the risk, that evidence may include adversarial tests, access-control tests, schema validation, dependency checks, API tests, load tests, or integration tests. The right combination depends on the application’s architecture and threat surface.
Build Automated Evidence, Not Just a Green Test Suite
Working through the OWASP LLM Top 10 is only useful if it produces evidence, not just a completed AI security checklist. A release decision should rest on proof that the relevant controls actually work, not on a green test suite that only proves the happy path.
That evidence typically comes from a mix of regression testing, API testing, security testing, schema validation, adversarial test cases, performance and load testing, and integration testing, run as repeatable release gates rather than a one-off exercise before launch.
This is where software testing and QA across functional, regression, performance and security requirements fit into the picture, since these disciplines cover different classes of failure across the delivery lifecycle rather than at the end of it, and together they form a meaningful part of AI application security rather than a bolt-on activity.
Defining expected behavior clearly, and writing tests before the corresponding code, also strengthens this evidence base. Test-driven development does not make a feature secure on its own, but it does produce better-defined expected behaviour, which in turn supports stronger automated verification. That is a useful relationship to keep in mind, and a different claim from saying TDD delivers OWASP compliance.
The Practical OWASP LLM Top 10 Release Checklist
This table turns the LLM security checklist above into something you can act on, not just read. For each risk, it sets out what to verify before shipping and what evidence should exist to back that up.
| OWASP risk | Before shipping, verify | Evidence |
|---|---|---|
| Prompt Injection | Injection attempts are tested and cannot cause unauthorized access or actions when application-level controls work as designed. | Adversarial tests |
| Sensitive Information Disclosure | Users receive only authorised information | Access-control tests |
| Excessive Agency | Tools and permissions are least-privileged | Tool/permission review |
| Supply Chain | Models and dependencies are tracked | Dependency/model inventory |
| Data & Model Poisoning | Data, model, embedding, and continuously ingested sources are controlled and traceable | Provenance + validation + regression tests |
| Unbounded Consumption | Usage and cost have enforceable limits | Load/rate-limit tests |
| Misinformation | High-impact outputs are verified | Evaluation/test results |
| Hidden Context Exposure | Secrets are excluded from prompts, confidential context is access-controlled, and exposure attempts are tested | Extraction tests |
| Vector & Embedding Weaknesses | Retrieval respects data boundaries and embedding/retrieval behaviour does not expose or manipulate sensitive information | Isolation + retrieval-manipulation tests |
| Improper Output Handling | Outputs are validated before downstream use | Schema/integration tests |
Used this way, the OWASP LLM Top 10 becomes a chain of control, test, and evidence for each of the ten LLM security risks, rather than a list a reviewer simply ticks off from memory.
What Does Ready to Ship Actually Mean?
An AI feature is ready for production when its security controls have been tested against the ways the feature can actually be attacked or misused. Authorization is enforced outside the model, sensitive data is protected, outputs are validated, permissions and resource use are constrained, and high-impact actions have appropriate verification.
The goal is not perfect model behaviour. It is a system that can detect, contain, and recover when the model behaves unexpectedly. Working through the OWASP LLM Top 10 before release is what turns AI feature security from a slogan into a series of specific, testable controls, and it is a habit worth building into every AI application security programme, not just the first release.
Ready to Ship an AI Feature Safely?
Ariel Software Solutions helps engineering teams build security into AI-enabled applications through OWASP-aligned testing, security reviews, and ongoing quality practices.
Frequently Asked Questions
1. What is the OWASP LLM Top 10 used for?
The OWASP LLM Top 10 is used to identify and manage the most important security risks in applications powered by large language models. Teams can use it during architecture reviews, development, security testing, and pre-release validation to identify weaknesses before an AI application reaches production. The current OWASP LLM Top 10 2026 provides updated risks, attack scenarios, and mitigation guidance.
2. Is the OWASP LLM Top 10 relevant to every AI application?
Not necessarily. It is most relevant when an application uses an LLM or generative AI model as part of its functionality. The risks you need to assess depend on how the model is used, what data it can access, what systems it connects to, and what happens with its output. A simple text-generation feature will have a different attack surface from an AI application connected to sensitive data and business systems.
3. What security controls should an AI application have before going into production?
At minimum, an AI application should have strong access controls, data and tenant isolation, input and output validation, least-privilege permissions, rate and resource limits, secure third-party components, logging and monitoring, and controls for handling model failures. High-impact AI workflows should also include verification or human approval before consequential actions. The exact controls should follow the application’s threat model.
4. Can traditional application security practices protect applications that use LLMs?
They provide an important foundation, but they are not enough on their own. Practices such as secure coding, authentication, authorization, vulnerability scanning, dependency management, penetration testing, and API security still apply. However, LLM applications introduce additional risks such as prompt injection, sensitive information disclosure, misinformation, and vector or embedding weaknesses. These require AI-specific threat modelling and testing alongside traditional application security.
