A community-maintained reference list of the most common security weaknesses seen in LLM applications. It helps teams identify recurring risk patterns such as prompt abuse, data exposure, and unsafe system behavior. The list is meant to guide testing, prioritization, and defensive design for AI-enabled services.
Expanded Definition
OWASP Top 10 For large language model Applications is a practitioner reference for the most common weakness classes seen in LLM-enabled systems. It is used to organise testing and defensive thinking around failure modes such as prompt injection, sensitive data exposure, insecure tool use, excessive autonomy, and weak output handling.
The list is broader than a single product or model, and it is not a compliance standard. Its value is in giving teams a shared vocabulary for reviewing an LLM application’s behaviour across the model, orchestration layer, retrieval layer, and surrounding business logic. That makes it especially useful where the model itself is only one part of the exposure.
OWASP’s own material is the primary authority for the list, and readers who want the source taxonomy can use the OWASP Non-Human Identity Top 10 only when they are explicitly examining machine-identity risk rather than the LLM weakness list itself. A common boundary mistake is to treat every model failure as a model-training problem; in practice, many of the most important weaknesses arise in prompts, connectors, retrieval, permissions, and downstream automation.
Examples and Use Cases
The term appears wherever teams need a structured way to review LLM application risk before release or during assurance work. It helps security, engineering, and product teams speak the same language about what should be tested, monitored, and constrained.
- Assessing a customer support chatbot for prompt injection, unsafe content disclosure, and overbroad access to internal knowledge sources.
- Reviewing a RAG workflow to confirm that retrieved documents cannot be turned into a data exfiltration path or an instruction channel.
- Testing an internal coding assistant to ensure it does not expose secrets, generate unsafe commands, or encourage unreviewed execution.
- Evaluating an AI agent that can call tools so the team understands where autonomy begins and where human approval still matters.
- Prioritising remediation across many AI features by grouping findings into repeatable weakness classes instead of isolated bug reports.
Where the application includes tool execution or delegated actions, the practical tradeoff is usually between capability and containment. More integration can improve usefulness, but it also expands the paths by which malicious input or bad outputs can affect real systems. For agentic workflows, readers should also compare the adjacent OWASP Agentic AI Top 10 because autonomous execution changes the risk profile in ways a model-only review can miss.
Security Implications
The security significance of this reference is that it turns scattered LLM failure modes into a manageable review structure. Without it, teams often test only the model prompt and miss the more dangerous parts of the stack: retrieval filters, connector permissions, tool invocation, logging, and post-processing.
When the list is misunderstood, organisations can overestimate model safety while leaving the application layer exposed. A well-behaved model can still leak confidential data if the surrounding system retrieves the wrong content, follows hostile instructions, or passes untrusted output into an action. The result is not just a bad answer, but possible disclosure, fraudulent workflow execution, poisoned records, or operational disruption.
A common practitioner observation is that LLM issues are often control failures, not purely model failures. The same weakness class can appear across chat interfaces, workflow assistants, and embedded copilots, which means one missed pattern can scale quickly. This is why the reference is useful for repeatable testing and for deciding where human review, output filtering, and permission boundaries are needed most.
Domain and Governance Relevance
In governance terms, the list matters because it helps define ownership for AI risk across engineering, security, and product teams. It is most useful when an organisation needs a repeatable way to decide which LLM behaviours are acceptable, which use cases need extra controls, and which exposures must be blocked before launch.
Its strongest relevance is in AI security, but it can also touch broader cybersecurity governance when LLMs are embedded into workflows that handle data, credentials, or operational actions. The framework does not itself prescribe enterprise policy; rather, it gives teams a shared map of failure patterns that can be translated into testing requirements, review gates, and monitoring expectations.
For NHIMG readers, the important distinction is that NHI concepts become material only when the LLM system is acting on behalf of a service, workload, or agent with its own permissions. At that point, the question is no longer just model safety, but whether machine-held access is being exercised safely and within bounds. That is where the reference starts to intersect with identity governance in a meaningful way.
Risk and Threat Considerations
The material risk is that an LLM application can be manipulated into revealing sensitive information, ignoring intended instructions, or taking unsafe actions through connected tools. Threat actors do not need to break the model itself if they can influence prompts, retrieved content, or the surrounding workflow.
Failure mechanism: Recognised mechanisms include prompt injection, indirect prompt injection through retrieved content, insecure tool execution, and over-permissive integration design. These weaknesses allow untrusted input to override intended behaviour or turn a helpful assistant into a path for disclosure or action abuse.
Impact: The result can be data leakage, unauthorised system actions, poisoned outputs, reputational damage, and loss of trust in the application. In more integrated environments, compromise of the assistant’s decision path can propagate into downstream business systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST AI 600-1, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN — Govern | Covers governance of AI risk management for LLM applications. |
| Recommendation — Apply GOVERN to assign ownership for LLM risk review and lifecycle oversight. | ||
| NIST AI 600-1 | MAP — Map | Supports scoping LLM use cases, context, and intended behaviour. |
| Recommendation — Use MAP to document LLM context, dependencies, and intended use before deployment. | ||
| MITRE ATLAS | AML.T0001 — Prompt Injection | Directly aligns with adversarial prompt manipulation against LLM systems. |
| Recommendation — Map prompt-injection findings to AML.T0001 and test instruction boundaries. | ||
| CIS Controls v8 | 6.3 — Data Protection | Relevant where LLMs may expose or mishandle sensitive information. |
| Recommendation — Apply 6.3 to limit sensitive data exposure in prompts, retrieval, and outputs. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Relevant when LLM tools or connectors operate with delegated permissions. |
| Recommendation — Use PR.AC-4 to constrain tool and connector permissions behind the LLM. | ||
Practitioner Guidance
Why practitioners should care: This reference is most useful when it is treated as a testing and prioritisation lens, not as a checklist of abstract “AI risks.” It helps teams decide where a weakness is application-level, where it is workflow-level, and where human approval or stricter containment is needed.
Common misunderstanding: Teams often assume that a secure model implies a secure LLM application. In practice, the surrounding orchestration, retrieval, tools, and output handling usually determine whether the weakness becomes exploitable.
Practitioner takeaway: Use the list to drive threat modeling and assurance reviews for the full LLM application path, then separate model concerns from integration and access-control concerns so the right owner can remediate each issue.
