Notifications
Clear all
Topic starter
10/06/2026 12:33 am
TL;DR: Enterprise AI assistants are becoming front doors to internal APIs, databases and SaaS, and Pomerium says the McKinsey platform hack showed how broad intermediary trust, not prompt injection alone, can let attackers trigger internal actions and data access. The architectural lesson is that AI systems need request-by-request policy enforcement, not blanket trust at login.
NHIMG editorial — based on content published by Pomerium covering the McKinsey AI platform hack and the access control pattern behind it
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- The end-to-end request flow showing how a user session becomes a policy-checked internal action.
- The YAML policy example that separates allowed database queries from denied administrative MCP tool paths.
- The audit log fields that let teams reconstruct AI-driven actions by user, resource, policy, and source IP.
- The architecture diagram for putting an identity-aware proxy between the AI orchestrator and internal services.
👉 Read Pomerium's analysis of the McKinsey AI platform access control failure →
AI platform gateway controls - are your controls keeping up?
Explore further
11/06/2026 2:16 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI platform gateway controls expose the McKinsey hack pattern
12/06/2026 3:50 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI platform gateway controls expose the McKinsey hack pattern
