Netzwerk- und Egress-Beschränkungen

Sicherheitsziel

Netzwerk- und Egress-Beschränkungen begrenzen, welche Ziele, Protokolle, Ports und Netzpfade agentische Komponenten, Tools, Sandboxes und Workloads erreichen können, unabhängig davon, was das Modell beabsichtigt. Beeinflussung des Modells darf keine beliebige Netzreichweite erzeugen.

Ausgehende Verbindungen geschützter Agenten-Workloads sollten standardmäßig verweigert, über durchsetzbare Grenzen vermittelt und auf ausdrücklich konfigurierte Ziele und Protokolle beschränkt sein.

Zuständigkeitsgrenzen

Egress ist keine Data Loss Prevention. Egress entscheidet, wohin Verkehr gehen kann, nicht, was er enthalten darf.

Bedrohungsmodell

Beeinflusstes Modellverhalten, aus direkter Eingabe, Webinhalten, Tool-Ausgaben oder dem Ergebnis eines Sub-Agenten, kann eine Anfrage an ein Ziel vorschlagen, das die Aufgabe nie brauchte: einen externen Upload-Host, eine interne Verwaltungsebene oder einen Infrastrukturdienst. Die Sorge ist, dass die Laufzeitumgebung es tatsächlich erreichen kann.

Ein blockiertes Ziel beweist keine böswillige Absicht. Es zeigt nur, dass der versuchte Pfad außerhalb der aktuellen Netzrichtlinie lag.

Erreichbarkeit ist eine eigene Berechtigung

Ein vorhandenes Tool oder ein autorisierter Tool-Aufruf bedeutet nicht, dass beliebige ausgehende Sockets oder beliebige URLs erlaubt sind. Erreichbarkeit wird je Workload, Zielidentität, Protokoll und Port gewährt und dort geprüft, wo Verbindungen entstehen.

Egress standardmäßig verweigern

Für geschützte Agenten-Workloads wird ausgehender Verkehr verweigert, sofern keine ausdrückliche, eng gefasste und überprüfbare Ausnahme ihn erlaubt. Die Erweiterung SC-7(5) in NIST SP 800-53 Rev. 5 beschreibt, Netzverkehr an verwalteten Schnittstellen standardmäßig zu verweigern und ausnahmsweise zu erlauben; diese Seite überträgt dieses allgemeine Prinzip auf Agenten-Workloads.

Lässt sich die Zielidentität nicht auflösen oder die Richtlinie nicht auswerten, wird in geschützten Abläufen sicher geschlossen.

Maßgebliche Zielfakten

Das maßgebliche Ziel stammt aus vollständig geparsten und aufgelösten Verbindungsfakten der Anwendung: Schema, kanonischer Host oder Dienstidentität, aufgelöste Adresse und Netzklasse, Port und, wenn ein Gateway es durchsetzt, Pfadvorlage oder API-Operation.

Vertrauensmodell

URLs aus Tools, abgerufenen Dokumenten, Webseiten, Nachrichten oder Sub-Agenten bleiben variabler Inhalt. Sie werden nie allein dadurch erreichbar, dass ein vertrauenswürdiger Connector sie zurückgegeben hat.

Zielklassen und Dienstidentitäten

Ziele werden klassifiziert: freigegebene eigene Dienste, freigegebene Dienste Dritter, interne sensible Dienste, reine Infrastrukturnetze und unbekannt. Richtlinien beziehen sich auf Klassen und exakte Dienstidentitäten, nicht auf eine beliebige Zeichenkette in einer Anfrage.

Unbekannte oder nicht klassifizierbare Ziele werden in geschützten Abläufen verweigert.

Anwendungseigene Dienst-IDs statt beliebiger URLs

Generische, vom Modell gesteuerte URL-Abrufer sind riskant: Sie machen jede Zeichenkette im Kontext zu einem möglichen Ziel. Besser sind anwendungseigene Dienstkennungen wie inventory-read, die auf feste Hosts und begrenzte Endpunktvorlagen abgebildet werden. Das Modell wählt eine Dienst-ID und Parameter; die Anwendung baut die Verbindung.

URL-Parsing und Kanonisierung

URLs werden mit einer gepflegten Bibliothek geparst, Host und Port kanonisiert und das Ergebnis mit der Richtlinie verglichen. Reine Regex-Prüfungen der Rohzeichenkette sind fragil. Geprüft wird dieselbe geparste Darstellung, die der Client tatsächlich verwendet, und zwar am letzten Verbindungspunkt, nicht nur in Oberfläche oder Eingabevalidierung.

DNS-Auflösung und Rebinding-feste Durchsetzung

Die DNS-Auflösung darf die Reichweite nicht stillschweigend erweitern. Ein einmal geprüfter Name kann später auf eine andere Adresse auflösen, auch auf eine interne oder Infrastrukturadresse. Die Richtlinie wird auf das tatsächlich aufgelöste Ziel und seine Netzklasse angewendet, idealerweise in einem kontrollierten Resolver, Proxy oder Gateway, der auflöst und verbindet, sodass die geprüfte Adresse die verbundene Adresse ist.

Das OWASP SSRF Prevention Cheat Sheet behandelt dieses Risiko der Zielverwechslung und empfiehlt, alle aufgelösten Adressen zu prüfen. Bei wesentlichen Änderungen der Auflösung wird neu bewertet.

Neubewertung von Weiterleitungen

Jede Weiterleitung ist eine neue Zielentscheidung. Eine zunächst erlaubte URL darf einen späteren Host nicht mit erlauben. Entweder werden automatische Weiterleitungen in Clients abgeschaltet, die sie nicht brauchen, oder Parsing, Auflösung und Richtlinienprüfung laufen für jeden Hop vollständig neu; ein scheiternder Hop wird als REDIRECT_DESTINATION_DENIED erfasst.

Protokoll- und Portbeschränkungen

Beschränkt werden Protokolle und Ports, nicht nur Hostnamen. Ein für HTTPS auf 443 erlaubtes Ziel bedeutet nicht beliebiges TCP oder UDP, andere Ports oder andere Protokolle. Verweigert wird mit PROTOCOL_NOT_ALLOWED oder PORT_NOT_ALLOWED.

TLS und Serveridentität

Die Prüfung von TLS und Serveridentität bleibt auf erlaubten Pfaden verpflichtend. Eine Egress-Richtlinie schaltet die Zertifikatsprüfung nie ab, und eine Identitätsabweichung wird als TLS_IDENTITY_MISMATCH gemeldet statt stillschweigend akzeptiert. Terminiert ein Gateway TLS, übernimmt es die Prüfung gegenüber dem Ziel.

Interne und East-West-Reichweite

Egress gilt an der Grenze des Agenten oder Workloads, nicht nur in Richtung öffentliches Internet. Intern heißt nicht automatisch vertrauenswürdig oder erreichbar. Verwaltungsebenen, sensible Datenbanken, Managementnetze und andere East-West-Dienste, die der Workload nicht braucht, sollten von ihm aus unerreichbar sein.

Loopback, Link-Local, Metadaten und Verwaltungsebenen

Zielklassen wie Loopback und lokale Dienste, Link-Local-Bereiche einschließlich Cloud-Metadatendiensten, private Managementbereiche und andere reine Infrastrukturnetze werden blockiert oder getrennt, sofern ein Workload sie nicht ausdrücklich braucht. Verweigert wird mit NETWORK_CLASS_DENIED. Diese Klassen enthalten oft Zugangsdaten oder Steuerfunktionen, die ein Agent nie berühren sollte.

Vermittelte Egress-Architektur

Ausgehender Verkehr geschützter Workloads läuft über einen Durchsetzungspunkt, der auflöst, entscheidet, verbindet und protokolliert. Möglich sind ein Egress-Proxy oder Gateway, ein Service Mesh oder Sidecar, Host- oder Container-Netzrichtlinien, Cloud-Firewalls oder Sicherheitsrichtlinien oder ein Application Gateway. Entscheidend ist die Eigenschaft, nicht das Produkt: eine zurechenbare Entscheidung je Verbindung, durchgesetzt dort, wo die Verbindung entsteht.

Umgehung per direktem Socket verhindern

Agenten-Laufzeitumgebungen sollten keinen unbeschränkten direkten Socket-Pfad an der vermittelnden Kontrolle vorbei haben. Direkter ausgehender Verkehr wird auf Host-, Container- oder Netzebene blockiert, sodass der Vermittler der einzige Weg ist, und Versuche werden als DIRECT_EGRESS_BYPASS gemeldet. Wo direkter Zugang bewusst nötig ist, wird er ausdrücklich eingegrenzt.

Egress-Richtlinien je Tool und Workload

Jedes Tool und jeder Workload erhält eine eigene, an seine Identität gebundene Richtlinie, damit sich Dokumentabrufer, Bestandsleser und Benachrichtigungsdienst keine breite gemeinsame Freigabeliste teilen. Jede Entscheidung sollte dem Workload, Tool oder der Dienstidentität und, wo möglich, Aufgaben-, Lauf- und Aufruf-IDs zurechenbar sein.

Webhooks, Callbacks und von Tools gelieferte Ziele

Webhook-Ziele, Callback-URLs und Ziele aus Tool-Ausgaben oder API-Antworten sind ebenfalls Ziele. Sie bleiben variabler Inhalt und durchlaufen vor der Nutzung dieselben Schritte aus Parsing, Auflösung und Richtlinienprüfung.

Abgrenzung zur Informationsflusskontrolle

Die Informationsflusskontrolle entscheidet, welche Daten einen Pfad durchqueren dürfen; Egress entscheidet, ob der Pfad existiert. NIST SP 800-53 AC-4 behandelt die Durchsetzung von Informationsflüssen allgemein und dient hier nur dazu, diese Grenze zu markieren. Jede Kontrolle kann unabhängig verweigern.

Abgrenzung zur Agentenautorisierung

Die Agentenautorisierung entscheidet, ob eine vollständig aufgelöste Aktion ausgeführt werden darf. Ein autorisiertes Senden scheitert trotzdem, wenn das Ziel unerreichbar ist, und ein erreichbares Ziel macht eine Aktion nicht autorisiert.

Abgrenzung zu Least Privilege

Least Privilege entscheidet, welche Tools, Zugangsdaten und Netzwerkfähigkeiten ein Workload überhaupt hat. Egress-Beschränkungen setzen den Netzwerkanteil dieses Budgets zum Verbindungszeitpunkt durch, sodass eine nie gewährte Fähigkeit auch durch beeinflusstes Verhalten nicht genutzt werden kann.

Abgrenzung zur Tool-Chain-Analyse

Die Tool-Chain-Analyse kann eine Folge erkennen, die ein neues Ziel einführt. Egress-Beschränkungen treffen die eigentliche Erreichbarkeitsentscheidung an der Netzgrenze. Ein Kettenbefund öffnet nie einen Pfad, und ein erlaubter Pfad hebt nie einen Kettenbefund auf.

Entscheidungs- und Durchsetzungspunkte

Die Entscheidung über Erlauben oder Verweigern ist deterministisch. Ein modellgestützter Klassifikator ist nicht der Entscheidungspunkt für Egress; semantische Risikosignale können eine getrennte Reaktionsrichtlinie speisen, gewähren aber nie Reichweite. Reaktion und Telemetrie können protokollieren, alarmieren, einschränken oder pausieren, und Netzausnahmen werden nie dynamisch durch Modellausgaben gewährt.

Erreichbarkeit, Autorisierung, Flussklassifikation, Provenienz, Kettenbefunde und Ausführungsevidenz bleiben getrennt. Kein zusammengefasster Vertrauenswert.

Telemetrie und Begründungscodes

Beispielhafte Begründungscodes als Engineering-Empfehlung: DESTINATION_NOT_ALLOWED, PROTOCOL_NOT_ALLOWED, PORT_NOT_ALLOWED, NETWORK_CLASS_DENIED, REDIRECT_DESTINATION_DENIED, DESTINATION_UNRESOLVED, DIRECT_EGRESS_BYPASS, TLS_IDENTITY_MISMATCH und POLICY_EXCEPTION_USED. Logs von Vermittler und Workload werden über Aufgaben-, Lauf- und Aufruf-IDs korreliert.

Ausnahmen und Änderungskontrolle

Ausnahmen sind kurzlebig und haben Verantwortliche, Begründung, exakten Umfang und Ablaufdatum. Breite dauerhafte Wildcards sind kein Standard. Richtlinien liegen als überprüfbare, versionierte Konfiguration vor. Entwicklungs- und Produktionsrichtlinien bleiben getrennt, ohne die Produktion aus Bequemlichkeit zu öffnen. Reine Domain- und reine IP-Listen haben beide Grenzen: Geteilte CDN-Adressen machen statische IP-Listen brüchig, und Wildcards oder nutzergesteuerte Subdomains machen breite Hostnamenlisten riskant. Besser sind exakte Dienstidentitäten mit kontrollierter Auflösung.

Durchgespieltes Szenario A: erlaubter eigener Dienst

Ein Tool braucht lesenden HTTPS-Zugriff auf inventory-api.internal.example.test:443, dargestellt durch die Dienst-ID inventory-read. Die Egress-Richtlinie erlaubt genau diesen Dienst und diese Pfadklasse für diesen Workload. Auf Netzwerkebene darf die Verbindung zustande kommen.

Das gewährt nur Netzreichweite. Aktionsautorisierung und Informationsflusskontrolle laufen weiterhin getrennt.

Durchgespieltes Szenario B: externes Upload-Ziel verweigert

Beeinflusstes Modellverhalten schlägt vor, eine Datei an upload.outside.example.test zu senden. Keine freigegebene Dienstidentität passt, daher wird die Reichweite mit DESTINATION_NOT_ALLOWED verweigert. War die Anfrage nur vorgeschlagen, wurde keine Verbindung versucht, und es wird kein Exfiltrationsversuch behauptet.

Durchgespieltes Szenario C: Weiterleitung zu nicht freigegebenem Ziel verweigert

Eine Anfrage an docs.internal.example.test ist erlaubt. Die Antwort leitet auf collector.outside.example.test weiter. Der Weiterleitungs-Hop ist eine neue Zielentscheidung und wird mit REDIRECT_DESTINATION_DENIED verweigert. Die ursprüngliche Erlaubnis gilt nicht weiter.

Durchgespieltes Szenario D: interne Verwaltung und Callback verweigert

Der Workload schlägt vor, admin.internal.example.test zu erreichen, ein internes Verwaltungsziel außerhalb seiner Richtlinie. Es wird mit NETWORK_CLASS_DENIED verweigert, obwohl es intern ist.

Unabhängig davon liefert eine Tool-Antwort eine Callback-URL auf hooks.partner.example.test. Die URL ist variabler Inhalt; sie wird gegen die Richtlinie aufgelöst, hat für diesen Workload keine freigegebene Identität und wird vor der Nutzung verweigert.

Was die Szenarien zeigen und was nicht

Tests und Validierung

Die Tests sind defensiv: Sie prüfen die Richtlinie, keine Techniken zu ihrer Umgehung.

Zum Üben von Egress-Entscheidungen an fiktiven Pfaden eignet sich das Lab Netzwerk- und Egress-Beschränkungen.

Kennzahlen

Das sind operative Messgrößen, kein Sicherheitsnachweis. Sie werden nicht zu einem Wert zusammengefasst.

Häufige Fehler

Checkliste für die Umsetzung

Standards und Quellen

Zur Quellennutzung: NIST SC-7 ist eine allgemeine Leitlinie zum Grenzschutz; SC-7(5) beschreibt, Netzverkehr standardmäßig zu verweigern und ausnahmsweise zu erlauben. Beide sind nicht spezifisch für KI-Agenten. AC-4 dient nur der Abgrenzung zur Informationsflusskontrolle. Das OWASP SSRF Prevention Cheat Sheet ist eine allgemeine Leitlinie für Webanwendungen zu Freigabelisten für Ziele, zur Prüfung aufgelöster Adressen und zum Umgang mit Weiterleitungen, keine agentenspezifische Leitlinie. Die agentische OWASP-Liste liefert Risikokontext zu Tool-Missbrauch; sie definiert diese Kontrolle nicht. LLM01:2026 dient nur als Angriffskontext. Keine der zitierten Quellen definiert "Netzwerk- und Egress-Beschränkungen" als agentenspezifische Kontrolle. Dienst-ID-Schemata, Begründungscodes, Gateway-Designs und Kennzahlen auf dieser Seite sind Engineering-Empfehlungen.

Häufige Fragen