Why Traditional Access Controls Fail in LLM Deployments

TL;DR: Prompt-driven apps quickly outgrow static API keys and coarse Identity Access Management (IAM) roles. OWASP’s LLM risk list shows why that model breaks. The answer is continuous, identity-aware policy applied before prompts ever reach the model. Pomerium provides that control so teams can ship GenAI features with confidence.

Traditional Access Controls Weren’t Built for Prompt Workflows

GenAI apps have introduced a new kind of access challenge.

Today’s LLM use cases—whether copilots, retrieval-based chatbots, or autonomous agents—regularly touch sensitive internal data. Yet many teams still lean on patterns built for REST APIs: one bearer token, full access.

That token often unlocks everything. The model endpoint, the vector store, and downstream tools the agent can call.

It only takes one misused prompt to reach into data that shouldn’t be exposed. In a recent example, Supabase’s MCP demo leaked private GitHub repos after a crafted prompt tricked the agent into executing an unexpected database command. The issue wasn’t with the model logic. There was simply no identity-aware policy in place between the prompt and the backend system.

OWASP’s LLM Risk List Puts the Problem in Focus

OWASP recently published its Top 10 Risks for LLM Applications. Two risks are especially relevant to access control:

• LLM01: Prompt Injection – Attackers bypass system instructions, access sensitive data, or gain unintended privileges.

• LLM05: Insecure Output Handling – The model outputs commands that downstream systems execute without context or validation.

At the core, both problems stem from the same issue. Once a prompt passes through a shallow gateway, there’s no way to confirm who made the request or whether that action should be allowed. Prompt filters try to catch malicious content, but they operate without the context that authorization decisions require.

Identity Needs to Travel With the Prompt

LLM traffic is stateful. A single user session can trigger dozens of calls across tools, APIs, and databases. These interactions carry different risk levels and should follow different policies.

Here’s what’s needed to keep access in check:

• Bind user identity and session claims to every call

• Evaluate policy at the edge, before the model or backend sees the request

• Log each decision for audit, monitoring, and incident response

When identity and policy enforcement happen on every request, prompts cannot bypass access controls. Without that layer, access becomes implicit, not intentional.

How Pomerium Secures LLM Routes at the Edge

Pomerium acts as an access proxy in front of your LLM infrastructure. Every call carries signed identity metadata, and policies are evaluated before the prompt or tool receives the request.

What this looks like in practice:

• Signed identity headers
  Include an X-Pomerium-Jwt-Assertion that proves user identity, group membership, and session details on every request.

• Declarative route-level policy
  Write policies in YAML or use Zero UI to allow or deny traffic based on identity, method, time of day, or device posture.

• Custom JWT claims
  Send only the attributes that the model or tool actually needs using Pomerium’s Claim Headers setting.

• Structured, audit-ready logs
  Stream all access decisions to your SIEM for visibility and real-time alerting.

The outcome is Zero Trust for prompts. Access is never assumed. It’s granted only by rule.

Case Study: Blocking RAG Data Leaks in Production

A healthcare company built a chatbot to help staff resolve patient support tickets. It used retrieval-augmented generation (RAG) to query a care-specific vector store.

During internal testing, some users were able to retrieve content outside their access scope by rewording their prompts.

What allowed the leak:

• The vector API was behind a long-lived bearer token

• Identity checks happened only at the frontend

• Prompt filters couldn’t catch rephrased or obfuscated terms

How the team fixed it with Pomerium:

• Routed /rag/query through Pomerium Zero

• Injected signed headers with the user’s group (e.g., role:doctor, role:nurse)

• Wrote a policy blocking PHI-tagged documents unless the user was in the doctor group and had recent MFA

• Logged all decisions for monitoring

No changes were needed to the model, the issue was closed in a single afternoon.

What to Do Next

Prompt filters can help flag questionable output. But they only work after the model has already seen and processed the prompt.

To prevent such exposure in the first place:

• Deploy Pomerium Zero inside your infrastructure

• Connect your identity provider and import group context

• Apply OWASP-aligned policy bundles in front of model endpoints

• Review and refine logs in your SIEM

Security becomes proactive, not reactive.

Related Resources for Deeper Integration

• Secure MCP Deployments – Closing the gaps in the MCP draft spec

• Shadow AI Playbook – How to manage unsanctioned GenAI usage

• Why the Managed Context Protocol (MCP) Spec Still Leaves Gaping Security Holes