AI platform gateway controls expose the McKinsey hack pattern

At a glance

What this is: This is an analysis of why enterprise AI platform architectures can be easy to exploit when the AI layer is treated as a trusted intermediary.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern tool-calling systems that can move across internal services, not just authenticate a user once.

👉 Read Pomerium's analysis of the McKinsey AI platform access control failure

Context

Enterprise AI assistants are increasingly placed between users and internal systems, which means the AI layer can become a high-trust intermediary rather than a simple user interface. In that model, a single compromise or manipulation can turn ordinary prompts into internal API calls, data retrieval, or administrative actions.

The core governance problem is not just model behaviour. It is the access control architecture around the model, including how identity is asserted, how authorization is evaluated, and whether downstream services trust the AI platform too broadly. That makes this an identity architecture problem across NHI-style workload access and broader enterprise IAM controls.

Key questions

Q: How should security teams govern AI assistants that can call internal tools?

A: They should put a policy enforcement layer between the AI system and every internal service, then require identity verification and authorization on each request. The goal is to prevent the AI platform from becoming a trusted deputy with broad inherited access. That model also improves auditability because every tool call is tied to a user context and a policy decision.

Q: Why do AI platforms create confused deputy risk in enterprise environments?

A: Because the AI layer often sits in the middle of users and internal systems while holding more access than any single user should have. If downstream services trust the platform itself, an attacker can persuade it to use legitimate privileges on the attacker’s behalf. The risk grows when tool calls, data access, and automation are all chained through one orchestrator.

Q: What breaks when AI authorization happens only at login?

A: A login-only model assumes the session stays safe after authentication, but AI systems may make many later decisions and tool calls across multiple services. That leaves a large gap between the original sign-in and the actual action. Continuous, request-level authorization closes that gap and makes every downstream action subject to fresh policy evaluation.

Q: What is the difference between an AI gateway and a normal proxy?

A: A normal proxy can forward traffic, but an AI gateway enforces identity, policy, and auditing specifically around AI-driven requests. That matters because the control point has to understand user context, tool categories, and action risk before forwarding the request. In practice, the gateway becomes the governance layer for delegated AI access.

Technical breakdown

Why confused deputy attacks are a control problem, not just a model problem

A confused deputy attack happens when a powerful intermediary is induced to act on behalf of an attacker. In AI platforms, the orchestrator may have access to internal APIs, knowledge bases, databases, and automation tools, which means it can be tricked into using legitimate privileges in unintended ways. The model does not need to be fully compromised for this pattern to work. The security failure is the trust boundary around the intermediary, especially when downstream systems accept requests from the AI layer without re-checking user context or authorization scope.

Practical implication: place a policy enforcement layer between the AI platform and internal services so every tool call is re-authorized.

Identity-aware proxies for AI platforms and MCP tool access

An identity-aware proxy acts as a centralized control point that verifies identity, evaluates policy, and logs activity before forwarding requests. That is materially different from relying on the AI platform or the target service to enforce access separately. For agentic workflows and MCP-linked tools, this matters because tool calls are often chained across multiple services. Without a common enforcement layer, you get fragmented authorization, inconsistent logs, and broad implicit trust between services that were never designed to trust an LLM orchestrator.

Practical implication: require signed identity assertions and central policy checks before any AI-driven request reaches internal resources.

Why request-by-request authorization beats login-time trust

Traditional session models often trust a user after initial authentication, but AI systems may execute many actions after that point across different services. Pomerium’s argument is that authorization must happen on every request, not just at login, because the risky event is not entry alone but each downstream action. This is especially relevant when the AI platform can call tools, chain API requests, or trigger automation without a human reviewing each step. Continuous verification becomes the control pattern that matches the architecture.

Practical implication: design authorization so every AI action is evaluated in context, rather than inheriting a broad session-wide trust state.

Threat narrative

Attacker objective: The attacker wants the AI platform to execute internal actions and expose data on the attacker’s behalf while bypassing normal user-level controls.

1. Entry begins when a user interacts with an enterprise AI assistant that is connected to internal systems through an LLM orchestration layer. The AI platform sits in a privileged position between the user and internal infrastructure.
2. Credential or access abuse occurs when the AI system’s broad trust is leveraged to call internal APIs, retrieve sensitive data, or perform administrative actions that the user should not be able to trigger directly.
3. Impact follows when the intermediary acts as a confused deputy, allowing unauthorized internal actions to be executed and traced only poorly if centralized policy and audit logging are missing.

Breaches seen in the wild

• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.
• OmniGPT breach — OmniGPT breach exposed API keys, email addresses and chat logs.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI platform governance now inherits the confused deputy problem. When an LLM orchestrator is treated as a trusted intermediary, it can be induced to use legitimate access in illegitimate ways. That is not a model-only issue, it is an access control design failure that spans IAM, workload identity, and downstream service trust. Practitioners should treat AI platforms as untrusted clients until every internal action is re-authorized.

Least privilege for AI systems is not a provisioning problem alone. The platform may be assigned fewer roles, yet still become dangerous if downstream services accept its requests as authoritative. The real issue is whether the AI layer can call tools, chain requests, and pivot across services without per-request policy gating. That is why least privilege has to be enforced at the request boundary, not just at account creation.

Request-by-request enforcement is the right control pattern for AI intermediaries. The architecture described here shows why login-time trust and fragmented service-level authorization are not enough. Centralized verification, signed identity assertions, and full auditability give security teams a traceable decision point for every AI-driven action. Practitioners should align gateway design with NIST Cybersecurity Framework 2.0 and zero trust principles.

Identity-aware gateways are becoming the governance layer for agentic access. As enterprise AI systems expand into internal APIs, SaaS, and automation tools, the control surface looks less like a chatbot and more like a delegated access broker. That changes the identity question from who logged in to which service action was authorized, under what context, and with what downstream blast radius. Practitioners should reframe AI access as a governable identity pathway, not an application feature.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• The same research found that DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
• Ultimate Guide to NHIs sets out the lifecycle and governance baseline that AI gateway designs need once tool-calling systems are treated as non-human identities.

What this signals

Identity-aware gateways will become a default control for AI-driven access paths. As enterprises connect assistants to APIs, data stores, and automation tools, the practical question shifts from whether the model is capable to whether the request path is governable. Teams that already treat service accounts and workload access as non-human identities are better placed to extend the same discipline to AI intermediaries.

Access review alone will not solve delegated AI risk. The control gap is not just permission size, it is whether every action can be tied to a verified identity, a policy decision, and a traceable audit record. With the Ultimate Guide to NHIs as a baseline, practitioners should expect AI gateway design to become part of broader identity architecture rather than a niche integration choice.

For practitioners

• Insert a central policy enforcement point Route every AI-driven request through a gateway that authenticates the user, verifies the context, and evaluates authorization before any internal API or data access occurs.
• Eliminate broad trust in downstream services Stop allowing internal APIs to trust the AI platform by default. Require verified identity assertions and per-request policy decisions instead of accepting orchestration-layer requests as inherently safe.
• Log tool calls with user context Capture the user identity, resource accessed, policy outcome, source IP, and timestamp for every AI action so security teams can reconstruct tool use and investigate misuse.
• Limit tool access by action type Separate low-risk read actions from write or administrative actions, and deny dangerous MCP tool categories such as update, delete, and admin paths unless explicitly authorized.
• Treat AI orchestrators as untrusted clients Assume the orchestrator can be manipulated and design the control plane so it never becomes the sole authority for reaching internal systems.

Key takeaways

• Enterprise AI assistants create a governance problem when they sit between users and internal systems with broad intermediary trust.
• The attack surface is the request path, not only the model, which is why request-level authorization matters more than login-time trust.
• Identity-aware gateways turn AI access into a governable flow by enforcing identity, policy, and audit before internal actions are executed.

Key terms

• Confused Deputy: A confused deputy is a trusted system that can be tricked into using its legitimate privileges on behalf of an attacker. In AI platforms, this appears when an orchestrator has broad internal access and downstream services trust its requests without re-checking user context or policy.
• Identity-aware gateway: An identity-aware gateway is a control layer that verifies identity, applies authorization policy, and records audit data before forwarding a request. For AI systems, it becomes the enforcement point between the orchestrator and internal services, preventing the model from becoming the authority for access decisions.
• Request-level authorization: Request-level authorization means each action is evaluated at the moment it is made, rather than inheriting a broad pass from the login event. For AI assistants, this is critical because tool calls, API requests, and automation can happen long after authentication and across multiple services.
• AI intermediary: An AI intermediary is a system that sits between a user and internal resources and can select tools, call APIs, and trigger actions on the user’s behalf. That placement makes it an identity control problem, because the intermediary can expand the user’s effective reach unless tightly governed.

Deepen your knowledge

AI gateway design and delegated access control are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity governance into AI assistants and tool-calling systems, the course is a practical starting point.

This post draws on content published by Pomerium covering the McKinsey AI platform hack and the access control pattern behind it. Read the original.