OWASP Top 10 for LLMs is a community-ranked list of the most common security risks affecting large language model applications. It frames how prompt injection, data leakage, insecure tool use, and model abuse can expose AI systems, then helps teams prioritize controls across identity, access, data handling, and runtime governance.
What this framework covers
owasp top 10 for LLMs is not just a list of weaknesses, it is a practical risk taxonomy for how LLM applications fail in production. It helps teams think about where user input, retrieved data, tools, and output handling can be abused.
The value of the list is that it turns a broad and fast-moving space into a shared language for design reviews, testing, and remediation prioritisation. A useful way to read it is as a map of where trust boundaries break down in an LLM stack, not as a fixed checklist of products or features.
Why LLM applications are exposed differently
LLM systems create risk through interaction, not just through code execution. A model may answer safely in one prompt and unsafely in another, so the security problem is often about controlling influence over context, instructions, retrieved content, and connected tools.
That is why prompt injection, indirect prompt injection, and unsafe tool use matter so much. The issue is not merely malformed input, but the ability of untrusted content to steer behaviour, override intended policy, or trigger actions the operator never meant to allow.
The same pattern appears when the model can read or surface sensitive data. If retrieval, memory, logs, or output controls are weak, the system can expose private records, credentials, or internal instructions even when the underlying model is functioning “correctly.” For a broader foundation on the underlying web and app risk model, the OWASP Top 10 Guide is a useful companion reference.
How the OWASP list relates to identity and access
Several LLM risks are really identity and access problems in disguise. When a model can call tools, query systems, or act on behalf of a user, the real question becomes which identity is allowed to do what, under what conditions, and with what auditability.
That is why strong implementations tie LLM behaviour to least privilege, scoped credentials, explicit approvals, and separate runtime identities for the model, orchestration layer, and downstream services. A compromised prompt should not become a privileged action path, and a low-trust user input should not inherit high-trust system permissions.
This matters even more in connected environments where the model can reach internal data stores or external APIs. Identity missteps can turn a language model from a productivity layer into a high-speed access broker. The AI Infrastructure Workload Identity Guide shows how those runtime identities should be separated and governed, while the Permission-Aware RAG Guide explains how retrieval must respect source permissions rather than relying on the model to “do the right thing.”
What to examine in an LLM security review
A meaningful review looks at the full pathway from prompt to output to side effect. That includes how the system handles user input, what content is retrieved, which tools are available, how secrets are stored, and whether the model can be induced to reveal or act on information outside its intended scope.
Good reviews also ask whether the application is exposing hidden trust relationships. If a chatbot can browse internal data, trigger workflows, or generate privileged output, then the security boundary is not the model alone, it is the combination of prompt handling, data access, tool execution, and downstream approval logic.
For teams that want a practical implementation lens, the Enterprise AI Copilot Security Guide and the Agentic AI Security Guide are strong complements because they translate these ideas into controls for connectors, orchestration, memory, and identity.
Risk and Threat Considerations
LLM applications concentrate risk because they often combine untrusted input, broad retrieval, and delegated actions in one interface. That makes them attractive to attackers seeking data leakage, privilege abuse, workflow abuse, or persistent manipulation of model behaviour.
Failure mechanism: A malicious prompt, poisoned document, exposed secret, or overprivileged tool connection can steer the system into revealing data or taking actions that bypass the operator’s intended control path.
Impact: The result can be confidentiality loss, unauthorised actions, unsafe automation, or broader trust collapse in the AI service, especially when the model is embedded in business workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | LLM apps rely on enforced access decisions for tools and data. |
| V6 — Authentication | LLM platforms depend on strong user and service authentication before tool use. | |
| V14 — Data Protection | LLM risk centers on leakage through prompts, retrieval, memory, and outputs. | |
| Recommendation — Apply V8 to prevent LLM actions from exceeding authorised access boundaries. Apply V6 to verify identities before allowing model-driven actions or data access. Apply V14 to protect sensitive data across prompts, retrieval, storage, and output channels. | ||
| NIST AI RMF | GOVERN — Govern | LLM risk requires organisational governance, accountability, and oversight. |
| MAP — Map | LLM security depends on understanding context, intended use, and risk surfaces. | |
| MANAGE — Manage | The framework directly supports prioritising and treating LLM security risks. | |
| Recommendation — Establish governance for LLM use, ownership, and risk decision-making. Map the model context, data flows, and intended uses before deployment. Manage identified LLM risks with controls, monitoring, and ongoing reassessment. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | LLM applications often expose APIs and service paths whose misuse enables abuse. |
| API5 — Broken Function Level Authorization | Tool-calling LLMs can invoke functions that must be access-controlled. | |
| Recommendation — Harden API authentication so model-connected services cannot be impersonated. Enforce function-level authorisation on every tool and action exposed to the model. | ||
Practitioner Guidance
Why practitioners should care: The most effective LLM security work is usually control design, not model tuning. Teams should treat prompts, retrieval, tools, and runtime credentials as one security surface and decide which parts must be isolated, logged, approved, or denied by default.
Common misunderstanding: Many teams assume that adding a guardrail or policy layer is enough. In practice, the surrounding identity model, data permissions, and tool permissions determine whether a guardrail is meaningful or easily bypassed.
Practitioner takeaway: Use the OWASP list to drive design reviews, test cases, and remediation prioritisation, then map each listed risk to a concrete control owner so the LLM stack is governed as a real production system, not a demo.
Related resources from NHI Mgmt Group
- What breaks when organisations rely on LLMs alone to find OWASP Top 10 vulnerabilities?
- How should security teams implement the OWASP Top 10 for LLMs in an AI governance programme?
- What are the core risks identified by the OWASP Agentic Top 10?
- How should IAM and AppSec teams work together on OWASP Top 10 findings?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org