That distinction is the practical story for Windows administrators and security teams. The announcements, collected by Forkast, show MCP becoming a high-value enforcement point: an agent’s access to a tool, resource, or action can be constrained independently of the model that composed the request. But each vendor’s control applies only where its own gateway, cloud service, identity integration, or endpoint traffic path is actually deployed.
ServiceNow governs approved remote MCP connections through its AI Control Tower. Rubrik exposes its Security Cloud capabilities to agents under the customer’s existing permissions. Microsoft inspects MCP traffic routed through Global Secure Access and can block it at the network edge. This is a convergence in architecture, not yet a consolidated enterprise control plane.
ServiceNow moved MCP approval into the request path
ServiceNow says AI Gateway v3.4, released September 10, makes its AI Gateway the runtime enforcement layer for MCP connections in AI Control Tower. Its documentation describes lifecycle approval for MCP servers, OAuth 2.1 client registration, centrally managed server credentials, tool scanning, sensitive-data checks, connection pausing, and telemetry covering connection attempts, latency, success rate, and client identity.
The valuable change is that a server’s approval status can now affect whether an agent can use it. In a conventional catalog or governance workflow, an administrator may have an inventory record and a risk assessment while an application still has a direct credential and direct route to the target. ServiceNow’s design is intended to replace that direct path for gateway-managed connections: the agent authenticates to the gateway, while the gateway holds the downstream credentials.
For teams already using AI Gateway, the update also carries a migration risk that was easy to miss in the broader governance narrative. ServiceNow changed the gateway proxy URL format in v3.4. Existing MCP and Client Identity Metadata Discovery registrations using the prior endpoint need to be updated, or an otherwise unchanged client can lose access to its MCP server.
ServiceNow further says AI Gateway supports remote MCP servers, not servers running locally on a developer workstation. That leaves a substantial boundary outside the product’s declared scope. A developer connecting an IDE or desktop agent to a local stdio-based MCP server is not brought under this particular gateway’s lifecycle approval and runtime controls simply because the company has adopted AI Control Tower elsewhere.
Rubrik puts its existing permissions in front of agent workflows
Rubrik announced Rubrik MCP on September 15, describing it as a programmable path from AI agents to Rubrik Security Cloud data, identity, and application intelligence. The company says agents can use exposed API capabilities and that teams can turn multi-step recovery or compliance procedures into reusable tools across AI clients.
Rubrik’s press release makes three security commitments: role-based access-control parity between agents and human users, configurable permissions, and guardrails aligned with the OWASP MCP Top 10. Those are sensible controls for a product that can expose backup, recovery, identity, and security information to an agent, but they should not be read as proof that every agent workflow is safe.
RBAC parity preserves existing access boundaries; it does not improve overly broad ones. If a human service account already has broad recovery, retention, or data-discovery privileges, giving an agent the same entitlement can automate those actions at much higher speed. The security outcome therefore depends on the scopes assigned to the human and workload identities underneath Rubrik MCP, the tool definitions the agent can reach, and the approval process around reusable workflows.
Rubrik’s announcement says the implementation was developed with Anthropic and uses OWASP MCP Top 10-aligned guardrails. Those statements identify design intent, not independent evidence of effectiveness against prompt injection, confused-deputy behavior, malicious tool descriptions, or authorization mistakes in a customer environment. Security teams should treat “aligned” as a procurement and design-review starting point, then ask which individual threats are tested, logged, blocked, and recoverable.
There is also an availability qualification missing from the initial wave of coverage. Rubrik’s own announcement and subsequent reporting describe Rubrik MCP as a private preview for existing customers, with general availability targeted for October 2026. It is a concrete product move, but it is not yet a broadly deployable control for every Rubrik customer.
Microsoft’s firewall is powerful only on traffic it can see
Microsoft’s MCP Firewall is the most immediately relevant of the three for Windows and Entra administrators because it places protocol-aware policy inside Global Secure Access. Microsoft says the preview feature can discover MCP servers and tools in observed traffic, allow or block servers by URL, restrict tools, resources, and prompt templates, and enforce transport and MCP protocol-version rules.
The feature is materially more specific than a generic web filter. Microsoft’s published configuration guidance describes inspection of JSON-RPC 2.0 over Streamable HTTP and server-sent events, then matching policies against MCP methods and primitives. An administrator can begin with an allow or block default action, select discovered servers from recent activity, and narrow rules to particular tools on a server.
The deployment prerequisites change how the claim of “network-level enforcement” should be understood. Microsoft requires Global Secure Access traffic forwarding, a Global Secure Access client on an Entra-joined or hybrid Entra-joined Windows or macOS device, an Entra Internet Access license, and TLS inspection. The firewall cannot parse encrypted MCP messages unless TLS inspection is enabled, and it cannot control an agent connection that never traverses Global Secure Access.
This is the central operational caveat. Microsoft can discover shadow MCP servers from the traffic it sees, but it cannot discover every MCP server in an organization by declaration alone. Agents running on unmanaged endpoints, traffic excluded from forwarding, local stdio servers, and other non-routed paths remain outside this firewall’s enforcement boundary.
Microsoft’s own documentation also undercuts the submitted story’s timing. The MCP Firewall configuration page was last updated on August 6, 2026, and Microsoft’s September Entra update listed the feature earlier this month as a preview. Forkast reported an Entra Agent ID expansion on September 17, but the record indicates the MCP Firewall was publicly documented before that date rather than newly introduced that day. Microsoft has announced a preview capability, not general availability.
MCP is the chokepoint, but it is not yet the shared policy language
The vendors are making the same architectural bet: when an agent needs to discover a server, obtain credentials, list tools, read a resource, call a tool, or use a prompt template, the MCP transaction is a more dependable place to enforce policy than an instruction in the model’s context window.
A model-side restriction can be ignored, misinterpreted, bypassed through prompt injection, or overridden by an application that provides the model different tools. An application UI restriction says little about another client reaching the same server. A correctly deployed protocol gateway or inspection point can reject the action before the downstream service performs it.
But the controls being announced do different jobs:
- ServiceNow’s AI Gateway governs the lifecycle, registration, credentials, and runtime access of MCP connections it brokers through AI Control Tower.
- Rubrik MCP applies the customer’s permissions and guardrails to agents consuming Rubrik Security Cloud capabilities.
- Microsoft’s MCP Firewall discovers and applies allow-or-block policy to MCP network traffic routed through Global Secure Access.
Calling all three “MCP governance” is accurate at a high level. Treating them as interchangeable would be a mistake. ServiceNow provides an agent-to-server broker for its governed estate; Rubrik governs what agents can do inside the Rubrik product boundary; Microsoft provides a traffic inspection and enforcement layer at the managed endpoint and security-service edge. None of those statements establishes a shared authorization format, common audit schema, mutual server registry, or cross-vendor remediation workflow.
The immediate result for enterprise IT is likely to be more control points rather than one plane of glass. A security team could use Microsoft to block an unapproved external server, ServiceNow to manage approved remote servers and client registrations, and Rubrik to constrain access to resilience data. Correlating an incident across those products will still require deliberate identity mapping, log retention, time synchronization, and ownership assignments.
The rollout has created a new change-management problem
MCP’s attraction is that it allows agents and tools from different suppliers to connect with less custom integration work. The new governance products introduce a counterweight: every connection may now require server intake, client registration, identity assignment, TLS inspection, policy authoring, tool classification, and exception handling.
That is defensible overhead for agents with authority to retrieve sensitive data, modify records, run recovery workflows, or query internal systems. It is also a reason to distinguish low-risk informational tools from tools that change state. A broad “allow this MCP server” rule can prove too coarse when a single server exposes both harmless lookup tools and privileged administrative actions.
Windows-focused IT teams should inventory agent hosts separately from MCP servers. The host is where browser settings, developer tools, local extensions, Global Secure Access routing, certificates for TLS inspection, and Entra device state determine whether network controls are in effect. The server is where tool definitions, authentication, permissions, resource exposure, and update hygiene determine what an agent can do after a connection is allowed.
The vendors’ announcements establish MCP as an enforcement surface worth designing around. They do not eliminate the older work of least privilege, endpoint management, certificate deployment, centralized logging, and tested containment. For organizations that enable these controls, the first measurable outcome should be a list of every agent-to-tool connection that is actually routed, authenticated, and policy-covered—and a second list of the connections that are not.