Deutsch

Snowflake kauft Natoma. Microsoft liefert Agent 365. Anthropic tunnelt MCP. Das CTO-Muster für die Agent-Governance-Roadmap

Drei MCP-control planes von Snowflake, Microsoft und Anthropic im Wettbewerb um die CTO-Agent-Governance-Roadmap

Drei große Unternehmensanbieter haben innerhalb von 30 Tagen beim Model Context Protocol (MCP) Governance-Schritte unternommen. Die Frage für den CTO lautet nicht, wer davon gewinnt. Die Frage lautet, ob Sie das Muster erkennen, bevor Ihr nächster Verlängerungszyklus beginnt.

Was Snowflake tatsächlich gekauft hat

Am 27. Mai 2026 gab Snowflake eine definitive Vereinbarung zur Übernahme von Natoma bekannt, einer Enterprise-MCP-Governance-Plattform, die speziell für AI-Agenten entwickelt wurde. Laut Snowflakes Pressemitteilung fügt die Transaktion drei Fähigkeiten zum Snowflake-Stack hinzu: eine verifizierte MCP-Server-Registry, eine Identitätsschicht und eine Access-Policy-Ebene.

Was das in der Praxis bedeutet: Snowflakes Cortex Agents, Snowflake Intelligence und Cortex Code können jetzt über eine einzige Governance-Oberfläche auf Enterprise-SaaS-Anwendungen, Datenbanken, APIs, Virtual Private Clouds (VPCs) und On-Premises-Systeme zugreifen. Drittanbieter-AI-Plattformen erhalten denselben Zugang. Jede Agentenaktion ist prüfbar, jede Verbindung ist richtliniengesteuert, und jeder MCP-Server muss die Registry durchlaufen, bevor ein Agent ihn nutzen kann.

Snowflakes technischer Blog benennt die Motivation direkt: MCP-Einführung hat zu fragmentierter Governance, shadow AI-Aktivitäten und Daten-Exfiltrationsrisiken geführt, während sich Agenten über Enterprise-Systeme vermehren. Natoma verwandelt das Data Warehouse in das Governance-Geflecht, nicht nur in den Datenspeicher. CIOs Berichterstattung zu der Transaktion bezeichnete sie als Wette darauf, dass Datengravitation Governance-Entscheidungen dorthin zieht, wo Ihr Data Warehouse bereits ansässig ist.

Key Facts

  • Snowflake gab am 27. Mai 2026 seine Absicht bekannt, Natoma zu übernehmen, und fügt damit eine verifizierte MCP-Server-Registry, eine Identitätsschicht und eine Access-Policy-Ebene zu seinem Stack hinzu (Snowflake Pressemitteilung, 2026).
  • Die Natoma-Transaktion ist der dritte große MCP-Governance-Schritt in einem 30-Tage-Fenster: Anthropic lieferte am 19. Mai selbst gehostete Sandboxen und MCP-Tunnel, Microsoft positionierte Agent 365 am 28./29. Mai als AI-control plane, und Snowflake schloss das Fenster am 27. Mai.
  • Drei unterschiedliche Plattformebenen konkurrieren jetzt darum, die Agent-control plane zu besitzen: die Datenebene (Snowflake), die Produktivitätsebene (Microsoft) und die Modellebene (Anthropic).

Das MCP-Akquisitionsmuster, das die meisten CTOs noch nicht benennen

Diagramm der drei MCP-control-plane-Schichten mit Snowflake plus Natoma, die die Datenschicht hervorheben

Die Falle ist nicht, den falschen Anbieter zu wählen. Die Falle besteht darin, jeden dieser Schritte als isolierte Produktankündigung zu behandeln, anstatt als ein einziges, sich sequenziell entfaltendes Muster.

Das Muster lautet: Jeder große Enterprise-Plattformanbieter versucht, die MCP-control plane zu besitzen, nicht weil MCP technisch ausgereift ist, sondern weil derjenige, der jetzt die Governance-Eigentümerschaft etabliert, die Beschaffungsregeln für die nächsten fünf Jahre des Enterprise-Agent-Einkaufs festlegt.

Die drei Akteure vertreten drei strukturell unterschiedliche Wetten darauf, welche Ebene das Recht verdient, der Governance-Anker zu sein.

Datenebene (Snowflake + Natoma). Die Wette hier ist, dass Datengravitation gewinnt. Unternehmen konzentrieren bereits sensible Daten in ihrem Warehouse. Wenn Governance den Daten folgt, wird der Warehouse-Betreiber der natürliche Richtlinienbeauftragte für jeden Agenten, der diese Daten berührt. Natomas Registry, Identitätsschicht und Policy-Ebene fallen direkt in diesen Gravitationssog.

Produktivitätsebene (Microsoft über Agent 365). Microsofts Wette, Ende Mai durch Agent 365 angekündigt, lautet: Die Enterprise-Workflow-Ebene besitzt Governance, weil Agenten ihren Wert aus Workflows ableiten. Wenn Agenten in Microsoft 365, Teams und Copilot Studio leben, dann ist das durch Entra ID und Azure bereits gewebte Identitäts- und Richtliniengeflecht der natürliche Standort für die Agentensteuerung. Die Produktivitätssuite weiß bereits, wer der Nutzer ist, wozu er berechtigt ist und welche Systeme er erreichen kann.

Modellebene (Anthropic über selbst gehostete Sandboxen und MCP-Tunnel). Anthropics Schritt vom 19. Mai ist ein anderes Argument: Führen Sie die Agenten-Ausführungsumgebung innerhalb des Sicherheitsperimeters des Kunden aus. Anthropics selbst gehostete Sandboxen und MCP-Tunnel ermöglichen Enterprise-Agenten, über ein einziges ausgehendes Gateway auf private Systeme zuzugreifen, ohne eingehende Firewall-Exposition. Der Modellanbieter wird zum Vertrauensanker, weil er kontrolliert, wo das Reasoning stattfindet und wie auf private Systeme zugegriffen wird.

Keine dieser Wetten ist falsch. Alle drei sind kohärent. Aber sie sind nicht als alleinige Governance-Schicht kompatibel, und alle drei Anbieter pitchen genau das.

Der CTO, der sich auf die control plane einer Ebene festlegt, bevor sich das Muster stabilisiert, riskiert eine Governance-Architektur aufzubauen, die funktioniert, bis ein Verlängerungszyklus einen Lock-in-Moment schafft, den er nicht hat kommen sehen.

Warum der Datenschicht-Pitch anders ist

Snowflakes Argument verdient eine eigene Betrachtung, weil es strukturell von den anderen beiden verschieden ist.

Der Produktivitätsschicht-Pitch (Microsoft) und der Modellschicht-Pitch (Anthropic) basieren beide auf Netzwerkeffekten durch bestehende Softwarebeziehungen. Microsofts Hebel ist, dass Ihre Mitarbeiter bereits in Teams und Outlook leben. Anthropics Hebel ist, dass Ihre Entwickler bereits mit Claude bauen. Beide Pitches sagen: Sie vertrauen uns bereits für X, erweitern Sie jetzt dieses Vertrauen auf Agent-Governance.

Snowflakes Pitch ist anders. Er lautet: Ihre Governance sollte Ihren Daten folgen, weil sich Ihre Daten nicht bewegen. Sensible Unternehmensunterlagen liegen im Warehouse. Compliance-Anforderungen sind bereits an das Warehouse geknüpft. Sicherheitskontrollen umhüllen das Warehouse bereits. Natomas Registry und Policy-Ebene verlangen nicht von Ihnen, das Vertrauen auf eine neue Oberfläche auszuweiten. Sie verknüpfen Governance mit einer Oberfläche, der bereits vertraut wird.

Dieses Argument ist strukturell stärker als es in einem Produkt-Briefing aussehen mag. Es erfordert nicht, dass Sie glauben, Snowflake sei das beste AI-Unternehmen. Es erfordert nur, dass Sie glauben, Datengravitation sei real und Ihr Compliance-Team werde immer fragen „Wo liegen die Daten?", bevor es eine Agentenhandlung genehmigt.

Aber verwechseln Sie „strukturell kohärent" nicht mit „strategisch sicher". Snowflakes Datenschicht-Governance-Pitch zu akzeptieren bedeutet immer noch, Snowflake als Policy-Enforcement-Punkt für jeden Agenten in Ihrem gesamten Stack zu akzeptieren, einschließlich Agenten, die auf Nicht-Snowflake-Infrastruktur aufgebaut sind. Das ist eine erhebliche Zentralisierung der Architektur, unabhängig davon, wie sauber das Argument ist.

Für ein Framework zur Bewertung von Anbieterabhängigkeitsrisiken auf der Governance-Ebene deckt der AI-Souveränitätsbeitrag zu Anbieterabhängigkeit das Abhängigkeitsmuster ausführlicher ab.

Der 4-Fragen-CTO-Test für jede MCP-control plane

Führen Sie diese vier Fragen durch, bevor Sie sich für den MCP-Governance-Ansatz eines Anbieters entscheiden, ob das Snowflakes Natoma-Akquisition, Microsofts Agent 365 oder Anthropics Sandbox-Architektur ist.

1. Verifizierte MCP-Server-Registry: Wer bürgt dafür, dass ein MCP-Server sicher installierbar ist? Eine MCP-control plane benötigt eine signierte, zentral verwaltete Liste genehmigter Server. Fragen Sie jeden Anbieter: Wie gelangt ein Server in die Registry? Wer prüft ihn? Was passiert, wenn ein registrierter Server kompromittiert wird? Die Antwort zeigt Ihnen, ob die Registry ein echter Sicherheitsmechanismus oder ein Produktchecklisten-Punkt ist.

2. Identitätsmodell: Übernimmt der Agent die Benutzeridentität, seine eigene Service-Identität oder beides? Diese Frage hat erhebliche nachgelagerte Konsequenzen. Wenn der Agent die Benutzeridentität übernimmt, hat er Zugang auf Benutzerebene zu jedem System, das der Nutzer erreichen kann. Wenn er eine eigene Service-Identität verwendet, benötigen Sie ein separates Berechtigungsmodell. Wenn er beides verwendet (delegierte Identität für einige Handlungen, Service-Identität für andere), benötigen Sie Klarheit darüber, welche Handlungen welches Modell verwenden. Unklare Antworten hier sind ein Governance-Risiko, keine Produktlücke.

3. Policy-Engine: Wo wird „Agent X darf Aktion Y auf System Z durchführen" tatsächlich ausgewertet? Die Policy-Engine ist die Laufzeitlogik, die bestimmt, was ein Agent in einem gegebenen Kontext tun darf. Sie muss zentralisiert (damit keine Richtlinienfragmentierung über Systeme hinweg entsteht), prüfbar (damit Entscheidungen nachvollzogen werden können) und schnell genug sein, um keine Latenz einzuführen, die Agenten unbrauchbar macht. Fragen Sie Anbieter, wo die Policy-Engine läuft, wie sie aktualisiert wird und ob die Richtlinienauswertung synchron oder gecacht ist.

4. Prüfpfad: Können Sie genau rekonstruieren, welcher Agent was an welchem Datensatz im Auftrag von wem getan hat? „Prüfpfad" ist nicht dasselbe wie „Protokolle". Ein Prüfpfad beantwortet Kausalitätsfragen: Warum hat der Agent diesen API-Aufruf gemacht, welche Daten hat er abgerufen, wessen Autorisierung hat er verwendet, und was hat sich daraus geändert? Wenn die Prüfgeschichte eines Anbieters „Sie erhalten Server-Protokolle" lautet, ist das eine andere Antwort als „Sie erhalten einen strukturierten Ereignisstrom mit kausaler Verknüpfung zur ursprünglichen Benutzeraktion." Wissen Sie, was Sie kaufen. Der Ressourcenbeitrag zu Prüfpfaden für AI-ausgeführte Aktionen beschreibt, wie eine produktionsreife Prüfarchitektur aussieht.

Für den übergeordneten Bewertungsrahmen ist die Leitlinie zu AI-Approval-Gates und Vendor-Review eine nützliche Ergänzung.

Häufig gestellte Fragen

Was ist Snowflakes Natoma-Akquisition?

Natoma ist eine Enterprise-MCP-Governance-Plattform, die AI-Agent-Bereitstellungen um eine verifizierte Server-Registry, eine Identitätsschicht und eine Access-Policy-Ebene erweitert. Snowflake gab am 27. Mai 2026 seine Absicht bekannt, Natoma zu übernehmen. Die Transaktion gibt Snowflake ein Governance-Geflecht, das es Cortex Agents und Drittanbieter-AI-Plattformen ermöglicht, über eine einzige prüfbare Steuerungsoberfläche eine Verbindung zu Enterprise-Systemen herzustellen, ohne die bestehenden Sicherheitskontrollen des Data Warehouse zu umgehen.

Warum sind MCP-control planes 2026 plötzlich das Beschaffungsschlachtfeld?

MCP, das Model Context Protocol, ist der aufkommende Standard dafür, wie AI-Agenten eine Verbindung zu externen Tools und Datenquellen herstellen. Da die unternehmensweite Einführung von Agenten beschleunigt wird, erhält derjenige, der die Richtlinienebene kontrolliert, die regelt, welche Agenten eine Verbindung zu welchen Systemen herstellen können, erheblichen Beschaffungshebel. Drei große Anbieter (Snowflake, Microsoft, Anthropic) haben innerhalb von 30 Tagen unterschiedliche Schritte zur MCP-Governance unternommen. Das Rennen geht nicht darum, dass MCP ausgereift ist. Es geht darum, jetzt die Governance-Eigentümerschaft zu etablieren, solange der Standard noch in der Entstehung ist und Unternehmen sich noch nicht auf eine Architektur festgelegt haben.

Wie sollten CTOs vermeiden, sich in die MCP-Schicht eines Anbieters einzusperren?

Der erste Schritt ist, vor der Evaluation eines Anbieters Ihren eigenen MCP-control-plane-Bewertungsrahmen anhand der vier obigen Fragen zu erstellen. Das gibt Ihnen anbieterneutrale Kriterien. Der zweite Schritt ist, zu inventarisieren, welche Agenten in Ihrer Organisation derzeit MCP verwenden und welche Steuerungsoberfläche sie bereits berühren. Wenn die meisten Ihrer MCP-verbundenen Agenten durch Microsoft 365 laufen, befinden Sie sich bereits teilweise im Produktivitätsschicht-Lager, ob beabsichtigt oder nicht. Das sichtbar zu machen ermöglicht Ihnen eine bewusste Architekturentscheidung, anstatt eine durch Produktakzeptanz ererbte zu erhalten.

Was CTOs diesen Monat tun sollten

Vier konkrete Maßnahmen, die weniger kosten als ein vollständiger Anbieter-Evaluierungszyklus, aber die Governance-Haltung etablieren, die Sie benötigen:

  • Erstellen Sie einen einseitigen MCP-control-plane-Bewertungsrahmen. Verwenden Sie den Vier-Fragen-Test oben. Eine Seite erzwingt Priorisierung. Teilen Sie ihn mit Ihren Sicherheits- und Beschaffungsteams, bevor ein Anbieter präsentiert. So bewerten Sie Anbieter-Pitches nach Ihren Kriterien, nicht nach deren Kriterien.

  • Inventarisieren Sie, welche Agenten derzeit MCP verwenden und welche Steuerungsoberfläche sie berühren. Das erfordert kein vollständiges Audit. Fragen Sie Ihre Engineering-Leads: Welche Agenten laufen, welche verwenden MCP-Verbindungen, und welche Identitäts- oder Richtlinienebene welches Anbieters verwaltet diese Verbindungen heute? Die Antwort wird Sie wahrscheinlich überraschen.

  • Vereinbaren Sie ein 30-minütiges Gespräch mit jedem der drei Anbieter vor Ihrem nächsten Verlängerungszyklus. Kein Produkt-Demo. Ein Governance-Architektur-Gespräch. Bringen Sie die vier Fragen mit. Stellen Sie sie konkret. Die Fähigkeit des Anbieters, klar und nicht nur geläufig zu antworten, verrät viel darüber, wie ausgereift seine control-plane-Geschichte tatsächlich ist.

  • Ordnen Sie Ihre Agenten dem Datenklassifizierungsrahmen zu. Bevor eine MCP-Verbindung in der Produktivumgebung autorisiert wird, sollte der Agent wissen, auf welche Datenklassifizierungsstufe er zugreift. Der Ressourcenbeitrag zur Datenklassifizierung für AI-Zugang beschreibt, wie diese Zuordnung aufgebaut wird. Ohne sie sind die obigen control-plane-Evaluationen Richtlinienentscheidungen ohne Durchsetzungsoberfläche.

Das Muster entwickelt sich schnell. Aber die richtige Antwort ist nicht, den ersten Anbieter zu wählen, der glaubwürdig wirkt. Es ist, Ihren eigenen Bewertungsrahmen zu etablieren, solange alle drei Optionen noch wirklich verfügbar sind.

Weiterführende Artikel