For about eighteen months, the MCP gateway was the most obvious piece of enterprise AI infrastructure you could get. Agents needed tools, tools needed guardrails, and the Model Context Protocol, for all its elegance, shipped without most of the guardrails a security team would ask for. So we put a box in the middle. Every agent talked to the gateway, the gateway talked to every server, and the CISO slept a little better.
That box is starting to look like a transitional technology. Not because the problems it solved went away, but because the ecosystem is absorbing them into layers that were always better placed to own them.
Why gateways existed in the first place
It's worth being honest about why gateways made sense. Early MCP was built for a developer running a local server over STDIO (standard input and output) on their own laptop. That model had no real answer for the questions enterprises ask on day one: who is this agent acting for, what is it allowed to touch, where is the audit trail, and how do I turn it off?
Gateways filled every one of those gaps at once. They centralized credentials so API keys weren't scattered across config files. They gave admins an allowlist of approved servers. They logged every tool call. They translated between transports. For a protocol moving faster than its own governance story, a gateway was the pragmatic fix.
The operative word is "fix." Gateways were a patch over missing capabilities in the protocol and its surrounding ecosystem. Patches get retired when the underlying system catches up.
The protocol grew up
The biggest change is that authorization is no longer an afterthought. The MCP spec now builds on OAuth 2.1, with servers acting as proper resource servers that validate tokens issued for them specifically. That sounds like a technical footnote, but it removes the gateway's original reason for existing. If a server can verify who is calling and what they're scoped to do, you no longer need a middleman holding a vault of shared secrets on everyone's behalf.
Enterprise-managed authorization (EMA) pushes this further. Instead of each user clicking through consent screens for every tool, the organization's identity provider can grant agents access to downstream apps based on existing policy. The control point moves to the IdP, which is where your access policy already lives, rather than to a separate proxy with its own policy language and its own drift.
Discovery is maturing too. Registries give clients a sanctioned way to find and verify servers, which chips away at the gateway's role as the curated catalog of "approved" tools.
Clients and platforms are taking the control plane
The second shift is on the client side. AI platforms now ship admin consoles that let organizations decide which connectors are available, who can enable them, and what scopes they get. When the agent runtime itself enforces an allowlist, a network-level allowlist in front of it becomes redundant.
Observability is following the same path. Tool calls are increasingly emitted as standard telemetry that flows into the SIEM and tracing stack you already run. The gateway's audit log was valuable when it was the only place tool calls were visible. It's less valuable when every hop is already instrumented.
The gateway tax
Once the core capabilities exist elsewhere, the overhead costs of a gateway become easier to see.
Every call takes an extra network hop, which adds latency to agent loops that may make dozens of tool calls per task. The gateway becomes a single point of failure for every agent in the company. And architecturally, gateways often encourage the exact pattern the spec now warns against: token passthrough, where one credential gets forwarded across trust boundaries it was never issued for. A proxy that terminates auth and re-originates it on your behalf breaks the end-to-end identity chain that modern MCP authorization is designed to preserve.
There's also a subtler cost. A gateway is a second policy engine. When access rules live in both your IdP and your gateway, they will eventually disagree, and the disagreement will surface as an incident.
Where the value is going
None of this means the concerns behind gateways were wrong. Identity, least privilege, auditability, and kill switches for agents are more important now than when gateways first appeared. What's changing is where those controls live.
Identity and authorization are moving into the identity provider and the protocol itself. Connector governance now sits with the agent platforms, which already decide what an organization can enable. Observability stops needing its own home once tool calls flow as standard telemetry into the stack you already run. And threat detection belongs with the security tools that watch everything else. What the gateway used to hold in one place is being handed back to the layers that own each piece natively.
If you're evaluating MCP infrastructure today, the useful question isn't "which gateway should we buy?" It's "which of these controls do our IdP, our agent platform, and our existing security stack already provide, and what's genuinely left over?"
What still justifies a gateway
To be fair to the category, there are real cases where a gateway still earns its place. Organizations running large fleets of legacy or internally built servers that don't support modern authorization will need something in front of them for a while. Highly regulated environments may want a single enforcement point for data loss prevention or content inspection that no individual server or client provides. And heterogeneous shops using many agent platforms, each with its own admin model, may find a neutral control layer simpler than configuring governance five different ways.
The honest forecast isn't that gateways vanish overnight. It's that they shrink from default architecture to become niche tools, useful for legacy bridging and specialized inspection, but no longer the thing every MCP deployment starts with.
The takeaway
Gateways were the right answer to an immature protocol. MCP is maturing, and the rest of the stack is learning to speak it natively. The teams that do best over the next year will be the ones who stop treating the gateway as the center of their agent security strategy and start asking which layer should actually own each control.
The box in the middle did its job. It's time to let the rest of the architecture catch up to it.
How NewCore goes beyond the gateway
If identity is where agent governance belongs, the next question is what an identity provider built for agents actually looks like. That's the problem NewCore was built to solve.
NewCore is a next-gen IdP that treats AI agents as first-class identities, not service accounts in disguise. Every agent gets its own lifecycle, credentials, and session, and NewCore acts as the OAuth 2.1 authorization server that MCP servers trust. The policy that decides what an agent can do lives in the same place as the policy for the humans it works for, so there's no second rulebook to drift out of sync.
NewCore does run a gateway endpoint. But that endpoint enforces identity decisions; it isn't where those decisions are made. The difference shows up everywhere.
Agents only see the tools they're allowed to use. NewCore filters the tool list per identity, so a tool outside an agent's policy is never discovered in the first place, not blocked after the agent reaches for it.
Permissions are scoped per tool rather than per server. Discovered tools fall into read, write, and delete groups, and each can be allowed outright, held for human approval, or blocked, with guardrails that cap rate, concurrency, and destructive actions across every connected app.
Every tool call leaves evidence: the audit trail ties each invocation to the agent, the person it acted for, and the policy that allowed or denied it. Denied attempts are early warning, not noise to filter out.
And none of it requires ripping out what you have. NewCore coexists with Okta, Entra ID, and your SaaS apps, so you can bring agents under governance without migrating your workforce first.
Gateways ask whether an agent can reach a server. NewCore asks who the agent is, who it's acting for, and whether it should be doing this right now. That's the question agent security actually has to answer.