TL;DR: OWASP’s updated 2025 Top 10 for LLM applications elevates prompt injection, sensitive information disclosure, supply chain exposure, and excessive agency as the most relevant risks for copilots, chatbots, and agents, according to Pomerium. Identity-aware, policy-backed access is now the control layer that determines whether prompt-driven systems can reach data or tools safely.
At a glance
What this is: This is a Pomerium analysis of the OWASP Top 10 for LLMs that argues the main security gap is access control, especially around prompt injection and sensitive data exposure.
Why it matters: IAM, PAM, and NHI teams need to treat LLM routes, tool calls, and data access as governed identity paths because prompt filtering alone does not stop over-permissioned systems.
Context
The access gap in LLM security is simple to state and hard to close: prompt-driven systems can reach data and tools faster than existing controls were designed to govern. In practice, that means the security problem is not only what the model says, but what the model can touch once a prompt changes its behaviour.
This article frames the OWASP Top 10 for LLMs as a governance problem for copilots, chatbots, and agents. For IAM and NHI teams, the relevant question is where identity-aware policy has to sit so that model output, tool use, and data access remain bounded.
Pomerium’s article focuses on two risks where access control is decisive: prompt injection and sensitive information disclosure. The broader lesson is that LLM security becomes tractable only when access decisions are enforced outside the model itself.
Key questions
Q: How should security teams think about protecting LLM applications beyond simply restricting access?
A: Security teams should treat LLM protection as a control problem, not just an access problem. Even if an application can only reach approved data, the model can still leak secrets, follow malicious prompts, or trigger unsafe downstream actions. Effective programmes combine least privilege, input and output controls, logging, red teaming, and continuous policy review across the full AI application path.
Q: Why do prompt injection attacks create identity risk?
A: Prompt injection becomes an identity problem when the model can use its authorised access to query data, call tools, or trigger actions on behalf of the request. The prompt is only the trigger. The real risk is over-permissioned access that lets untrusted input inherit privileges the caller should not have.
Q: What breaks when LLMs have access to sensitive systems with static secrets?
A: Static secrets let one compromise persist across many requests, so a single prompt or workflow error can keep exposing the same systems until the secret is rotated. That creates an oversized blast radius and weakens incident response, because you cannot easily separate one task from the credential that enabled it.
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 turns the model into an access broker
Prompt injection is not only a content problem. It becomes a control problem when a model can interpret a malicious prompt as permission to reach tools, data sources, or downstream systems. The article’s framing of LLM01 shows why simple prompt filters are insufficient: they try to police language after the request has already been interpreted. In an enterprise setting, the real control point is whether the model is allowed to invoke a route, query a repository, or call an internal service at all. That is an identity and policy question, not a language-safety question.
Practical implication: place route-level authorisation in front of tool and data access so a prompt cannot expand the model’s reach.
Sensitive information disclosure is an access boundary failure
LLM02 matters because many LLM deployments connect to systems that already hold valuable data, such as customer records or code repositories. If the model inherits broad or static credentials, a single query can expose more than intended, even when the model itself is behaving normally. This is why short-lived, identity-bound credentials matter: they tie access to a specific session, route, or user context instead of leaving standing privilege in place. The issue is not only disclosure in the response. It is disclosure enabled by over-broad upstream trust.
Practical implication: replace static API keys with short-lived, scoped credentials and log every privileged route decision.
Excessive agency changes the trust model for AI workflows
Excessive agency means the system is allowed to act beyond the intent of the original requester. In LLM and agentic environments, that can include calling tools, moving data, or triggering downstream actions that were not explicitly authorised for that task. Once agency expands, conventional request/response assumptions break down because the identity path is no longer tied to one user action. This is where NHI governance starts to overlap with emerging agentic controls: the access decision must constrain what the system may do, not just what it may read. The governing model shifts from output review to execution control.
Practical implication: define explicit action scopes for LLM workflows and deny any tool call that falls outside the approved route.
Threat narrative
Attacker objective: The attacker wants to use the LLM as a trusted intermediary to reach data, tools, or actions that should remain out of scope.
- Entry occurs when a malicious prompt or untrusted input reaches an LLM-connected workflow and changes the model’s behaviour.
- Credential or access abuse follows when the model is allowed to query data sources or invoke tools with privileges broader than the task requires.
- Impact occurs when the model discloses sensitive data, triggers an unsafe downstream action, or exposes internal systems through the authorised route.
Breaches seen in the wild
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
- McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity-aware access, not prompt hygiene, is the control layer that matters for LLM security. The article is right to elevate prompt injection and sensitive information disclosure, but the real governance issue is whether the system can reach tools or data in the first place. If access is policy-backed at the edge, a malicious prompt has far less room to turn into an incident. Practitioners should treat route-level authorisation as the boundary that makes LLM deployment governable.
LLM security is becoming an NHI problem because the model often operates through machine credentials. Once an LLM or agent can call internal systems, static secrets and over-broad tokens create the same failure pattern seen in classic NHI sprawl. The difference is that the request is now generated dynamically by model behaviour rather than by code alone. Teams should evaluate LLM routes as non-human access paths with explicit ownership, scope, and revocation.
Prompt injection exposes a mismatch between model interpretation and authorisation design. Access controls were built around stable requests and known callers, not around systems that can reinterpret instruction content at runtime. That means least privilege must be enforced at the point of tool invocation, not assumed from the model prompt or user intent. Security teams should stop treating prompts as trustworthy boundaries.
Identity blast radius is the right named concept for LLM governance. A model with access to multiple systems can amplify a single compromised prompt into data exposure across several routes. The article shows why policy scope, not model quality, determines how far that blast radius extends. Practitioners should map every LLM route to a bounded access domain before expanding deployments.
The OWASP Top 10 for LLMs validates that AI security and IAM now converge at the same control point. Prompt-driven applications are no longer only application-security problems because they increasingly operate as identity-bearing systems. That convergence makes collaboration between IAM, PAM, and AI platform teams unavoidable. The practical conclusion is to govern LLM access as part of the enterprise identity programme, not as an isolated AI project.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: Zero Trust for AI Agents
What this signals
Identity blast radius: LLM programmes fail fastest when one prompt can traverse multiple data and tool routes under a single credential. That is why access boundaries have to be designed around routes, not just around users or models.
The governance shift is from model safety to execution safety. Teams should expect AI security reviews to look more like identity reviews, with route scoping, short-lived credentials, and denial logging becoming baseline controls.
For practitioners
- Define route-level policy for every LLM workflow Map each model route to the exact users, groups, and services that may reach it, then deny all other calls before they hit the target system.
- Replace static credentials with short-lived access Use identity-bound, short-lived credentials for model-connected data sources so a single compromised prompt cannot reuse the same access path repeatedly.
- Separate read access from action rights Allow a model to retrieve only the data needed for the task, and require a distinct approval path for any downstream write or execution step.
- Log denied and approved model routes Record every blocked and permitted access attempt so security teams can spot prompt injection patterns, excess privilege, and unexpected tool use.
Key takeaways
- LLM security becomes an access-control problem as soon as models can reach tools or data on behalf of a request.
- Identity-bound, policy-backed access is the practical control that limits prompt injection and sensitive data exposure.
- Teams should govern LLM routes like other non-human access paths, with scoped credentials and explicit action boundaries.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Prompt injection and unsafe tool calls are central to this article's risk model. |
| ASI03 — Identity & Privilege Abuse | The article centres on access overreach when LLMs inherit too much privilege. | |
| Recommendation — Restrict tool invocation paths so untrusted prompts cannot trigger unauthorised actions. Bind each agent or LLM workflow to narrowly scoped identity and privilege boundaries. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article relies on identity-aware access as the boundary for LLM routes and tools. |
| NHI-07 — Long-Lived Secrets | Static API keys are called out as the credential pattern that expands exposure. | |
| Recommendation — Use strong machine authentication for every LLM-connected service and route. Replace long-lived secrets with short-lived credentials for all AI-connected systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle is central to limiting access in LLM-connected workflows. |
| Recommendation — Enforce credential rotation and revocation for every AI-facing authenticator. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes how malicious prompts lead to access abuse and data leakage. |
| Recommendation — Map prompt-injection scenarios to credential access and exfiltration detections. | ||
Key terms
- Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
- Sensitive Data Disclosure: Sensitive data disclosure occurs when an LLM reveals confidential information through its responses or outputs. The risk includes customer PII, API keys, internal system details, and proprietary logic, especially when prompts or retrieval context contain data the model should not echo back.
- Excessive agency: A condition where an AI system is given more operational authority than its task requires. The risk is not just poor output. It is that mistakes, manipulation, or compromise can produce destructive actions at machine speed across the systems the agent can reach.
- Identity-Aware Access: Identity-aware access is an authorization model that evaluates who or what is making a request, what it is trying to reach, and under what context. It replaces broad, persistent trust with request-level decisions. In agentic environments, it is the control that can contain a deceived agent before it reaches enterprise systems.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org