Datenabfluss von AI-Agenten sperren: Egress-Kontrolle per Network Policy

TL;DR

Ob ein Agent oder eine von Mitarbeitern gebaute KI-App Daten nach außen schicken kann, entscheidet keine Richtlinie, sondern die Network Policy. Der betreibbare Standard auf Kubernetes lautet Default-Deny für ausgehenden Verkehr und eine explizite Allowlist je Namespace. Alles andere, inklusive unbekannter externer Ziele, ist dann technisch unmöglich statt nur verboten.

Warum Egress der kritische Pfad ist

Die meisten Agenten-Risiken enden am Netzwerk: Ein Lauf liest eine interne Datei und schickt sie an einen externen Dienst, eine schnell gebaute App telefoniert an eine fremde API, ein kompromittiertes Package öffnet eine Verbindung nach draußen. Wer den ausgehenden Verkehr kontrolliert, schneidet diese Wege ab, ohne in Inhalte schauen zu müssen. Das ist auch die datenschutzfreundlichste Kontrolle, weil sie Ziele prüft, nicht Personen und nicht Inhalte.

Umsetzung in drei Schritten

Erstens eine Default-Deny-Egress-Policy im Agenten-Namespace, die ausgehenden Verkehr zunächst vollständig sperrt. Zweitens eine Allowlist mit den Zielen, die der Agent wirklich braucht: internes Git, die geprüfte Package-Registry, das AI Gateway und freigegebene interne APIs, jeweils so eng wie möglich per FQDN oder CIDR und Port. Drittens DNS disziplinieren, weil ohne kontrollierte Namensauflösung jede Allowlist löchrig wird; DNS läuft über den Cluster-DNS mit Logging der angefragten Namen. Abweichungen zwischen erteilten Freigaben und tatsächlichen Flows prüfen Sie regelmäßig gegen die Flow-Logs Ihrer CNI, bei Cilium zum Beispiel über Hubble.

Zusammenspiel mit Gateway und Identität

Egress-Kontrolle allein reicht nicht, sie ist eine von drei Sperren. Modell-Aufrufe laufen ausschließlich über das AI Gateway, damit kein Agent mit einem eigenen Schlüssel ein externes Modell direkt anspricht. Die eigene Service-Identität des Agenten begrenzt, was er intern darf, die Network Policy begrenzt, wohin er sprechen darf. Zusammen ergibt das die Eigenschaft, die im Audit zählt: Ein Agent kann nur mit freigegebenen Systemen sprechen, nur mit freigegebenen Rechten handeln und jeder Versuch außerhalb davon ist geloggt und blockiert.

Typische Fehler

Die drei häufigsten Fehler sind eine Allowlist, die aus Bequemlichkeit auf ganze externe Netze zeigt, vergessene DNS-Freigaben, die Schattenwege öffnen, und Ausnahmen ohne Ablaufdatum. Jede Ausnahme bekommt einen Owner und ein Review-Datum, sonst wächst die Liste, bis Default-Deny nur noch auf dem Papier steht. Wie Egress in die Gesamtplattform aus Runtime, Gateway und Monitoring gehört, beschreibt die Übersicht zur AI-Agenten-Plattform auf Kubernetes.

Fazit

Egress-Kontrolle ist die billigste wirksame Agenten-Kontrolle: eine Policy-Haltung statt eines neuen Produkts. Default-Deny, enge Allowlist, DNS im Griff und Flow-Logs als Kontrolle. Damit wird aus der Sorge, wohin Apps und Agenten funken, eine beantwortbare Betriebsfrage.