Die Kurzfassung
Auf der Black Hat 2026 hat Snowflake das Cortex AI Gateway gestartet – eine zentrale Schicht, die regelt, wie KI-Agenten auf Modelle, Daten, MCP-Server und Unternehmenswerkzeuge zugreifen, und bei jedem Tool-Aufruf Identität, Autorisierung, Audit und Kostengrenzen durchsetzt. Die Technik stammt aus der Übernahme von Natoma im Mai 2026. Das Gateway deckt neben Snowflakes eigenen Agenten auch Agenten auf Amazon Bedrock, Azure AI Foundry, ChatGPT, Cursor, LangChain und LlamaIndex ab und startet überwiegend als Private Preview; Agenten-Identität und eingeschränkter Sitzungs-Scope sind allgemein verfügbar oder kurz davor.
Das Signal für Engineering-Verantwortliche reicht über einen Anbieter hinaus. Zusammen mit den Übernahmen im Bereich Agenten-Identität durch Cyera und Okta in derselben Woche zeigt der Start, dass sich das „MCP-Gateway“ vom Nischenwerkzeug zur Standardinfrastruktur verfestigt. Stehen autonome Agenten auf Ihrer Roadmap, wird eine Governance-Schicht – wer hat angefragt, worauf darf er zugreifen, war es erlaubt, was hat es gekostet – zu einer Komponente, die man von Anfang an einplant, statt sie später anzuflanschen.
Was hat Snowflake konkret vorgestellt?
Auf der Sicherheitskonferenz Black Hat 2026 präsentierte Snowflake das Cortex AI Gateway als zentrale Kontrollschicht dafür, wie KI-Agenten auf Modelle, Daten, MCP-Server und Unternehmenswerkzeuge zugreifen. Entscheidend: Es beschränkt sich nicht auf Snowflakes eigene Agenten, sondern soll auch Ökosysteme von Drittanbietern zentral steuern – Amazon Bedrock, Azure AI Foundry, ChatGPT, Claude Code, Cursor sowie eigene Anwendungen auf Basis von LangChain oder LlamaIndex. Zu den genannten Funktionen gehören feingranulare Autorisierung und Zugriffskontrolle, Audit-Trails der Agentenaktionen in Echtzeit, Unterstützung für mehr als 100 MCP-Server, automatische Erkennung und Überwachung von „Schatten-KI“ sowie Kostensteuerung mit Budgetgrenzen. Die meisten Funktionen starten als Private Preview; Agenten-Identität und ein eingeschränkter Sitzungs-Scope werden als allgemein verfügbar oder unmittelbar bevorstehend genannt.
Die Technik stammt aus einer Übernahme. Snowflake hat das Gateway auf Basis von Natoma gebaut, einem auf zentrale MCP-Gateways spezialisierten Start-up, das im Mai 2026 übernommen wurde und genau dafür gedacht war, Identität, Richtlinien und Audit auf Tool-Aufruf-Ebene durchzusetzen. Aufschlussreich ist die Einordnung von Snowflakes Chief Security and Trust Officer Mayank Upadhyay: Unternehmens-KI bewege sich von der Interoperabilität der Daten hin zur Interoperabilität der Agenten, und Sicherheit müsse im Zentrum dieses Wandels stehen. Das schwierige Problem ist also nicht mehr, Systeme Daten austauschen zu lassen, sondern autonome Agenten sicher über diese Systeme hinweg handeln zu lassen. Wer ernsthafte KI-Agentensysteme baut, kennt diesen Wandel: Sobald ein Agent etwas tun kann, statt nur Fragen zu beantworten, ist Zugriffskontrolle kein Detail mehr, sondern der Kern der Sache.
Warum braucht ein Agent überhaupt ein Gateway?
Um zu verstehen, warum das mehr als eine Produktmeldung ist, lohnt ein Blick darauf, wie die meisten Teams ihre ersten Agenten anbinden. Jeder Agent bekommt Zugangsdaten und verbindet sich direkt mit den Werkzeugen, die er braucht – einer Datenbank, einer internen API, einer SaaS-Anwendung, ein oder zwei MCP-Servern. In der Demo funktioniert das. Als Governance funktioniert es nicht mehr, sobald ein Dutzend Agenten läuft, denn jede dieser Direktverbindungen ist ein eigener Pfad mit eigenen Schlüsseln, eigenem Schadensradius und oft ohne zentrales Log. Auf die Frage „Welcher Agent hat letzte Nacht die Kundentabelle gelesen, und durfte er das?“ gibt es dann häufig keine saubere Antwort.
Ein Gateway dreht das um. Statt dass Agenten Zugangsdaten halten und Werkzeuge direkt aufrufen, läuft jeder Aufruf über einen Kontrollpunkt, der bei jeder Anfrage drei Dinge prüft: wer die Aktion angefordert hat, welche Rechte er hat und ob die Aktion erlaubt ist – und das Ergebnis protokolliert. Erst dieser eine Engpass macht Least-Privilege-Zugriff, sauberen Entzug von Rechten, Audit in Echtzeit und Kostengrenzen möglich. Er macht auch Schatten-KI sichtbar: nicht genehmigte Agenten und Integrationen, die jemand still eingerichtet hat und die sich nicht steuern lassen, weil niemand sie sieht. Das Gateway-Muster ist bewusst dieselbe Idee, die die Branche für APIs und Identität längst akzeptiert – ein richtliniengesteuerter Eingang –, angewendet auf die neue Realität, dass die Aufrufer jetzt halbautonome Agenten sind und keine von Menschen bedienten Anwendungen.
Warum ist das ein Muster und kein Einzelprodukt?
Dass es sich um einen Architekturwandel und nicht nur um eine Snowflake-Schlagzeile handelt, zeigt der Zeitpunkt. Das Cortex AI Gateway kam nicht allein: Analysten beobachteten im selben Zeitraum eine Häufung von Deals rund um Agenten-Identität, darunter die Übernahme von Oasis durch Cyera für rund 1 Mrd. US-Dollar und die Übernahme von Permiso durch Okta. Snowflake selbst präsentierte zum Start eine Reihe von Identitätspartnern – 1Password, Aembit, Cyera, Okta, SailPoint, Saviynt und weitere. Wenn mehrere große Anbieter innerhalb weniger Tage dieselbe Fähigkeit besetzen, verfestigt sich meist eine Kategorie – nicht weil ein Unternehmen eine clevere Idee hatte.
Was sich verfestigt, ist das MCP-Gateway als horizontale Schicht. Vor einem Jahr wurde das Model Context Protocol vor allem als Weg diskutiert, einen Agenten mit Werkzeugen zu verbinden. Inzwischen geht die Debatte eine Ebene höher: Wenn Agenten ohnehin mit vielen Werkzeugen verbunden werden, wer sitzt dann in der Mitte und setzt Identität, Richtlinien, Audit und Kostenkontrolle durch? Diese mittlere Schicht ist das Gateway, und sie sieht zunehmend weniger wie ein optionales Sicherheitsprodukt aus und mehr wie das Pendant zu einem API-Gateway oder Identity Provider – Infrastruktur, die man bei jeder ernsthaften Agenten-Einführung voraussetzt. Deshalb gilt die Lehre auch für Teams, die nie mit Snowflake arbeiten: Die Form des Stacks pendelt sich ein, und Governance wird darin als eigenständiger Baustein gezeichnet.
Was bedeutet das für Softwareteams in der EU und im DACH-Raum?
Die erste Konsequenz: Agenten-Governance ist eine Frage des Designs, keine Aufräumarbeit. Identität und Audit nachträglich bei Agenten einzuziehen, die bereits Produktivdaten berühren, ist mühsam und selten vollständig. Teams, die das Gateway-Muster früh einbauen – eine eng begrenzte Identität pro Agent, Tool-Aufrufe über einen Richtlinienpunkt, lückenloses Logging –, bekommen Governance fast nebenbei. Wer es aufschiebt, erbt ein unübersichtliches Geflecht direkter Verbindungen, dessen Entflechtung teuer wird.
Die zweite: Das bildet Compliance-Pflichten ab, die Sie ohnehin tragen. Ein Audit-Trail in Echtzeit auf Tool-Aufruf-Ebene ist genau der Nachweis, den Prüfer bei SOC 2 sehen wollen – und ebenso unter DORA und dem EU AI Act, wo Sie zunehmend belegen müssen, wer oder was auf Daten zugegriffen hat und ob die Aktion autorisiert war. Für regulierte Projekte im FinTech- und HealthTech-Umfeld ist ein Agent, der regulierte Daten ohne gesteuerte, widerrufbare Identität lesen kann, eine Kontrolllücke und keine Bequemlichkeit. Mit dem Gateway wird aus der Behauptung „unsere Agenten sind unter Kontrolle“ ein vorzeigbares Artefakt.
Die dritte ist ein Kostenpunkt, der leicht unterschätzt wird: Agenten können schnell Geld ausgeben. Ein Agent, der Aufrufe wiederholt, Sub-Agenten auffächert oder bei einer schwierigen Aufgabe in einer Schleife hängt, kann Token- und Tool-Rechnungen auflaufen lassen, ohne dass ein Mensch im Freigabeweg steht. Budgetgrenzen und Kostensteuerung im Gateway entscheiden darüber, ob Sie das per Alarm bemerken oder erst auf der Rechnung. Ob Sie die Kontrollschicht selbst bauen oder einkaufen – die gewünschte Governance ist dieselbe: Identität, Richtlinien, Audit und Ausgabengrenzen, durchgesetzt an einem Ort, den Ihr Plattform- und DevOps-Team tatsächlich verantwortet.
Was jetzt zu tun ist
Sie müssen in diesem Quartal kein bestimmtes Gateway einführen. Sie sollten aber aufhören, Agenten-Governance als etwas zu behandeln, das man „später ergänzt“. Hier die umsetzbare Version.
- Agenten und Integrationen erfassen. Listen Sie jeden Agenten und jede Werkzeugverbindung auf, auch inoffizielle – Schatten-KI, die Sie nicht sehen, können Sie nicht steuern.
- Jedem Agenten eine eigene Identität geben. Ersetzen Sie geteilte Schlüssel durch eng begrenzte Identitäten mit minimalen Rechten pro Agent, damit Zugriffe zurechenbar und widerrufbar sind.
- Tool-Aufrufe über einen Kontrollpunkt leiten. Schon ein schlankes internes Gateway schlägt ein Dutzend Direktverbindungen; jede Aktion sollte eine Stelle passieren, die sie erlauben, ablehnen und protokollieren kann.
- Audit einschalten und als Compliance-Nachweis behandeln. Führen Sie Logs auf Tool-Aufruf-Ebene und ordnen Sie sie schon jetzt Ihren Pflichten aus SOC 2, DORA, DSGVO und EU AI Act zu – nicht erst zur Prüfung.
- Budgetgrenzen setzen. Legen Sie Budgets und Alarme pro Agent fest, damit ein Agent in einer Schleife ein Limit auslöst statt einer unangenehmen Rechnung.
- Bei neuen Projekten von Anfang an einplanen. Wer früh dran ist, verankert die Governance-Schicht direkt in der Architektur; Nachrüsten kostet ein Vielfaches.
Nichts davon ist ein Urteil über das Cortex AI Gateway im Speziellen; es ist eine starke Umsetzung eines Musters, das schnell zum Standard wird. Die bleibende Erkenntnis ist architektonisch: Während Agenten vom Antworten zum Handeln übergehen, wird der kontrollierte Eingang vor ihnen zur Infrastruktur – und Teams, die ihn jetzt ins Design aufnehmen, müssen später deutlich weniger Aufwand in den Nachweis von Kontrolle stecken.
Häufig gestellte Fragen
Was ist ein MCP-Gateway?
Ein MCP-Gateway ist ein zentraler Kontrollpunkt zwischen KI-Agenten und den Modellen, Daten, Werkzeugen und Servern für das Model Context Protocol (MCP), die sie aufrufen. Statt dass sich jeder Agent mit eigenen Zugangsdaten direkt mit jedem Werkzeug verbindet, laufen alle Aufrufe über das Gateway. Es setzt Identität, Autorisierung, Richtlinien und Audit auf Ebene jedes einzelnen Tool-Aufrufs durch und beantwortet für jede Aktion drei Fragen: Wer hat sie angefordert, welche Rechte hat er, und ist die Aktion erlaubt? Snowflakes Cortex AI Gateway, vorgestellt auf der Black Hat 2026, ist ein prominentes Beispiel und basiert auf der Technik des übernommenen Start-ups Natoma.
Was hat Snowflake auf der Black Hat 2026 angekündigt?
Snowflake hat das Cortex AI Gateway vorgestellt, eine Kontrollschicht dafür, wie KI-Agenten auf Modelle, Daten, MCP-Server und Unternehmenswerkzeuge zugreifen. Sie deckt sowohl Snowflakes eigene Agenten ab als auch Ökosysteme von Drittanbietern wie Amazon Bedrock, Azure AI Foundry, ChatGPT, Claude Code, Cursor sowie eigene Anwendungen auf Basis von LangChain oder LlamaIndex. Zu den Funktionen gehören feingranulare Autorisierung, Audit-Trails in Echtzeit, Unterstützung für mehr als 100 MCP-Server, automatische Erkennung von Schatten-KI und Kostensteuerung mit Budgetgrenzen. Die meisten Funktionen starten als Private Preview; Agenten-Identität und eingeschränkter Sitzungs-Scope sind allgemein verfügbar oder folgen in Kürze. Grundlage ist die Technik des MCP-Gateway-Start-ups Natoma, das Snowflake im Mai 2026 übernommen hat.
Warum brauchen KI-Agenten eine Governance-Schicht?
Weil ein autonomer Agent nicht nur Fragen beantwortet, sondern mit echten Zugangsdaten handelt: Er ruft Werkzeuge auf, liest Daten und stößt Workflows in vielen Systemen an. Ohne zentrales Gateway ist jede Verbindung zwischen Agent und Werkzeug ein eigener, oft nicht protokollierter Pfad mit eigenen Rechten. Dann lässt sich nicht beantworten, wer was getan hat, Zugriffe lassen sich kaum sauber entziehen, und nicht genehmigte Schatten-Agenten entstehen leicht. Ein Governance-Gateway bietet einen einzigen Ort, um Least-Privilege-Zugriffe durchzusetzen, einen Audit-Trail auf Tool-Aufruf-Ebene in Echtzeit zu führen, ausufernde Kosten zu deckeln und gegenüber Prüfern Kontrolle nachzuweisen – etwa nach SOC 2, DORA, DSGVO und EU AI Act.
Betrifft das nur Unternehmen, die Snowflake nutzen?
Nein. Snowflakes Start ist das deutlichste Einzelbeispiel, das Muster ist aber herstellerneutral. In derselben Woche gab es Übernahmen im Bereich Agenten-Identität durch Cyera und Okta, und das Gateway selbst soll auch Agenten außerhalb von Snowflake steuern, die auf Bedrock, Azure AI Foundry, ChatGPT, Cursor, LangChain oder LlamaIndex laufen. Die Lehre ist architektonisch: Wer agentische KI baut oder einkauft, braucht eine Governance-Schicht im Stil eines MCP-Gateways – Identität, Richtlinien, Audit und Kostenkontrolle auf Tool-Aufruf-Ebene – als Standardkomponente, unabhängig von der gewählten Plattform.
Was sollten Engineering-Teams jetzt tun?
Erfassen Sie alle Agenten und Tool-Integrationen, die bereits laufen, auch inoffizielle – was man nicht sieht, kann man nicht steuern. Geben Sie jedem Agenten eine eigene, eng begrenzte Identität mit minimalen Rechten statt geteilter Schlüssel, und leiten Sie Tool-Aufrufe über ein einziges Gateway, damit jede Aktion protokolliert und widerrufbar ist. Ergänzen Sie Budgetgrenzen, um ausufernde Agentenkosten früh zu erkennen, und behandeln Sie den Audit-Trail als Compliance-Nachweis für SOC 2, DORA, DSGVO und EU AI Act. Wer früh dran ist, plant die Governance-Schicht von Anfang an ein, statt sie nachzurüsten, wenn Agenten bereits Produktivdaten berühren.
Quellen
Snowflake — Enterprise AI security and agentic MCP governance with Cortex AI Gateway
VentureBeat — Snowflake launches Cortex AI Gateway to control AI agents and prevent runaway enterprise costs
Yahoo Tech — Snowflake's Cortex AI Gateway signals MCP gateways are crystallizing as infrastructure
Cybersecurity Magazine — Snowflake launches Cortex AI Gateway to govern agentic AI