Enterprise AI

Can incumbent AI governance vendors close the gap?

Sagar Batchu

August 20, 2026 · 3 min read

Most enterprises already have vendors shipping AI governance features. The hyperscalers ship model routing and audit trails, the enterprise platforms ship AI risk dashboards, and a wave of point tools ships gateways and guardrails. The question for a buyer is whether any of these architectures can be extended to cover a problem whose scope exceeds what they were built for: governing every AI agent and every system those agents reach.

This analysis works through the three groups of incumbents and where each architecture stops. For the full reference on the layer that closes the gap, see the AI control plane guide.

What AI governance actually requires

A system that governs AI needs to sit between every AI agent and every system those agents can reach. To do that, it needs to:

• Know who the user is and what they are permitted to access
• See every model call, regardless of which provider serves it
• See every tool call, regardless of which MCP server handles it
• Enforce policy on the content of traffic in real time
• Produce a correlated view across all of the above

No existing vendor’s architecture was built to do all of this. Each incumbent occupies a different layer, and the gap between that layer and the oversight the governance problem requires is structural.

Hyperscalers: AWS Bedrock, Azure AI Foundry, and Google Vertex AI

AWS Bedrock, Azure AI Foundry, and Google Vertex AI provide model routing, access controls, logging, and audit trails at enterprise scale. For an organization running entirely on one cloud, they are a reasonable starting point for AI governance.

A hyperscaler’s controls only apply to traffic routed through its platform, which means:

• An organization running models from Anthropic, Mistral, and an open-source provider gets three separate governance views with no correlation between them.
• Internal agents and MCP-connected tools that do not route through the cloud platform are invisible to these controls.
• As model and tool diversity increases, the share of traffic that the hyperscaler can see shrinks.

Enterprise platform vendors: ServiceNow, Salesforce, and the GRC suites

ServiceNow, CrowdStrike, Salesforce, and the major GRC and ITSM vendors own the policy and risk layer that AI governance needs to connect to. Governance belongs next to identity, policy, and compliance infrastructure, and these vendors already have all of that.

The problem is that these vendors sit above the traffic layer, not inside it:

• They can define policy, but enforcing it on every prompt, response, and tool call would require them to be in the path of that traffic.
• Adding real-time traffic enforcement means building a new layer from scratch. Salesforce’s MuleSoft Agent Fabric and ServiceNow’s AI Control Tower are moving in that direction, each adding an AI gateway for MCP governance, with ServiceNow extending to real-time enforcement that can shut down a rogue agent.

Point tools: LLM gateways and MCP security

LLM gateways and MCP security tools are already inside the traffic. They have enforcement capability within, and deep technical knowledge of, their respective layers.

Expanding their capabilities beyond their layers requires building what they do not have:

• Visibility into the identity layer above them and the policy layer that needs to govern them
• Cross-layer correlation across model calls, tool calls, and user identity

Many point tools in infrastructure categories are acquired before they can complete that expansion.

The gap is the path between layers

Each of these vendors was built to own one layer, and AI governance requires owning the path between layers. Closing that gap means rebuilding significant parts of their architecture, and the incumbents now attempting it confirm the direction: the control plane is the layer this problem requires.

The AI control plane guide covers the full architecture: the four functions, how the control plane relates to governance frameworks, and the tradeoffs to weigh before deploying one. To score a specific vendor, or a homegrown setup, against the capabilities this layer needs, use the evaluation checklist.