Deutsch

Snowflake Bought Natoma. Microsoft Shipped Agent 365. Anthropic Tunneled MCP. Here's the CTO Pattern for the Agent Governance Roadmap

Three MCP control planes from Snowflake, Microsoft, and Anthropic vying for the CTO agent governance roadmap

Three major enterprise vendors have moved on Model Context Protocol (MCP) governance in 30 days. The question for the chief technology officer (CTO) isn't which one wins. It's whether you see the pattern before your next renewal cycle.

What Snowflake Actually Bought

On May 27, 2026, Snowflake announced a definitive agreement to acquire Natoma, an enterprise MCP governance platform built specifically for AI agents. According to Snowflake's press release, the deal adds three capabilities to Snowflake's stack: a verified MCP server registry, an identity layer, and an access-policy plane.

What that means in practice: Snowflake's Cortex Agents, Snowflake Intelligence, and Cortex Code can now reach enterprise software as a service (SaaS) apps, databases, APIs, virtual private clouds (VPCs), and on-premises systems through a single governance surface. Third-party AI platforms get the same access. Every agent action is auditable, every connection is policy-gated, and every MCP server must pass through the registry before an agent can use it.

Snowflake's technical blog frames the motivation directly: MCP adoption has introduced fragmented governance, shadow AI activity, and data-exfiltration risk as agents multiply across enterprise systems. Natoma turns the data warehouse into the governance fabric, not just the data store. CIO's coverage of the deal called it a bet that data gravity pulls governance decisions toward wherever your data warehouse already sits.

Key Facts

  • Snowflake announced its intent to acquire Natoma on May 27, 2026, adding a verified MCP server registry, identity layer, and access-policy plane to its stack (Snowflake press release, 2026).
  • The Natoma deal is the third major MCP-governance move in a 30-day window: Anthropic shipped self-hosted sandboxes and MCP tunnels on May 19, Microsoft positioned Agent 365 as the AI control plane on May 28-29, and Snowflake closed the window on May 27.
  • Three distinct platform layers are now competing to own the agent control plane: the data layer (Snowflake), the productivity layer (Microsoft), and the model layer (Anthropic).

The MCP Acquisition Pattern Most CTOs Aren't Naming Yet

Diagram of three MCP control plane layers with Snowflake plus Natoma highlighting the data layer

The trap isn't picking the wrong vendor. The trap is treating each of these moves as an isolated product announcement rather than as a single pattern unfolding in sequence.

Here's the pattern: every major enterprise platform vendor is racing to own the MCP control plane, not because MCP is technically mature, but because whoever establishes governance ownership now sets the procurement rules for the next five years of enterprise agent buying.

The three players represent three structurally different bets on which layer earns the right to be the governance anchor.

Data layer (Snowflake + Natoma). The bet here is that data gravity wins. Enterprises already concentrate sensitive data in their warehouse. If governance follows data, then the warehouse operator becomes the natural policy enforcer for every agent that touches that data. Natoma's registry, identity layer, and policy plane drop directly into that gravity well.

Productivity layer (Microsoft via Agent 365). Microsoft's bet, announced in late May through Agent 365, is that the enterprise workflow layer owns governance because agents derive value from workflows. If agents live in Microsoft 365, Teams, and Copilot Studio, then the identity and policy fabric already woven through Entra ID and Azure is the natural home for agent control. The productivity suite already knows who the user is, what they're authorized to do, and which systems they can reach.

Model layer (Anthropic via self-hosted sandboxes and MCP tunnels). Anthropic's move, shipped May 19, is a different argument: run the agent execution environment inside the customer's security perimeter. Anthropic's self-hosted sandboxes and MCP tunnels let enterprise agents reach private systems through a single outbound gateway, with no inbound firewall exposure. The model vendor becomes the trust anchor because it controls where reasoning happens and how private systems are accessed.

None of these bets are wrong. All three are coherent. But they're not compatible as the sole governance layer, and all three vendors are pitching theirs as exactly that.

The CTO who commits to one layer's control plane before the pattern stabilizes risks building governance architecture that works until a renewal cycle creates a lock-in moment they didn't see coming.

Why the Data Layer Pitch Is Different

Snowflake's argument deserves its own examination because it's structurally distinct from the other two.

The productivity-layer pitch (Microsoft) and the model-layer pitch (Anthropic) both rely on network effects through existing software relationships. Microsoft's leverage is that your employees already live in Teams and Outlook. Anthropic's leverage is that your developers are already building with Claude. Both pitches say: you already trust us for X, now extend that trust to agent governance.

Snowflake's pitch is different. It says: your governance should follow your data because your data doesn't move. Sensitive enterprise records sit in the warehouse. Compliance requirements already attach to the warehouse. Security controls already wrap the warehouse. Natoma's registry and policy plane don't ask you to extend trust to a new surface. They attach governance to a surface that's already trusted.

That argument is structurally stronger than it might look in a product briefing. It doesn't require you to believe Snowflake is the best AI company. It only requires you to believe that data gravity is real and that your compliance team will always ask "where does the data live" before approving any agent action.

But don't mistake "structurally coherent" for "strategically safe." Accepting Snowflake's data-layer governance pitch still means accepting Snowflake as the policy enforcement point for every agent across your stack, including agents built on non-Snowflake infrastructure. That's significant architectural centralization regardless of how clean the argument is.

For a framework on evaluating vendor lock-in risk at the governance layer, the AI sovereignty piece on vendor lock-in covers the dependency pattern in more detail.

The 4-Question CTO Test for Any MCP Control Plane

Before committing to any vendor's MCP governance approach, whether that's Snowflake's Natoma acquisition, Microsoft's Agent 365, or Anthropic's sandbox architecture, run these four questions.

1. Verified MCP server registry: who vouches that an MCP server is safe to install? An MCP control plane needs a signed, centrally managed list of approved servers. Ask each vendor: what's the process for getting a server into the registry? Who audits it? What happens when a registered server is compromised? The answer tells you whether the registry is a real security mechanism or a product checklist item.

2. Identity model: does the agent inherit the user's identity, the agent's own service identity, or both? This question has significant downstream consequences. If the agent inherits user identity, it has user-level access to every system that user can reach. If it uses its own service identity, you need a separate permission model. If it uses both (delegated identity for some actions, service identity for others), you need clarity on exactly which actions use which model. Blurry answers here are a governance risk, not a product gap.

3. Policy engine: where does "agent X can take action Y on system Z" actually get evaluated? The policy engine is the runtime logic that determines what an agent is allowed to do in a given context. It needs to be centralized (so you don't have policy fragmentation across systems), auditable (so you can reconstruct decisions), and fast enough not to introduce latency that makes agents unusable. Ask vendors where the policy engine runs, how it's updated, and whether policy evaluation is synchronous or cached.

4. Audit trail: can you reconstruct exactly which agent did what, to which record, on whose behalf? "Audit trail" is not the same as "logs." An audit trail answers causality questions: why did the agent make this API call, what data did it retrieve, whose authorization did it use, and what changed as a result. If a vendor's audit story is "you get server logs," that's a different answer than "you get a structured event stream with causal linkage to the originating user action." Know which one you're buying. The audit trails for AI-executed actions resource covers what a production-ready audit architecture looks like.

For the broader evaluation framework, the AI approval gates and vendor review guidance is a useful companion.

Frequently Asked Questions

What is Snowflake's Natoma acquisition?

Natoma is an enterprise MCP governance platform that adds a verified server registry, an identity layer, and an access-policy plane to AI agent deployments. Snowflake announced its intent to acquire Natoma on May 27, 2026. The deal gives Snowflake a governance fabric that lets Cortex Agents and third-party AI platforms connect to enterprise systems through a single, auditable control surface, without requiring agents to bypass the data warehouse's existing security controls.

Why are MCP control planes suddenly the procurement battleground in 2026?

MCP, the Model Context Protocol, is the emerging standard for how AI agents connect to external tools and data sources. As enterprise agent adoption accelerates, whoever controls the policy layer that governs which agents can connect to which systems gains significant procurement leverage. Three major vendors (Snowflake, Microsoft, Anthropic) have made distinct moves on MCP governance within 30 days. The race isn't about MCP being mature. It's about establishing governance ownership now, while the standard is still forming and enterprises haven't yet committed to an architecture.

How should CTOs avoid being locked into one vendor's MCP layer?

The first move is to write your own MCP control-plane evaluation rubric using the four questions above before evaluating any vendor. That gives you vendor-neutral criteria. The second move is to inventory which agents in your organization currently use MCP and which control surface they already touch. If most of your MCP-connected agents run through Microsoft 365, you're already partially in the productivity-layer camp whether you meant to be or not. Making that visible lets you make an intentional architectural choice rather than inheriting one through product adoption.

What CTOs Should Do This Month

Four concrete actions that cost less than a full vendor evaluation cycle but establish the governance posture you need:

  • Write a one-page MCP control-plane evaluation rubric. Use the four-question test above. One page forces prioritization. Share it with your security and procurement teams before any vendor presents. That way you're evaluating vendor pitches against your criteria, not their criteria.

  • Inventory which agents currently use MCP and which control surface they touch. This doesn't require a full audit. Ask your engineering leads: what agents are running, which ones use MCP connections, and which vendor's identity or policy layer is handling those connections today. The answer will likely surprise you.

  • Schedule a 30-minute conversation with each of the three vendors before your next renewal cycle. Not a product demo. A governance architecture conversation. Bring the four questions. Ask them specifically. The vendor's ability to answer clearly, not just fluently, tells you a lot about how mature their control-plane story actually is.

  • Map your agents to the data classification framework. Before any MCP connection is authorized in production, the agent should know which data classification tier it's accessing. The data classification for AI access resource covers how to build that mapping. Without it, the control plane evaluations above are policy decisions with no enforcement surface.

The pattern is moving fast. But the right response isn't to pick the first vendor that looks credible. It's to establish your own evaluation framework while all three options are still genuinely available.

Learn More