Topic starter
05/10/2026 6:49 pm
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”.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
MCP gateways: what changes when authorization moves into the stack?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
05/10/2026 6:49 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP gateways are losing ground as native authorization matures