An Exciting Upcoming Security Update to Servicenow AI Gateway - Coming Soon

[Saumya Shikhar]

If you've been building with ServiceNow’s AI Gateway, you already know it handles onboarding, credential mediation, and observability.

But here's a question we've been hearing a lot lately from customers and community members: "Once a tool request is authenticated, who decides if it should actually be allowed?"

Today, the honest answer is: the downstream MCP server does. And that's fine, until it isn't.

The Problem No One Talks About Enough

In practice, most enterprises aren't using only neatly defined and reputed remote MCP servers. They're operating across a mix of internal servers with no proper RBAC, third-party servers from reputable vendors, and everything in between.

The challenge? Those third-party servers weren't always built with enterprise-grade access control in mind. And even your internal servers — well, they each enforce their own policies, in their own way, with no single view of what's being allowed or disallowed across your AI ecosystem.

What that means in practice:

• You can't centrally restrict access to sensitive tools without coordinating across every server owner.
• If a server is misconfigured, privilege escalation is a real risk.
• Audit teams have no unified view of tool access decisions.
• Governance becomes a spreadsheet problem instead of a platform capability.

Sound familiar?

Two layer policy definition and implementation plane

Soon, AI Gateway is introducing Enterprise Access Management — an authorization layer built directly into the gateway. It works in two sequential layers. Both must pass for a request to go through.

Layer 1 — Client Authorization (Allow-Only, Fail-Closed)

Administrators assign tool groups to each MCP client integration. A client with no explicit grant for a MCP Server’s tool group cannot invoke tools in that group.

This exists today for MCP Servers and AI Gateway (using Client ID Metadata Document concept).

Layer 2 — User Authorization: Defence in Depth or Primary Control, Depending on the Server

After Layer 1 passes, the gateway evaluates user-level policies. What this layer does depends on the server it's protecting.

For MCP servers that have their own RBAC, the gateway adds defence in depth — deny policies that restrict access to sensitive tools by user role, enforced independently of whatever the downstream server does. If a server is misconfigured or overly permissive, the gateway still holds the line.

For MCP servers that lack native RBAC, there's an opt-in Restricted Mode. Enabling it flips the posture to fail-closed: tools not explicitly allowed are blocked by default. Here the gateway isn't supplementing another access control layer — it's providing the primary one. Deny policies still apply and override allow policies when both match.

Policies map to existing ServiceNow identity constructs — users, groups, roles — so there's no new identity model to learn. If you already manage access through ServiceNow, this fits right in.

Tool Grouping: Because Nobody Has Time for Tool-by-Tool Policies

One thing we thought hard about here is scale. Enterprises aren't running 5 tools. They're running scores of tools, across dozens of servers. Managing deny policies tool-by-tool would be a nightmare.

That's why Enterprise Access Management on AI Gateway would support flexible tool groupings — including system-defined groups like "All Tools", gateway-wide groups, and custom groups your AI Stewards/ Security Engineers/ Platform Engineers can define.  

Observability That Actually Helps

Enforcement without visibility is just a false sense of security.

Every policy evaluation — blocked, allowed or forwarded — is logged with full context: user identity, MCP server, tool requested, which policy triggered the decision. These logs surface directly in AI Control Tower, giving your security and compliance teams a consolidated view they've never had before.

You'll also get aggregated metrics like denials per policy and denials per server — and policies that affect broad swaths of your ecosystem (like a gateway-wide deny) are flagged as high-impact so they don't fly under the radar.

Why ServiceNow Is the Right Place for This

Here's what makes this different from bolt-on solutions: ServiceNow already owns the identity layer, the workflow layer, and the integration layer. Enterprise Access Management doesn't ask you to bring in a new policy engine or a new identity model. It plugs into what you already have.

As AI agents become more autonomous — discovering tools dynamically, crossing team and vendor boundaries — the gateway stops being just a routing layer. It becomes part of your enterprise security model.

What's Next

Enterprise Access Management is coming soon. We'll have more to share on availability and configuration details as we get closer.

Curious what policies you'd define first if you had this today? Drop a comment below or sign up for a 30-minute walkthrough with us.

Safe harbor notice for forward-looking statements

This presentation may contain "forward-looking" statements that are based on our beliefs and assumptions and on information currently available to us only as of the date of this presentation. Forward-looking statements involve known and unknown risks, uncertainties, and other factors that may cause actual results to differ materially from those expected or implied by the forward-looking statements. Further information on these and other factors that could cause or contribute to such differences include, but are not limited to, those discussed in the section titled "Risk Factors," set forth in our most recent Annual Report on Form 10-K and Quarterly Report on Form 10-Q and in our other Securities and Exchange Commission filings. We cannot guarantee that we will achieve the plans, intentions, or expectations disclosed in our forward-looking statements, and you should not place undue reliance on our forward-looking statements. The information on new products, features, or functionality is intended to outline our general product direction and should not be relied upon in making a purchasing decision, is for informational purposes only, and shall not be incorporated into any contract, and is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for our products remains at our sole discretion. We undertake no obligation, and do not intend, to update the forward-looking statements.