KI-Gateways sind jetzt kritische Infrastruktur. Behandeln Sie sie auch so.
Ihr KI-Gateway mag wie eine technische Infrastruktur wirken. Tatsächlich wird es zu einem der privilegiertesten Systeme im Unternehmen.
Das Gateway leitet Eingaben an Modelle weiter, speichert oder ruft Anbieteranmeldedaten ab, wendet Nutzungsrichtlinien an, verbindet Anwendungen mit Abrufsystemen und hält oft die Konfiguration, die bestimmt, welches Modell auf welche Daten zugreifen darf. Damit ist es eine Steuerungsebene, keine Komfortschicht.
Ein aktueller Microsoft Threat Intelligence-Bericht macht das Problem deutlich. Bei Untersuchungen kompromittierter LiteLLM-, RAGFlow- und Kestra-Umgebungen verfolgten Angreifer dasselbe Ziel: Anmeldedaten, Persistenz und Zugriff auf Systeme hinter der KI-Arbeitslast. Im LiteLLM-Fall beobachtete Microsoft das Abgreifen von Anmeldedaten aus dem Gateway-Laufzeitprozess, das Sammeln aus einer unterstützenden Datenbank und Persistenzaktivitäten. Dies ist keine Geschichte über ein Modell mit falscher Antwort, sondern über einen KI-Dienst als Unternehmens-Brückenkopf.
Für Sicherheitsverantwortliche bedeutet das: Die Organisation kann KI-Agenten nicht nur auf der Eingabe-, Modell- oder Benutzerebene steuern. Sie muss auch die Infrastruktur kontrollieren, die diese Ebenen verbindet.
Warum das Gateway zur Schwachstelle wurde
Traditionelle Anwendungsarchitektur verteilt Vertrauen auf Dienste. KI-Architektur komprimiert es oft.
Ein Gateway oder Orchestrierungslayer kann Modellanbieter-Schlüssel, Mandanten-Routingregeln, virtuelle Schlüssel, Datenbankverbindungszeichenfolgen, Tool-Anmeldedaten und Beobachtungsdaten in einer Laufzeit vereinen. Eine Abrufplattform kann interne Dokumente sehen und Zugriff auf Datenspeicher einbetten. Ein Workflow-System kann Code, Container oder SaaS-Aktionen auslösen. Jede Komponente ist isoliert verteidigbar. Zusammen bilden sie einen hochsensiblen operativen Engpass.
Deshalb lautet die wichtige Sicherheitsfrage nicht mehr „Ist unser Modell genehmigt?“, sondern „Was kann ein Kompromiss der KI-Steuerungsebene erreichen?"
Wenn die Antwort Produktionsdaten, privilegierte SaaS-Aktionen, wiederverwendbare Anbieter-Schlüssel oder andere Systemgeheimnisse einschließt, verdient das Gateway dieselbe technische Disziplin wie ein Identitätsanbieter, eine API-Management-Schicht oder eine Produktionsbereitstellungsplattform.
Der Fehler: KI-Infrastruktur als Entwicklerwerkzeug behandeln
Viele Unternehmen setzen KI-Infrastruktur noch über den Entwickler-Erfahrungsweg ein: schnelle Evaluierung, ein gemeinsamer API-Schlüssel, ein öffentlicher Verwaltungspunkt zur Bequemlichkeit, dann eine Produktionsarbeitslast darum herum. Die Kontrollen reifen meist später, wenn das System nützlich wird.
Diese Reihenfolge ist nachvollziehbar. Sie ist aber falsch herum.
Eine exponierte Admin-Oberfläche bei einem herkömmlichen internen Tool ist ein Problem. Eine exponierte Admin-Oberfläche bei einem KI-Gateway kann ein Multiplikator sein: Sie kann Zugriff auf mehrere Modelle, Anwendungen, Datenbanken und die Richtliniendatensätze, die sie verbinden, freigeben. Ein gestohlener Modellanbieter-Schlüssel ist nicht nur ein Abrechnungsproblem, wenn er genutzt werden kann, um einen genehmigten Dienst zu imitieren oder einen Anbieterendpunkt außerhalb des erwarteten Pfads zu erreichen.
Hier taucht Shadow-KI in technischerer Form wieder auf. Das nicht genehmigte Tool ist nicht immer ein Browser-Tab. Es kann ein kleines Gateway, ein Abrufserver oder ein Orchestrierungsworkflow sein, den ein fähiges Team für eine interne Funktion zusammenstellt. Die Sicherheit kennt vielleicht den Modellanbieter, aber nicht die Steuerungspunkte, die das Modell betriebsbereit machen.
Drei Kontrollen, die unverhandelbar sein sollten
1. Inventarisieren Sie die Steuerungsebene, nicht nur die Modelle
Ihr KI-Inventar sollte jedes Gateway, jede Abrufplattform, jede Agenten-Laufzeit, jeden Orchestrierungsdienst, jeden Plugin-Server und jede Workflow-Engine umfassen. Für jede Komponente erfassen Sie Eigentümer, Umgebung, Internet-Exposition, Datenquellen, Modellanbieter, gehaltene Anmeldedaten und Aktionen, die sie auslösen kann.
Geben Sie sich nicht mit einer Tabelle genehmigter Modellnamen zufrieden. Diese Liste kann nicht beantworten, ob ein vergessenes Test-Gateway einen Produktionsschlüssel hat oder ob ein Abrufdienst auf einen sensiblen Dokumentenspeicher zugreifen kann.
Beginnen Sie mit Beweisen: Cloud-Ressourcen, Container-Registries, Kubernetes-Namespaces, DNS-Einträgen, Quellcode-Repositories, Identitätsprotokollen und Netzwerk-Telemetrie. Ziel ist eine lebendige Karte der Systeme, die KI-Arbeit weiterleiten oder ausführen.
2. Machen Sie Anmeldedaten eng gefasst, kurzlebig und trennbar
Ein Gateway sollte keinen einzigen dauerhaften Anmeldedaten-Schlüssel benötigen, der alles kann. Trennen Sie Anbieterzugriff von Datenbankzugriff, Lesepfade von Administrationspfaden und verwenden Sie wo möglich eingeschränkte Identitäten. Rotieren Sie Anmeldedaten und stellen Sie sicher, dass ein kompromittiertes Gateway nicht unbemerkt breiteren Zugriff erzeugen kann.
Das ist besonders wichtig für agentenbasierte Workflows. Ein Agent, der Tools aufrufen kann, benötigt eine eigene eingeschränkte Identität und eine explizite Aktionsgrenze. Lassen Sie nicht zu, dass ein gemeinsamer Service Principal zur universellen Berechtigung für jeden Agenten wird, mit dem ein Team experimentiert.
Der praktische Test ist klar: Wenn heute ein Gateway-Container kompromittiert wird, welche Geheimnisse kann er lesen und was können diese Geheimnisse morgen bewirken? Wenn die Antwort unklar ist, ist das Zugriffskonzept nicht ausgereift.
3. Überwachen Sie KI-Infrastruktur als Ausführungsumgebung
Das Protokollieren von Eingaben ist nützlich, reicht aber nicht aus. Sicherheitsteams benötigen Telemetrie, die ungewöhnliche Prozessstarts, Geheimniszugriffe, ausgehenden Datenverkehr, Änderungen an Modellrouten, Erstellung virtueller Schlüssel und anomale Tool-Aufrufe vom Gateway und Orchestrierungslayer zeigt.
Die von Microsoft beobachteten Aktivitäten sind ein hilfreiches Modell für Erkennungen: vom Gateway ausgehende Shell- oder Python-Ausführungen, Lesen von Prozessumgebungsvariablen, Datenbankzugriffe außerhalb des normalen Anwendungsverhaltens, Änderungen an Service-Konto-Schlüsseln und unerwarteter Datenabfluss sollten alle hochsignifikante Ereignisse sein.
Der Eigentümer der KI-Plattform sollte drei Fragen schnell beantworten können: Was hat sich geändert, wer hat es genehmigt und was wurde erreicht? Wenn ein Incident-Response-Team diese Antworten nicht rekonstruieren kann, ist Governance theoretisch.
Governance ist das Betriebsmodell, das Kontrollen lebendig hält
Eine Richtlinie, die „genehmigte KI verwenden“ sagt, schützt kein unkontrolliertes Gateway. Die Richtlinie muss mit einem Weg verbunden sein, der sichere Bereitstellung einfacher macht als nicht genehmigte.
Das bedeutet eine schlanke Aufnahme neuer KI-Dienste, wiederverwendbare sichere Bereitstellungsmuster, einen benannten Verantwortlichen für jede Arbeitslast und Überprüfungen bei Änderungen der Datensensitivität oder Agentenberechtigungen. Es bedeutet auch, der Sicherheit eine Möglichkeit zu geben, KI-Nutzung zu entdecken, ohne jedes Experiment zu einer monatelangen Genehmigungsschleife zu machen.
Das Ziel ist nicht, Teams am Bauen zu hindern. Es ist, zu verhindern, dass kritisches Vertrauen in Systemen wächst, die niemand sehen oder verteidigen kann.
Die Unternehmen, die das gut handhaben, behandeln KI-Infrastruktur als erstklassige Infrastruktur. Sie wissen, wo die Steuerungsebenen sind, minimieren die Autorität jeder einzelnen und überwachen sie mit derselben Ernsthaftigkeit wie Identität und Produktions-APIs.
Das ist die operative Definition von KI-Governance: nicht eine Sammlung von Absichten zu verantwortungsvoller KI, sondern die Fähigkeit zu beweisen, welche Systeme auf Daten zugreifen, Aktionen ausführen und Regeln ändern können.
Aona hilft Sicherheitsteams, die KI-Systeme im Unternehmen zu entdecken, deren Daten- und Zugriffsrisiken zu verstehen und Governance um die Tools zu legen, die Mitarbeiter und Teams bereits nutzen. Wenn Ihr KI-Inventar bei Modellnamen endet, ist es Zeit, die Steuerungsebene zu erfassen.
