AI gateways clarify routing, but identity still governs authority

At a glance

What this is: This is an analysis of how AI gateway products split into LLM, MCP, and agent gateway patterns, and the key finding is that identity and access control must sit upstream of routing decisions.

Why it matters: It matters because IAM, PAM, and NHI teams need to decide where authority is established, how identity context survives delegation, and whether gateways merely route or actually enforce access.

👉 Read Aembit’s analysis of AI gateway patterns and identity enforcement

Context

AI gateway is a routing and enforcement layer, not a replacement for identity governance. In agentic systems, the core problem is not only which model or tool receives a request, but which identity and policy context determines whether that request may proceed.

The article frames a practical boundary that IAM teams already know from other domains: intermediary controls can direct traffic, but they do not create authority on their own. That distinction becomes sharper when agents reach models, MCP servers, APIs, SaaS platforms, and internal services through the same architecture.

For identity programmes, the question is no longer whether an AI gateway exists. The question is whether attested workload identity, represented-user context, and destination-specific credentials are preserved across the request path, or collapsed into a shared access path that obscures accountability.

Key questions

Q: How should security teams govern AI gateways in production environments?

A: Security teams should govern AI gateways like shared control planes, not convenience proxies. That means tying every key, token, and routing policy to an owner, enforcing least privilege for configuration changes, and making logging, retention, and fallback behaviour auditable. The gateway should sit inside IAM, secrets, and incident response processes, not beside them.

Q: Why do AI gateways create new identity governance concerns?

A: AI gateways sit between users, service accounts, agents, and models, so they become the place where identity, authorisation, and data controls either stay coherent or fragment. If governance is split across code, plugins, and side integrations, compliance drift and policy gaps appear quickly.

Q: What are the signs that an AI gateway is becoming an access blind spot?

A: Warning signs include shared credentials moving through the gateway, weak visibility into which agent or user is represented, and logs that show routing decisions without a traceable policy lineage. If operators can see traffic but cannot reconstruct who authorised the action and which credential was issued, the gateway is obscuring accountability rather than improving it.

Q: What is the difference between an AI gateway and the identity control plane?

A: An AI gateway sits on the traffic path and decides where a request goes, while the identity control plane decides whether that request should be allowed and which credential it should receive. The control plane establishes authority, and the gateway enforces it on the wire. Conflating the two usually leads to incomplete governance and weak auditability.

Technical breakdown

LLM gateways manage inference traffic, not downstream authority

An LLM gateway sits between an application or agent and one or more model providers. Its functions are operational: routing, retries, fallback, caching, token accounting, rate limits, logging, and sometimes prompt or response inspection. That makes it useful for governing model consumption, but it does not itself decide what an agent may do after inference returns a tool call. The key architectural point is that model access and action authority are separate layers. A request can be routed correctly and still carry the wrong identity context into the next step if downstream tools are not governed independently.

Practical implication: Treat the LLM gateway as an inference control point and enforce separate identity and authorisation controls for tool execution.

MCP gateways mediate tool discovery and access paths

An MCP gateway typically sits between clients and MCP servers to aggregate tools, route requests, authenticate connections, and record activity. In some deployments it also applies traffic policy or mediates protocols, which makes it a useful boundary for tool exposure. However, the MCP specification’s authorization foundation does not remove the enterprise need to verify workload identity, preserve represented-user context, and broker downstream credentials. In other words, protocol-level authorization helps, but it does not define the full governance model for how an agent should be allowed to act across multiple servers or services.

Practical implication: Use MCP gateways to centralise tool access, but keep identity attestation, policy evaluation, and credential issuance in a separate control plane.

Agent gateways blur protocol boundaries, so identity context becomes the control plane

An agent gateway can span model traffic, MCP calls, API requests, and agent-to-agent communication in one data plane. That consolidation reduces sprawl, but it also increases the risk that routing becomes confused with authorization. When a gateway handles multiple protocols, the central design question is not only where a request goes, but whose authority it carries, what policy informed the decision, and whether identity context survives into the destination interaction. This is where blended identity models matter, because the request may represent both a workload identity and a human or organizational actor.

Practical implication: Require explicit identity propagation and token exchange controls anywhere a gateway spans more than one protocol boundary.

Threat narrative

Attacker objective: The objective is to turn a legitimate AI request path into an authorised-looking channel for broader tool access, data access, or credential use.

1. Entry occurs when an agent obtains a valid path into models, tools, or services through a gateway that can route but does not fully govern identity context.
2. Escalation occurs when the request inherits insufficiently constrained authority, allowing the agent to reach tools, APIs, or downstream credentials beyond the intended scope.
3. Impact occurs when the gateway path enables misuse of approved access while obscuring which actor actually exercised the authority.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

Identity context, not gateway branding, is the real security boundary: The article correctly separates traffic handling from authority handling. LLM, MCP, and agent gateways all route requests, but none of those labels answers who is acting, whose authority is represented, or whether the downstream credential is destination-specific. Practitioners should treat gateway terminology as a routing taxonomy, not an access model.

Blended identity is the right lens for agentic access decisions: In agentic systems, the request may carry both workload identity and represented-user identity. That is a different governance problem from classic service-to-service access because the same interaction can be simultaneously machine-initiated and human-authorised. The implication is that identity programmes need explicit representation semantics, not just authentication events.

Token exchange becomes a governance control, not an implementation detail: The article shows why preserving credential isolation matters when agents traverse multiple tools and servers. If a gateway simply forwards a long-lived secret, it creates standing reach beyond the original decision boundary. Identity teams should treat token exchange as part of privilege containment, not as plumbing.

Gateway consolidation can simplify operations while complicating assurance: One product handling model, MCP, and agent-to-agent traffic may reduce tooling sprawl, but it also concentrates risk in a single decision layer. That concentration makes observability and policy clarity more important, not less. Practitioners should demand proof of how identity context is preserved at each boundary.

Runtime access for AI agents still depends on upstream IAM discipline: The article’s deepest point is that gateway enforcement cannot rescue weak identity architecture. If workload attestation, delegated authority, and credential issuance are unclear upstream, the gateway only becomes a better place to hide the problem. The practical conclusion is to govern the control plane first and the traffic plane second.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• Use OWASP Agentic Applications Top 10 to map gateway-driven agent risk to the controls that fail when tool use, memory, and delegation are not tightly bounded.

What this signals

Identity context is becoming the differentiator between useful orchestration and ungoverned access. As AI gateways consolidate routing across models, MCP servers, APIs, and agent-to-agent traffic, the programme risk shifts from connectivity to authority. Security teams should watch for designs that preserve transport logs but lose delegated identity, because those designs are operationally neat and governance-poor.

Blended identity will become a practical requirement, not an architectural nicety. When an agent acts for both itself and a human or organisation, access decisions need to survive across the gateway boundary. That means identity teams will need policy language and audit trails that can represent delegation, not just authentication events, and they should align those controls with the NIST AI Risk Management Framework.

Runtime governance for AI agents should now be measured by credential containment, not by routing efficiency. The more a gateway spans multiple protocols, the more important it becomes to prove that destination-specific credentials are issued and isolated correctly. This is where the OWASP Top 10 for Agentic Applications 2026 becomes operationally relevant, because tool misuse and identity abuse tend to appear together.

For practitioners

• Define the authority boundary before choosing a gateway Document whether the gateway is only routing requests or also enforcing policy, preserving represented-user context, and exchanging credentials. Make that boundary explicit in architecture reviews so teams do not assume gateway branding implies identity governance.
• Separate workload attestation from request routing Require a control plane that can attest the agent or workload identity independently of the gateway path, then pass only approved access context into the request. This avoids collapsing identity proof into transport mediation.
• Enforce destination-specific credential issuance Do not allow shared credentials to move with the agent across tools, APIs, or MCP servers. Issue the narrowest credential needed for the destination and ensure the gateway can broker it without exposing the underlying secret.
• Preserve represented-user context across delegation Where an agent acts on behalf of a person or organisation, keep that context visible to access policy, logging, and investigation workflows. Otherwise the interaction becomes operationally convenient but analytically opaque.
• Test whether the gateway can prove policy lineage Ask whether a request can be traced from workload identity through policy decision to issued credential and final tool action. If any of those links are missing, the gateway is enforcing traffic, not authority.

Key takeaways

• AI gateways help organise traffic, but they do not by themselves establish authority or accountability.
• The central governance problem is preserving identity context across model, tool, and agent boundaries without leaking standing credentials.
• Enterprises should separate routing, policy decisioning, and credential issuance if they want agentic systems to remain auditable.

Key terms

• AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.
• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Blended Identity: Blended identity occurs when an autonomous system acts partly on behalf of a person and partly under its own machine authority. This creates split accountability because one actor may initiate the task while another identity performs the privileged action across different systems.
• Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.

What's in the full article

Aembit's full article covers the operational detail this post intentionally leaves for the source:

• The specific differences between LLM gateways, MCP gateways, and agent gateways in day-to-day deployment.
• How Aembit separates identity attestation, policy evaluation, and credential issuance from traffic enforcement.
• The MCP Identity Gateway request path and where token exchange fits into access enforcement.
• Examples of how blended identity preserves both agent and user context across tool calls.

👉 The full Aembit article covers gateway distinctions, identity context, and MCP enforcement details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 lifecycle governance, it is worth exploring.