OWASP top 10 for LLMs exposes the access gap in AI security

At a glance

What this is: Pomerium maps the 2025 OWASP Top 10 for LLM applications to the access-control failures that let prompt-driven systems reach data and tools they should not.

Why it matters: IAM, NHI, and AI governance teams need to treat LLM risk as an identity and authorisation problem, not only a model-safety problem.

By the numbers:

• In 2025, the OWASP Top 10 for LLM applications was updated to reflect the latest threat patterns facing copilots, chatbots, and agents.
• The OWASP Top 10 for LLMs names 10 distinct risk categories, including prompt injection, sensitive information disclosure, and excessive agency.
• OWASP published the first LLM-specific risk list in 2023, giving teams a baseline for prompt-driven application threats.

👉 Read Pomerium's analysis of the OWASP Top 10 for LLM security risks

Context

LLM security fails when teams treat the model as the only thing to defend. Prompt-driven systems reach databases, APIs, code repositories, and internal tools through identity and access paths, so the real control problem is who and what the model can reach at runtime.

The 2025 OWASP Top 10 for LLMs gives practitioners a common language for that risk, but the important governance shift is broader than model abuse alone. For IAM, NHI, and AI teams, the question is how to constrain tool use, data exposure, and downstream action before the model can turn an unsafe prompt into an unsafe request.

Key questions

Q: How should security teams control prompt injection in LLM applications?

A: Security teams should control prompt injection by restricting what the model can reach, not only what it can say. Put policy enforcement between the model and the target systems, use identity-aware authorization for every tool call, and deny any route that is not explicitly required for the workflow. The safest design assumes hostile prompts and limits the blast radius of the connected services.

Q: Why does sensitive information disclosure become an identity problem in LLM systems?

A: Sensitive information disclosure becomes an identity problem because the model can only expose what its connected accounts and routes allow it to access. If the workflow has broad permissions, the model can return or leak far more than intended. Narrow permissions, short-lived credentials, and per-route controls reduce the chance that a single request becomes a large data event.

Q: What do security teams get wrong about LLM access control?

A: Many teams focus on the model output and miss the privilege scope behind the workflow. Access control fails when the system can still query sensitive APIs, databases, or repositories even if the prompt is suspicious. The right question is not whether the model looks safe, but whether the connected access paths are least privileged and continuously checked.

Q: How do Zero Trust controls help with agentic and LLM risk?

A: Zero Trust helps by requiring continuous verification at the point where the model reaches a resource. Instead of trusting the application because the prompt was accepted, it evaluates each request against identity, policy, and destination. That approach is especially useful when output can drive tool use, because it prevents implicit trust from turning into unauthorized action.

Technical breakdown

Prompt injection and downstream tool access

Prompt injection becomes materially worse when the model is allowed to call tools or query internal systems. The malicious input does not need to break the model itself if it can influence the model’s next action, especially when the application wires model output directly into API calls, search, or database lookups. In practice, the security boundary must sit between the model and the protected resource, not just around the chat interface. Identity-aware authorization at the edge narrows what the model can reach, even when the prompt is hostile.

Practical implication: Enforce route-level policy between LLM outputs and backend services so a manipulated prompt cannot trigger unrestricted access.

Sensitive information disclosure in connected LLMs

Sensitive information disclosure usually follows over-broad access rather than sophisticated model theft. If an LLM is connected to customer records, source code, support tickets, or internal documents, the model can expose more than intended in a single response or retrieval chain. The issue is not simply what the model memorises. It is what the surrounding application permits it to query and return. Short-lived, identity-bound credentials and per-route authorization reduce the blast radius when the model is asked to retrieve restricted data.

Practical implication: Replace static credentials with short-lived access and narrow each LLM route to the smallest approved data set.

Excessive agency and unsafe output handling

Excessive agency appears when model output is allowed to drive actions beyond the model’s intended scope. That can mean opening tickets, posting messages, updating records, or invoking tools without a human or policy gate. Improper output handling is the adjacent failure mode: the application treats generated text as if it were trusted input. Together, these risks turn an LLM from a conversational interface into an uncontrolled actor in a business process. Zero Trust access control limits what the system can do when output is wrong, misleading, or adversarial.

Practical implication: Require policy checks before model output can trigger any external action or privileged workflow.

Threat narrative

Attacker objective: The attacker aims to turn a conversational interface into an access path for data disclosure or unauthorized action.

1. Entry occurs when a malicious prompt reaches a connected LLM application and influences the model’s next step through prompt injection or poisoned input.
2. Escalation follows when the application trusts model output enough to query protected tools, retrieve sensitive records, or invoke downstream services with excessive agency.
3. Impact is achieved when the system leaks data, performs unsafe actions, or exposes internal systems that were never meant to be reachable from the prompt interface.

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

Identity-aware access is the control plane for LLM security, not a secondary safeguard. The article correctly frames prompt injection and sensitive information disclosure as the top two operational risks, but the governance lesson is broader: an LLM is only as safe as the routes it can reach. Once a model can query tools or internal systems, identity policy becomes the boundary that matters most. Practitioners should treat every LLM connection as an access decision, not a prompt-handling problem.

Prompt injection is an authorisation failure when the model can act on behalf of the user. OWASP’s LLM01 risk becomes an IAM issue the moment model output can trigger backend requests. The model may be the thing that receives the prompt, but the exposed asset is the connected service, database, or API. That means access design must assume hostile input and constrain the model’s reach before tool invocation. Practitioners should review every LLM workflow where output can influence privileged actions.

Identity blast radius: a prompt-driven system inherits the privilege scope of every connected account, token, and route it can touch. That blast radius is often wider than teams realize because static credentials, broad service permissions, and shared integrations collapse separation of duties inside the application. The concept is useful because it explains why model safety and identity safety cannot be separated at deployment time. Practitioners should map the blast radius of each LLM integration before they approve production use.

Zero Trust is relevant here because the model should never be trusted implicitly after first contact. The article’s access-control emphasis aligns with a continuous verification model, where every route, tool, and data source is explicitly authorized. That is the right direction for both human-triggered copilots and machine-triggered agents, because the security issue is not language generation itself. Practitioners should design for continuous authorization at the point of data and action.

OWASP’s updated LLM categories are useful because they help security teams stop over-indexing on prompt filters. Prompt filters can reduce noise, but they do not solve the underlying identity and privilege problem when the application can still reach sensitive systems. The field needs to move from content moderation to controlled execution. Practitioners should reframe LLM security reviews around reachable assets, not only model outputs.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For a broader NHI control baseline, see the Ultimate Guide to NHIs for lifecycle, rotation, and offboarding guidance.

What this signals

Identity blast radius: LLM programmes need to be assessed by the reach of the credentials behind them, not by the quality of the prompts they accept. When a workflow can read from internal systems and act on their output, the smallest access mistake becomes the largest security mistake. Teams that already expose secrets outside secrets managers should treat LLM integrations as an accelerant for existing weakness.

The programme signal is straightforward: move LLM governance into the same control stack used for privileged access and workload identity. That means route-level authorization, short-lived credentials, and explicit separation between read and write paths. The article points in the right direction, but the operational lesson is that model safety depends on the maturity of the surrounding identity controls.

Pomerium’s focus on edge authorization reflects a broader market shift toward execution control around AI systems, and that shift is likely to intensify as copilots and agents touch more internal data. The teams that will scale safely are the ones that can prove which identities, tools, and data sources are reachable from each workflow.

For practitioners

• Constrain every LLM route with explicit authorization Map each prompt-driven workflow to the exact data sources, APIs, and tools it may reach, then block all other paths at the access layer. Use per-route policy so a successful prompt injection cannot expand the model’s reach beyond approved systems.
• Replace static secrets with short-lived, identity-bound access Use ephemeral credentials for model-connected services and avoid long-lived API keys in copilots, agents, and retrieval pipelines. This reduces the window in which an exposed token can be reused against connected systems.
• Separate read, write, and action privileges in AI workflows Assign different permissions to retrieval, summarization, and execution steps so the model cannot move from reading content to changing state without a distinct control decision. This is especially important where output can trigger business actions.
• Log denied model requests as a security signal Treat blocked calls, unusual tool attempts, and repeated access denials as evidence of prompt manipulation or excessive agency. Preserve decision logs so incident responders can reconstruct how the workflow behaved under hostile input.

Key takeaways

• LLM security breaks at the access layer when prompt-driven systems can still reach sensitive tools and data.
• The risk is measurable because the OWASP Top 10 for LLMs now names 10 distinct failure categories, including prompt injection and excessive agency.
• Practitioners should govern LLM workflows with identity-aware, route-level controls so hostile prompts cannot become privileged actions.

Key terms

• Prompt Injection: Prompt injection is malicious input designed to change how an LLM behaves or what it reaches. In practice, the risk is not limited to bad text generation. It becomes a control failure when the model can use that input to query tools, access data, or trigger actions beyond intended scope.
• Identity-Aware Access: Identity-aware access is authorization that evaluates who or what is making a request before allowing a resource to be reached. For AI workflows, it applies to model-connected routes, tools, and data sources, so the system can block unsafe calls even when the prompt itself appears valid.
• Excessive Agency: Excessive agency occurs when an AI system is allowed to take actions that exceed the scope it was intended to have. The issue is governance, not intelligence. If output can drive privileged tools, state changes, or external workflows without tight authorization, the system behaves like an over-privileged actor.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, and actions exposed by a single identity or credential. In AI environments, it describes how far a model can go if its associated account, token, or route is over-permissioned. Smaller blast radius means less impact when a prompt or secret is compromised.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pomerium: The OWASP Top 10 for LLMs and How to Defend Against Them. Read the original.