AI platform gateway controls expose the McKinsey hack pattern

At a glance

What this is: This is a Pomerium analysis of why enterprise AI platforms become easy to abuse when they sit inside the trust path to internal systems.

Why it matters: It matters because IAM, PAM and NHI teams now have to govern AI platforms as intermediary identities that need per-request authorization, auditability and least privilege.

Context

Enterprise AI platforms are increasingly acting as intermediaries between users and internal systems, which breaks the usual assumption that an authenticated session is enough to trust downstream action. Once an AI assistant can call APIs, databases and SaaS tools on behalf of a user, the access model shifts from human login control to request-level governance.

Pomerium's article uses the McKinsey AI platform hack pattern to show that the core issue is not prompt injection alone. The deeper problem is an access control architecture that lets the platform inherit broad trust, then relay actions into systems that never intended to trust the orchestrator itself.

Key questions

Q: What breaks when an AI platform is trusted like a normal application session?

A: The access model breaks because the platform can become a confused deputy with broader effective authority than the user who prompted it. That allows tool calls, data access and even administrative actions to happen under a trust model built for static applications, not delegated AI orchestration.

Q: Why do AI platform gateways need request-level authorization instead of login-only controls?

A: Because AI systems can make many different downstream requests inside one session, and each request may have a different risk profile. Login-only controls cannot distinguish a safe summary from a dangerous database query or admin action, so authorization has to happen at the point of use.

Q: What are the signs that an AI platform trust model is too broad?

A: Look for internal services that accept requests from the AI layer without rechecking identity, weak visibility into tool calls, and backend permissions that exceed what any single user should have. Those are symptoms that the orchestrator has become a privileged shortcut into internal infrastructure.

Q: How should security teams govern delegated control in autonomous AI systems?

A: They should treat delegated control as a first-class identity problem, not a by-product of application integration. That means binding every action to a named owner, a defined purpose, and a constrained scope, then reviewing whether the agent still operates within those limits as its behaviour changes. Accountability must remain traceable throughout the agent lifecycle.

Technical breakdown

Why intermediary trust creates a confused deputy problem

An AI platform that can broker requests to internal services becomes a confused deputy when it is trusted more broadly than the user who triggered it. The platform may be legitimate, but its delegated position lets an attacker use it as the actor that actually reaches data and tools. That is why the security question is not whether the model can reason, but whether the intermediary can be induced to exercise privileges outside the user's intended scope. In practice, direct service trust in the orchestrator is the architectural flaw.

Practical implication: treat the AI platform as an untrusted intermediary and remove any direct trust path from it to internal services.

Request-by-request authorization for AI platform access

Traditional login-based controls assume one authorization decision can stand for the whole session. AI platforms break that model because each tool call, API request and data lookup may have a different sensitivity and a different business effect. Request-by-request enforcement evaluates the user, the action, the target resource and the context every time the platform tries to do something. That is materially different from allowing the platform to operate with a broad session token or shared backend trust. It is the only way to keep the AI layer from expanding user intent into system capability.

Practical implication: enforce authorization at the request boundary, not just at authentication time or session creation.

Why auditability must follow tool calls, not only user sessions

AI-driven access is hard to govern when security teams can see who logged in but not which tools were called, which data was touched or which downstream service approved the action. AI platforms often distribute activity across orchestrators, APIs and automation layers, so the audit trail has to preserve identity, request context and policy decision together. Without that, investigators can reconstruct a login event but not the actual machine-mediated action chain. This is especially important when the AI layer can trigger administrative or data-moving functions.

Practical implication: log the user, request, policy decision and target service for every AI-mediated action.

Threat narrative

Attacker objective: The attacker wants to use the AI platform as a trusted deputy so they can reach internal systems and actions they should not be able to invoke directly.

1. Entry occurs when a user interacts with the AI platform through a normal authenticated session and asks it to perform an internal task.
2. Escalation happens when the orchestrator is allowed to call internal APIs, databases or SaaS systems with broader privilege than the user intended.
3. Impact follows when the attacker abuses the intermediary trust model to retrieve sensitive data, trigger administrative actions or pivot across internal services.

Breaches seen in the wild

• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
• CrewAI Uncrew GitHub token exposure: A CrewAI provisioning error exposed an admin GitHub token for all its private repositories; Noma reported it and CrewAI fixed it in hours.

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 gatewaying is now the control point for enterprise AI access: when an AI platform can call internal systems, the decisive control is no longer the login session but the policy boundary in front of every request. That changes how teams think about authorization, audit and trust across the AI stack. The platform must be treated as an intermediary identity, not as a privileged extension of the user. Practitioners should design for per-request control rather than platform-level trust.

Confused deputy risk is the right model for this attack pattern: the platform is not the primary target because it is intelligent, but because it is allowed to act with authority on behalf of someone else. That is a governance problem as much as a technical one, because downstream systems often trust the orchestrator implicitly once it has authenticated. The practical implication is that identity assertions must be verified where the action occurs, not assumed upstream. Security teams should map every delegated action path.

Request-by-request authorization becomes the identity control that matters most: AI platforms change the timing of access from human-paced to machine-paced, which means broad sessions hide too much authority for too long. A login event tells you that a person arrived, but it does not tell you whether the platform should be allowed to query a warehouse, update a record or invoke an admin function. The governance shift is from session trust to continuous decisioning. Teams should re-evaluate any control that assumes access can be reviewed after the fact.

Auditability has to cover the action chain, not just the user identity: when a platform can chain tool calls across internal services, the security record must show which request caused which downstream action. That is what makes investigation, recertification and accountability possible in AI-mediated environments. Without that visibility, the platform becomes a blind spot inside the identity plane. Practitioners should demand evidence of every tool call, policy check and downstream recipient.

AI platform gateway controls are an identity architecture, not a bolt-on security feature: the article points to a broader market direction where enterprise AI systems will need policy enforcement points between orchestration and infrastructure. That aligns AI access governance with established zero trust thinking, but the object being governed is now the orchestrator itself. The implication is that identity programmes must absorb AI platforms into access governance, audit and least-privilege design. Teams should stop treating the AI layer as a special case.

What this signals

AI platforms need to be governed as intermediary identities: the important design choice is not whether the model can answer well, but whether the orchestrator can be allowed to inherit broad trust across internal systems. Once that happens, the control plane has to move from authentication to authorization on every request.

The practical boundary for AI access is the request path, not the login screen. Teams that already run zero trust or identity-aware proxy patterns should extend those controls to AI orchestration layers before internal tool access becomes normalised.

For practitioners

• Treat the AI platform as an untrusted intermediary Remove implicit trust from the orchestrator and require all internal requests to pass through a policy enforcement layer before reaching APIs, databases or SaaS systems.
• Enforce per-request authorization Evaluate user identity, resource, method and context on every tool call instead of relying on a one-time login decision or shared backend trust.
• Separate user intent from platform capability Limit what the AI layer can do by action type and target service so that a user's request cannot silently expand into administrative or bulk-data access.
• Log the full action chain Record the user, request context, policy decision, source IP, target service and timestamp for every AI-mediated action so the path is reconstructable later.

Key takeaways

• The article shows that the main failure mode is excessive trust in the AI platform itself, not simply malicious prompting.
• The attack pattern matters because the platform can reach internal APIs, data stores and SaaS systems with more authority than the triggering user.
• Request-by-request policy enforcement and full action logging are the controls that most directly reduce the blast radius.

Key terms

• Confused Deputy Attack: An attack where a legitimate agent is tricked into using its own authorised access to perform an action the attacker could not do directly. The risk is highest when an agent has broad permissions and accepts untrusted inputs, allowing adversary-driven prompts or documents to redirect valid credentials toward harmful actions.
• Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.
• Identity-aware Proxy: An identity-aware proxy combines routing with authentication and authorization logic. It checks tokens or certificates, applies policy at the edge, and forwards verified identity context to the backend so applications do not have to re-implement security decisions inconsistently.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

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.