Notifications
Clear all
Topic starter
06/09/2026 6:20 pm
TL;DR: AI gateways are converging around three jobs, model routing, MCP tool mediation, and broader agent communication, but the article’s key finding is that routing alone does not answer who is authorised to act, according to Aembit. That boundary is governed upstream by attested workload identity, represented-user context, and policy-driven credential issuance, not by the gateway label itself.
NHIMG editorial — based on content published by Aembit: AI gateway patterns, MCP mediation, and identity enforcement in agentic systems
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Enforce destination-specific credential issuance Do not allow shared credentials to move with the agent across tools, APIs, or MCP servers.
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.
👉 Read Aembit’s analysis of AI gateway patterns and identity enforcement →
AI gateways and identity: what determines who can act?
Explore further
06/09/2026 6:21 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI gateways clarify routing, but identity still governs authority
