TL;DR: MCP gateways began as a practical patch for missing authorization, audit and discovery controls, but Newcore argues that OAuth 2.1, enterprise-managed authorization, registries and platform telemetry are now absorbing those functions into the identity provider and agent platforms. The control question is shifting from proxy placement to which layer should own identity, policy and observability.
Editorial analysis by NHI Mgmt Group, based on content published by Newcore: “The MCP Gateway Had a Good Run”.
At a glance
What this is: This analysis says MCP gateways are becoming transitional because native authorization, discovery and telemetry are moving into the protocol, the identity provider and the agent platform.
Why it matters: IAM teams should treat agent governance as a control-placement problem, because duplicating policy across a gateway, IdP and platform creates drift, latency and brittle accountability.
Context
MCP gateways emerged because early Model Context Protocol deployments lacked the identity, authorization and audit controls enterprises expect. In practice, they filled a governance gap rather than defining the long-term control model for AI agents and the tools they use.
The underlying problem is control placement. If the protocol, the identity provider and the agent platform can each own part of the policy chain natively, the gateway stops being the only place where identity governance for AI infrastructure can live.
Key questions
Q: What should teams do first when their MCP gateway is mostly duplicating other controls?
A: Start by cataloguing which gateway functions are already present in the IdP, the agent platform and your observability stack. If the gateway is only re-enforcing controls that already exist natively, it has become a governance duplicate rather than a control plane.
Q: Why do MCP gateways create governance drift when policy exists in more than one place?
A: Because access decisions split across a gateway and an IdP rarely stay identical for long. When scope, approval and revocation rules diverge, teams end up with contradictory enforcement points, which turns policy disagreement into operational risk.
Q: What signs show that an MCP gateway is no longer adding meaningful security value?
A: The clearest signs are extra latency, repeated tool-call logs already visible in SIEM, and gateway rules that mirror platform allowlists or server-side token checks. At that point, the gateway is mostly compensating for itself.
Q: When does a gateway still make sense in MCP deployments?
A: A gateway still makes sense when it provides a unique enforcement point for legacy servers, regulated content inspection or heterogeneous platforms that cannot share a common governance model. Outside those cases, it should be a temporary bridge, not the default architecture.
Technical breakdown
Why MCP gateways existed in the first place
Early MCP deployments assumed a developer running a local server over STDIO, which is workable for experimentation but weak for enterprise governance. Gateways centralized credentials, enforced tool allowlists, translated transports and created one audit point for tool calls. They were compensating for a protocol that had not yet matured into an enterprise authorization model. That made them useful, but also temporary: once the surrounding stack can express identity and policy directly, a proxy stops being the natural control plane.
Practical implication: treat the gateway as a transitional control and map which enterprise controls it is currently substituting for.
How OAuth 2.1 and enterprise-managed authorization change MCP
The protocol now builds on OAuth 2.1, with servers acting as resource servers that validate tokens issued for them specifically. That restores end-to-end identity and reduces the need for a middleman holding shared secrets and re-originating trust. Enterprise-managed authorization pushes policy into the identity provider, where existing access decisions already live. The important shift is architectural: the control point moves from a separate proxy with its own policy language to the identity layer that already governs entitlement.
Practical implication: align MCP authorization with the IdP and remove duplicated policy logic wherever the server can validate scoped access directly.
Why telemetry and platform controls weaken the gateway model
Gateways once had the only useful audit trail for agent tool use, but that advantage erodes when platforms emit standard telemetry into SIEM and tracing stacks. The same is true for connector governance: if the agent runtime can enforce an allowlist, a network proxy adds another policy layer without adding much new protection. The gateway tax then becomes visible in latency, single-point-of-failure risk and token passthrough patterns that break the identity chain the protocol is trying to preserve.
Practical implication: move observability, connector control and approval logic to the layers that already own them, and keep the gateway only where it adds unique enforcement.
NHI Mgmt Group analysis
Gateway centralisation was a patch for an immature identity model, not a destination architecture. MCP gateways solved a very real enterprise problem, but they did so by compensating for missing authorization, discovery and audit primitives. Once those primitives exist in the protocol, the IdP and the agent platform, the gateway stops being the natural control plane and starts being an extra layer of drift. The practitioner conclusion is to retire proxy-centred design thinking and decide which layer truly owns each control.
Control duplication is now the bigger governance risk than control absence. A second policy engine in front of the protocol creates latency, inconsistent enforcement and a wider blast radius when rules disagree. That is not just an architectural nuisance, it is an identity governance failure mode because access decisions become split across systems that were never designed to remain in lockstep. Practitioners should treat policy convergence as a first-class design requirement.
Named concept: identity control repatriation. The most accurate reading of the market is that identity, authorization, connector governance and observability are moving back to the layers that natively own them. This is not a rejection of gateways so much as a redistribution of responsibility after the stack matures. The implication is straightforward: assess each control by the layer that can enforce it closest to the decision, not by habit or convenience.
MCP governance is shifting from server-centric mediation to identity-centric enforcement. That shift matters because the enterprise question is no longer whether an agent can reach a server, but who the agent is, who it is acting for and whether it should be doing this right now. That reframes agent security as lifecycle, authorization and session governance, which is exactly where IAM teams already have operating discipline.
Gateways will persist, but as edge-case infrastructure rather than default architecture. Legacy servers, regulated inspection points and heterogeneous platform estates still create valid use cases. Even there, the gateway should be justified by unique enforcement, not by familiarity. The practitioner conclusion is to reserve gateways for bridging and specialised inspection, while moving the center of gravity to IdP-led control.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: AI Infrastructure Workload Identity Guide
What this signals
Identity control repatriation: As MCP matures, the most useful governance controls move back to the identity provider, the agent platform and the protocol itself. That changes the architecture question from "where do we place a gateway?" to "which layer should own each decision?"
Gateways that keep acting as second policy engines will increasingly produce drift rather than resilience. The operational priority is to remove duplicated enforcement before teams mistake policy overlap for defense in depth.
For practitioners
- Inventory which gateway controls are now native Map credential handling, allowlisting, audit logging and transport translation to the identity provider, agent platform and SIEM before deciding whether the gateway still adds unique value.
- Eliminate token passthrough across trust boundaries Require end-to-end token validation for MCP servers and stop forwarding one credential across multiple trust domains just because a proxy can relay it.
- Collapse duplicate policy engines Compare gateway policies with IdP policy and remove any rule set that can drift, especially where server scopes, approval logic and revocation decisions overlap.
- Keep gateways only where they are uniquely justified Retain a gateway for legacy MCP servers, regulated inspection or heterogeneous platform estates, but document the enforcement function it provides that no native layer can.
Key takeaways
- MCP gateways were a pragmatic answer to missing enterprise controls, but native authorization and telemetry are now reducing their role.
- The main risk is no longer the absence of a gateway, it is duplicated policy across the IdP, the platform and the proxy.
- Teams should reserve gateways for legacy bridging and specialised inspection, while moving identity governance to the layer that can enforce it natively.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on how MCP servers validate identity and issued tokens directly. |
| NHI-05 — Overprivileged NHI | Gateway allowlists and broad proxy trust can mask excess connector and tool access. | |
| NHI-10 — Human Use of NHI | The article stresses who the agent acts for and how human approvals shape agent access. | |
| Recommendation — Align MCP server authentication with issued tokens and remove shared-secret relays from the trust path. Review agent tool scopes and revoke any access that is broader than the task requires. Tie agent decisions to the human or business principal they represent and record that mapping in policy. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The gateway debate turns on token validation and end-to-end authentication boundaries. |
| Recommendation — Validate MCP requests at the server and avoid proxy-based auth re-originating that weakens assurance. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about where authorization should live across the MCP stack. |
| Recommendation — Centralise entitlement decisions in the authoritative policy layer and remove duplicate allow rules. | ||
| NIST Zero Trust (SP 800-207) | Policy Enforcement Point | MCP gateways act as policy enforcement points, but the article argues for moving that function closer to native layers. |
| Recommendation — Place enforcement where identity and request context are validated natively, not in an extra proxy. | ||
Key terms
- 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.
- Enterprise-Managed Authorization: Enterprise-managed authorization is a policy model in which the identity provider decides what an agent may do and encodes that decision into the token or access flow. It helps organisations keep control logic centralized instead of spreading entitlement decisions across many servers.
- Token Passthrough: Token passthrough is the practice of forwarding an authentication token through intermediaries instead of validating it at each trust boundary. In MCP this is prohibited because it prevents the server from proving who is actually authorised to act. The result is weaker accountability and a larger attack surface for stolen or replayed credentials.
- Identity Control Repatriation: Identity control repatriation is the shift of authentication, authorisation, audit and connector governance back into the native layers that own them. In agentic environments, it means the proxy is no longer the default control point, and governance should follow the layer with the strongest contextual authority.
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.
Published by the NHIMG editorial team on October 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org