ServiceNow AI Gateway Adds Governance for MCP Servers
ServiceNow just gave enterprises a reason to stop letting agents talk to MCP servers however they please. The September 2026 release of AI Gateway (v3.4) adds MCP server governance as a first-class capability: every agent-to-server connection now runs through a central control point instead of a direct, unmonitored link.
If you've shipped an agent that calls Model Context Protocol (MCP) servers, you already know the problem this solves. MCP made it trivially easy for an agent to discover a tool and call it. It did not make it easy to answer "which agents can reach which servers, with what credentials, and can I prove that later?" ServiceNow's answer is to move that decision out of the agent and into the gateway.
One catalog, one approval gate
AI Gateway v3.4 pulls MCP servers into a single inventory inside AI Control Tower regardless of how they were registered: auto-discovered from AI Agent Studio, added through the MCP Server Console, imported from an MCP catalog, or entered by hand. The point of consolidating them is enforcement. Agents can only reach servers that are marked approved and active in that catalog, so an unvetted or shadow MCP server simply isn't reachable, no matter how an agent tries to discover it.
No more unscoped tokens on the agent
The part that matters most for anyone who has actually run MCP in production is authentication. ServiceNow's release notes are direct about it: every MCP connection is authenticated through the gateway, with no direct agent-to-server connections, no unscoped tokens, and no credentials sitting on the agent side. The gateway issues short-lived, scoped tokens per connection using OAuth 2.1, and server credentials live centrally instead of being copied into every agent that needs them.
This mirrors the direction the MCP specification itself has been pushing for HTTP-based servers, which define an OAuth 2.1 authorization flow with a metadata discovery step before a client ever gets a token:
GET /.well-known/oauth-authorization-server HTTP/1.1
Host: mcp.example.com
A client hits that endpoint to learn where to get scoped, short-lived tokens before calling any tool, rather than holding a static credential forever. What ServiceNow adds on top is that the gateway does this negotiation and token issuance on the agent's behalf, so individual agents never hold a long-lived secret at all.
A kill switch and a paper trail
Two more pieces close the loop. A new Pause control lets an operator halt a specific MCP server, or every connection at once, from AI Control Tower with no code change and no redeploy; other servers keep running while the risky one is frozen. And tool calls get scanned against the OWASP MCP Top 10, with a Data Sensitivity Check policy that inspects tool inputs and outputs and blocks responses carrying flagged data before they reach the agent. Everything, meanwhile, lands in a Monitor tab: success rates, P50/P90/P95 latency, and connection attempts per server and per tool, without instrumenting the agent side yourself.
Why this matters if you're not on ServiceNow
Most teams building agents don't have a ServiceNow AI Gateway sitting in front of their MCP servers, and that's exactly why this release is worth reading. It's a checklist of the governance gaps that show up the moment an MCP-based agent leaves a demo and enters a real enterprise: an approved-server allowlist, centralized OAuth instead of static tokens on agents, a pause button that doesn't require a redeploy, and a tool-level audit trail. If your own agent stack is missing any of these, that's the gap ServiceNow just decided was worth building a product feature around.
What to do Monday morning
Audit your own MCP setup against the four pieces above before you audit anyone else's. Check whether your agents hold long-lived MCP credentials directly, whether there's a single list of approved servers anywhere, and whether you could pause one misbehaving server without touching code. If the answer to any of those is no, that's your next sprint, gateway vendor or not.
Governance like this is what separates an MCP pilot from something you can actually hand to a security team, and that gap is exactly where forward deployed engineers earn their keep.