Why traditional access controls fail in LLM deployments

At a glance

What this is: Pomerium’s article argues that LLM deployments break traditional access control assumptions because prompt workflows can traverse model, data, and tool layers in one session.

Why it matters: IAM and security teams need to treat prompts as live access events, or they will miss the policy, audit, and containment gaps created by GenAI workflows.

Context

Prompt-driven LLM applications do not behave like ordinary REST integrations. A single request can fan out across a model endpoint, a vector store, and downstream tools, which means static credentials and coarse roles no longer describe the real access path.

The governance gap is identity-aware decisioning at the prompt boundary. When policy is only enforced at the frontend or inside the model output, teams lose the ability to tell who requested what, whether the request should be allowed, and how to audit the decision later.

Key questions

Q: How should security teams deploy LLMs without exposing sensitive data or weakening access controls?

A: Security teams should separate development, testing, and production data, restrict access with role-based controls, and encrypt data at rest and in transit. They should also keep embeddings and vectors derived from sensitive data under tight governance, use private network paths where possible, and validate that logging, key management, and authentication are all aligned before the model goes live.

Q: Why does prompt injection create risk even when credentials are valid?

A: Prompt injection works because the agent uses its own authorised access. The attacker does not need to steal a key if they can steer the agent into using that key for an unintended action. Valid credentials confirm identity, but they do not prove the intent behind each runtime decision.

Q: Where do static IAM roles fail in RAG and chatbot workflows?

A: Static IAM roles fail when one session can reach multiple backend layers with different sensitivity levels. A coarse role may permit the chatbot to query a vector store, invoke tools, and touch downstream APIs even when the user should only see a narrow subset of documents or actions. The control needs to follow the request, not the app.

Q: How do organisations know whether LLM access controls are actually working?

A: They should verify that every request is evaluated with identity context, that tool access is logged, and that rephrased prompts cannot reach data outside the caller's scope. If a user can change phrasing and still cross an access boundary, the control is not working as intended.

Technical breakdown

Why bearer tokens fail in prompt workflows

Traditional API access assumes a request maps to one resource and one privilege boundary. LLM applications collapse that assumption because a prompt may trigger retrieval, generation, tool invocation, and database access in one session. If the same bearer token can reach all of those layers, the token becomes a proxy for trust rather than a scoped authorisation artefact. The real problem is not token format alone. It is that the authorisation model was designed for request-response APIs, not for prompt-driven control flow where the next action may be selected dynamically at runtime.

Practical implication: replace broad bearer-token access with route-level policy that evaluates the request before it reaches the model or backend.

Prompt injection and insecure output handling as access-control failures

OWASP’s LLM risks show that access control failures can happen both on input and output. Prompt injection can trick the application into bypassing intended instructions or reaching data outside the user’s scope. Insecure output handling becomes dangerous when downstream systems execute model output as if it were trusted input. In both cases, the gap is the same: the system cannot verify who initiated the action or whether the requested operation matches the caller’s entitlement. That makes prompt filters insufficient on their own because they inspect content, not authorisation context.

Practical implication: bind identity, group, and session context to every prompt-related decision instead of relying on content filtering.

How edge policy changes the access boundary

An access proxy in front of LLM infrastructure changes the enforcement point from the model to the request path. That allows the system to evaluate identity, device posture, method, time, and claim-based policy before the prompt reaches a retriever, tool, or database. Signed identity metadata and structured logs create an auditable control plane for GenAI traffic. This is especially important for RAG systems, where retrieval scope must follow the caller’s entitlements rather than the application’s broad backend credentials. The architectural shift is from implicit trust in the app tier to explicit verification at every call.

Practical implication: enforce policy at the edge and log every decision so retrieval and tool use stay aligned to the caller’s entitlement.

Threat narrative

Attacker objective: The attacker wants to make the LLM workflow act on requests the user was never meant to authorise, especially by exposing restricted data or triggering unsafe downstream actions.

1. Entry occurs when a crafted prompt reaches an LLM-enabled workflow that trusts the request path more than the caller's identity context.
2. Credential or authorisation abuse follows when a single long-lived token unlocks the model endpoint, vector store, and downstream tools without per-request policy.
3. Escalation happens when prompt injection or reworded queries steer the workflow into data or commands outside the user's intended scope.
4. Impact is the exposure of restricted content or unintended backend actions through a prompt path that was never constrained by continuous authorisation.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

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

Prompt workflows have become an authorisation problem, not just an AI problem: the access boundary now sits between the user session and the tool chain, not just between the user and the application. Static API keys and coarse roles cannot express the difference between safe retrieval, unsafe tool execution, and restricted data access. The practical conclusion is that GenAI governance has to be designed as a request-time authorisation problem, not as a model-content problem.

Prompt filters are not an access-control substitute: they can detect suspicious language, but they cannot prove who initiated the request or whether the action matches the caller’s entitlement. That is why prompt injection and insecure output handling are both governance failures, not just application bugs. The decisive control is identity-aware policy at the point of enforcement, because content inspection alone cannot preserve least privilege.

Prompt boundary controls create identity blast radius discipline: once the model, vector store, and tools are reachable from one session, every extra privilege expands the blast radius of a single prompt. That is the same failure pattern security teams already know from overbroad service accounts, only now it appears in conversational form. The programme implication is to treat each route, claim, and tool call as a separately governed entitlement.

Prompt-bound access needs continuous verification, not one-time trust: the article’s core lesson is that access to GenAI systems must be re-evaluated on every request because the risk state can change between prompts. This aligns with Zero Trust thinking, but the important shift is operational: the authorisation decision has to travel with the prompt, or the model becomes a blind relay for backend access. Security teams should govern the conversation as tightly as they govern the credential.

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

Prompt-boundary governance is becoming the new control point for GenAI: teams that keep treating LLMs like ordinary API consumers will miss the fact that the real decision now happens before retrieval or tool execution. The operating model has to shift from static entitlements to per-request authorisation with identity context attached to every call.

Identity blast radius is the right way to think about LLM access: one session can touch the model, the vector store, and the downstream tool chain, so a single permissive path can expose far more than the prompt itself suggests. Security teams should map which backend systems a prompt can reach and collapse any unnecessary shared privilege.

Zero Trust has to extend to the prompt layer: request-time verification, not just network placement, is what prevents conversational workflows from becoming implicit trust channels. For practitioners, the priority is to make every prompt an explicitly authorised event with logging, entitlement checks, and policy enforced at the edge.

For practitioners

• Enforce route-level policy at the prompt boundary Place an identity-aware proxy in front of model endpoints, retrievers, and tools so every request is authorised before it reaches backend systems.
• Bind session claims to each LLM call Carry user identity, group membership, and session context through every model, retrieval, and tool invocation so entitlement checks are request-specific.
• Replace broad bearer-token access Remove single-token access paths that open the model endpoint, vector store, and downstream tools together, and scope each path separately.
• Log prompt decisions for audit and response Stream allow and deny events into your SIEM so reviewers can reconstruct which prompt touched which resource and why it was permitted.

Key takeaways

• LLM deployments expose a structural mismatch between conversational workflows and static IAM, because one prompt can fan out into multiple backend systems with different access needs.
• The main failure mode is not the model alone, but the absence of identity-aware policy at the prompt boundary, where authorization decisions must be made.
• Practitioners should move access enforcement to the edge, attach session context to each call, and log every allow or deny decision for auditability.

Key terms

• Prompt Boundary Control: The practice of defining what an LLM may generate, assume, and omit before it produces output. In QA and software engineering, this reduces brittle or non-integrable code by making role, scope, architecture, and validation requirements explicit.
• Identity-aware policy: An authorization model that uses identity context, such as claims, roles, or scopes, to decide what a caller may access. In this pattern, the policy follows the identity at request time instead of relying only on static infrastructure rules, which improves precision but raises governance requirements.
• 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.
• Retrieval-augmented Generation: Retrieval-augmented generation is a pattern where an AI model pulls external information before generating output. The security challenge is that access rules can weaken when data is chunked, embedded, cached, or reused, so source permissions may not automatically follow the content into the model's context.

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.