OWASP LLM top 10 shows where app security breaks down

At a glance

What this is: This is an analysis of the OWASP Top 10 for LLM applications and its key finding that model-driven features create security failures that sit outside classical application security.

Why it matters: It matters because IAM, PAM, and data-access controls must now govern model output, retrieval, and tool use, not just user logins and application endpoints.

By the numbers:

• The OWASP Top 10 for LLM Applications 2025 is the industry's current consensus on what breaks.
• The article cites three new entries and reworkings of several others in the 2025 update.

👉 Read WorkOS's analysis of the OWASP Top 10 for LLM applications

Context

LLM-integrated applications fail in ways that traditional web applications do not. The model can be manipulated through prompts, can surface information it should not reveal, and can pass unsafe output into downstream systems that treat it as trusted input. That is why primary keyword coverage matters here: OWASP LLM applications need security controls that sit outside the model itself.

For identity and access teams, the real shift is that the LLM is not just a feature layer. It becomes a decision-adjacent component that can query data, invoke tools, and trigger actions, so authorization, retrieval controls, and auditability have to be enforced before the model acts. Human IAM, NHI controls, and tool-scoped permissions all converge in the same pipeline.

Key questions

Q: How should security teams govern LLM applications that call tools and data sources?

A: Security teams should govern LLM applications as identity-rich systems, not as isolated models. Access must be enforced before retrieval or tool use, tools must run under scoped credentials, and high-impact actions should require human approval. The model can assist with language and orchestration, but it should not be trusted to make authorization decisions on its own.

Q: Why do LLMs complicate traditional access control models?

A: LLMs complicate access control because they can transform a valid user request into unsafe data exposure or action execution after the initial login check has already passed. Classical IAM assumes the risky decision happens at authorization time. In LLM apps, the risky decision often happens later, inside retrieval, prompt processing, or tool invocation.

Q: What breaks when prompt instructions are used as a security control?

A: Prompt instructions fail when they are treated as the source of truth for permissions, data boundaries, or action approval. They can be leaked, overwritten, or ignored by malicious input. Security rules need to live in deterministic application logic and downstream enforcement points, not only in natural-language prompts.

Q: How do teams reduce excessive agency in AI-powered workflows?

A: Teams reduce excessive agency by limiting functionality, shrinking privileges, and removing approval-free execution for high-impact actions. The safest pattern is least privilege for tools, short-lived credentials tied to the initiating identity, and downstream authorization that does not depend on the model behaving correctly.

Technical breakdown

Prompt injection and indirect instruction smuggling

Prompt injection is the class of attack where attacker-controlled text changes what the model does. Direct injection comes from the user, while indirect injection hides in content the model ingests from emails, documents, web pages, or retrieval sources. The important security point is that the model cannot reliably separate instructions from data when both arrive in the same channel. That is why prompt hardening helps but does not solve the problem. The model remains an untrusted interpreter of text, and downstream systems must assume output can be manipulated.

Practical implication: treat model output as untrusted and enforce approval, schema checks, and authorization outside the prompt.

Sensitive data disclosure through training and runtime context

LLM data leakage happens in two directions. Training leakage occurs when proprietary or personal data enters the model's training or memory surfaces. Runtime leakage happens when a retrieval-augmented or chat application exposes one user's context, records, or documents to another user. The risk is not only memorization. It is also over-broad retrieval, shared service identities, and weak separation between users, tenants, and sessions. Once a model sees data, prompt instructions alone cannot reliably prevent disclosure.

Practical implication: move access checks to the retrieval layer and scope every data source to the requesting identity.

Excessive agency in LLM tool use

Excessive agency is the point where an LLM can take harmful action because it has too much functionality, too much privilege, or too much autonomy. Functionality is the tool set, privilege is the rights attached to those tools, and autonomy is the ability to act without review. A model that can read mail, search data, and send messages becomes dangerous when any one of those dimensions is too broad. The security boundary is therefore not the model's reasoning quality. It is the tool chain, its credentials, and its approval gates.

Practical implication: scope tool permissions tightly, bind them to the authorizing user, and require human approval for high-impact actions.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

LLM security failures are identity failures once the model can retrieve data or call tools. The article shows that the dangerous part of LLM applications is not only generation, but the way output is connected to data sources, email, databases, and external actions. That moves the problem into IAM, NHI, and authorization design. Practitioners should stop treating the model as a self-contained control plane and instead govern every identity it can act through.

Prompt instructions are not a security boundary. The article repeatedly shows that security rules placed inside system prompts can be bypassed, leaked, or overridden. That means any policy expressed only in prompt text is operationally fragile, because the model is still processing attacker-controlled input. Practitioners should treat prompts as interface guidance, not as the place where access control lives.

Excessive agency is the named concept that best captures LLM risk in identity terms. It describes the combination of too much functionality, too much privilege, and too much autonomy in the tool chain. The article makes clear that removing any one of those dimensions can block an attack path. The implication is that governance must focus on what the model is allowed to do, not only on what it is allowed to say.

Permission-aware retrieval is now a core identity control, not a nice-to-have feature. The article's discussion of RAG and vector weaknesses shows that access has to be enforced before the model sees content, especially in multi-tenant systems. If retrieval happens first and filtering happens later, the model has already processed data it should never have touched. Practitioners should align retrieval policy with identity, tenancy, and document scope.

LLM applications expose a control gap between user authentication and downstream authorization. Users may be strongly authenticated while the model still operates through shared service identities or over-privileged tools. That gap is where many leakage and agency failures emerge. The practical conclusion is that enterprise auth must extend into the model path, not stop at login.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
• That same attack pattern is why practitioners should review AI LLM hijack breach research alongside prompt injection and tool-use governance.

What this signals

Excessive agency should become a review lens in any programme that is adding model-connected automation. If the application can read data, call tools, and trigger actions, then identity architecture has to move from user-centric authorization to task-scoped, session-scoped, and approval-scoped control. The security programme that ignores that shift will end up measuring model behaviour after damage has already happened.

With 6 distinct secrets manager instances on average, fragmentation remains a structural problem for teams trying to govern the credentials behind LLM features, according to the State of Secrets in AppSec. That fragmentation matters more when model workflows depend on short-lived tokens, retrieval permissions, and API keys that are easy to over-expose.

Practitioners should also align model governance with OWASP Agentic AI Top 10 thinking, because the boundary between LLM features and agentic behaviour is already blurring in production. The programme question is no longer whether the model is intelligent enough, but whether its identity path is constrained enough to survive misuse.

For practitioners

• Move authorization out of prompts Implement access checks in application code before retrieval or tool invocation, and keep role logic out of system prompt text so a prompt leak does not expose your policy model.
• Scope model tools to the authorizing user Use per-request or per-session credentials for tools, with the narrowest permissions needed for the task and no shared high-privilege service account as the default execution path.
• Enforce permission-aware retrieval Apply tenant, document, and session-level filtering at the vector store or data layer before content reaches the model, especially in multi-tenant RAG systems.
• Validate every model output before execution Require schema checks, output encoding, and human approval for irreversible actions before the model can write to email, database, shell, or workflow systems.

Key takeaways

• LLM features widen the attack surface because model behavior can change what data is exposed and what actions are taken.
• The evidence in the article shows repeated failures across prompt injection, data leakage, supply chain tampering, and excessive agency.
• Enterprises need to move security controls out of prompts and into identity, retrieval, output validation, and approval boundaries.

Key terms

• Prompt Injection: A prompt injection is malicious text that changes how an LLM behaves. It matters because the model cannot always distinguish instructions from data, especially when content comes from users, documents, or external retrieval sources. The security impact is unauthorized disclosure, unsafe output, or tool misuse.
• Excessive Agency: Excessive agency is the condition where an LLM can do more than the task requires because it has too many tools, too much privilege, or too much autonomy. In practice, the risk is not model intelligence but unsafe execution paths that bypass normal authorization boundaries and human review.
• Permission-Aware Retrieval: Permission-aware retrieval is the practice of enforcing access control before data reaches the model. It ensures the model only sees documents, records, or context that the requesting identity is allowed to access. In multi-tenant or sensitive environments, this control is more important than post-processing filters.
• System Prompt Leakage: System prompt leakage is the exposure of hidden prompt content to users or attackers. The real security problem is usually not the prompt itself, but the secrets, policy logic, and internal architecture details placed inside it. If those details are sensitive, they should live in code or secrets management instead.

Deepen your knowledge

LLM application risk, prompt injection, and excessive agency are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to govern model-connected workflows in an enterprise environment, it is a practical place to start.

This post draws on content published by WorkOS: The OWASP Top 10 for LLM applications and what developers need to know. Read the original.