ServiceNow AI Gateway GA: A UK Steward Production Gate for MCP Tool Governance

What AI Gateway is — and what it is not

ServiceNow AI Gateway reached general availability on 10 September 2026 inside AI Control Tower. It is the runtime enforcement layer for Model Context Protocol (MCP) connections between agents and MCP servers — not a separate SKU, and not a replacement for Kill Switch or Runtime Observability.

If your UK estate already published playbooks for AI Control Tower Kill Switch and Runtime Observability, keep those lanes clean:

• Kill Switch contains compromised or runaway agents.
• Runtime Observability scores traces and detects drift after go-live.
• AI Gateway decides whether an agent may call an MCP tool at all, under which auth, and with which sensitive-data and pause controls.

Conflating the three in CAB will produce the wrong control owner and the wrong evidence pack.

Why UK Stewards need a production gate now

MCP is how agents reach tools. Without a gateway, Product Owners can wire agents straight to remote MCP servers — including external platforms — with little Steward visibility. AI Gateway puts a single governance plane in front of those calls: OAuth 2.1 at the gateway, tool-level policy, pre-deploy metadata scanning, and runtime sensitive-data scanning that blocks the entire response (it does not mask fields and let the rest through).

For UK organisations that already treat agent changes as CAB items, this is the missing data-plane gate: DPIA-friendly data minimisation (block-not-mask), an audit trail for every MCP call, and one place to pause a bad server without redesigning every agent.

Plugin, roles, and prerequisites

Confirm plugin and roles in non-prod before any production CAB. Localhost MCP servers are not supported — only remote MCP servers. Architecture note for platform teams: the data plane was rebased from Spring Boot to Envoy, which matters for capacity and network-path reviews.

Intake paths (how servers enter inventory)

AI Gateway supports three intake patterns:

1. (1A) Auto sync from AI Agent Studio — every 15 minutes, so Studio-registered servers appear without a manual CSV.
2. (1B) MCP catalog import — bring in catalogued servers in bulk for estate-wide onboarding.
3. (1C) Direct intake — for external platforms (Microsoft Copilot Studio, Claude Desktop, and similar) that are not native to Agent Studio.

Platform-agnostic design means Copilot Studio, Bedrock, Vertex, and custom agents can use the Gateway URL + OAuth rather than bypassing ServiceNow governance.

Lifecycle: Unmanaged → Managed → Deployed & Approved

Treat lifecycle as the Steward workflow, not a status badge:

1. Unmanaged — discovered or imported; not yet under playbook control.
2. Managed — starts the Onboard playbook: Assess → Build and test → Deploy.
3. Deployed & Approved — eligible for Product Owners in AI Agent Studio.

Critical UK control: Product Owners in AI Agent Studio only see approved servers. Unapproved servers stay hidden — which prevents “shadow MCP” wiring through the Studio UI. Your CAB should require evidence that the server reached Deployed & Approved before any production agent is allowed to bind to it.

Auth and connection model

• Agents authenticate with OAuth 2.1 via the gateway.
• Agents never connect direct to MCP servers when Gateway is in path.
• CIMD is available for VS Code and platforms that support it.

This is the architectural answer to “how do we prove agents cannot exfiltrate via a private MCP URL?” — the only durable URL Product Owners should hold is the Gateway endpoint under Steward-controlled clients.

Tool-level governance and sensitive-data controls

Beyond server allow/deny:

• Tool-level governance — approve or restrict specific tools on a managed server.
• Pre-deploy scan for malicious metadata before a server is trusted in production.
• Runtime sensitive-data scan (PII / credentials): on detection, Gateway blocks the entire response — not token masking. That is the DPIA-friendly posture: fail closed on sensitive egress/ingress through MCP.

Operational pause:

• Pause per-server or globally.
• Configurations are preserved; resume is one click.
• Pause / resume / sensitive-data config changes take effect within about 10 minutes (cache). Plan CAB windows and incident runbooks around that lag — do not promise instant fleet-wide effect.

Observability at the gateway boundary

Gateway metrics are measured at the boundary, without agent-side instrumentation:

• Success rates
• Latency (P50 / P90 / P95)
• Connection attempts

Use these for SRE/Steward dashboards. Do not treat Gateway latency panels as a substitute for AI Control Tower Runtime Observability quality scores — different control, different evidence.

UK Steward CAB checklist (production gate)

Use this numbered sequence in change records:

1. Confirm AI Control Tower Core sn_awh_config in the target instance; verify AI Gateway components installed.
2. Assign Steward / Agent Admin / MCP Client Admin roles to named accounts (no shared Steward logins).
3. Choose intake path (1A / 1B / 1C) and record the source of each production MCP server.
4. Move candidate servers Unmanaged → Managed; complete Onboard playbook (Assess / Build and test / Deploy).
5. Require Deployed & Approved before Studio Product Owners can bind agents.
6. Enforce OAuth 2.1 via Gateway; ban direct agent-to-server URLs in architecture standards.
7. Enable tool-level approvals and pre-deploy metadata scan; document reject criteria.
8. Enable runtime sensitive-data scan; confirm block entire response behaviour in a non-prod test with synthetic PII.
9. Document pause runbook (per-server and global) and the ~10 minute cache propagation expectation.
10. Attach DPIA / data-minimisation note: block-not-mask; audit trail for every MCP call; multi-vendor agents still forced through one governance plane.
11. Distinguish evidence packs: Gateway ≠ Kill Switch ≠ Runtime Observability.
12. Sign CAB only when a production-like agent call succeeds through Gateway with approved tools and fails closed on a sensitive-data probe.

Multi-vendor AI with one governance plane

UK programmes often mix ServiceNow agents with Copilot Studio, Bedrock, Vertex, or bespoke runtimes. AI Gateway’s platform-agnostic URL + OAuth model is how you keep a single Steward control plane without forcing every team onto one agent framework. Architecture review should reject any “temporary” direct MCP bypass for “just this vendor.”

What success looks like for AIATS clients

A Steward can answer, in one CAB pack: which MCP servers are approved, which tools each agent may call, how auth is terminated at the gateway, what happens when PII appears in a tool response, and how to pause a bad server without waiting for a full agent redeploy. That is production-ready MCP governance — not a dashboard screenshot of unmanaged inventory.