Egress-Allowlist
Schränken Sie ein, wohin der Traffic eines Agenten fließen darf. Datendiebstahl und die Übertragung von Injection-Payloads enden beide in einem ausgehenden Request. Eine Default-Deny-Liste zugelassener Ziele ist daher die Kontrollmaßnahme, die selbst dann noch greift, wenn alle anderen versagt haben.
Definition
Eine Egress-Allowlist ist eine Richtlinie auf Netzwerk- oder Sandbox-Ebene, die ausgehende Requests eines Agenten nur an eine explizit definierte Gruppe von Zielen zulässt und alles andere standardmäßig blockiert. So können selbst bei einer vollständigen Übernahme des Agenten keine Daten an einen vom Angreifer gewählten Endpunkt abfließen.
Problem
Jeder Exfiltrationspfad endet in einem ausgehenden Request. Ein Agent, der beliebige Hosts erreichen kann, kann angewiesen werden, alle gelesenen Daten an eine beliebige Adresse zu senden – und keine Anweisung auf Prompt-Ebene kann das verhindern.
Wann zu verwenden
Nutzen Sie dieses Pattern überall dort, wo ein Agent sowohl nicht vertrauenswürdige Inhalte verarbeitet als auch Netzwerkanfragen stellen kann – sei es beim Abrufen von Seiten, Aufrufen von Tools, Rendern von Bildern oder Ausführen von generiertem Code. Das Pattern ist genau dort am wertvollsten, wo Injections am wahrscheinlichsten sind.
Lösung
Default-Deny. Die Allowlist ist der einzige Ausweg; alles, was nicht explizit aufgeführt ist, wird blockiert. Diese Blockierung wird als Signal protokolliert und nicht einfach als Fehler verschluckt.
Listen Sie die Ziele basierend auf der Aufgabe auf: die APIs, die der Agent aufrufen muss, die Domains, die er abrufen muss, die Registries, aus denen er installieren muss – jeweils mit einem Verantwortlichen und einer schriftlichen Begründung.
Erzwingen Sie dies unterhalb des Agenten. Platzieren Sie die Richtlinie in der Sandbox, im Proxy oder im Netzwerk, niemals im Tool-Code, von dem das Modell abgebracht werden kann. Eine Regel, die der Agent wegdiskutieren kann, ist eine Dokumentation, keine Kontrollmaßnahme.
Schließen Sie die stillen Kanäle. Gerenderte Bild-URLs, Link-Vorschauen, DNS-Abfragen, Webhooks, Fehlerberichterstatter und Paketinstallationen sind alle Egress, und sie alle werden genutzt.
Erlauben Sie Hosts, über die Sie logisch urteilen können. Eine Wildcard für einen Host, der vom Benutzer bereitgestellte Inhalte bereitstellt – ein Raw-File-CDN, eine Paste-Website, ein öffentlicher Objektspeicher –, ist ein offener Kanal im Gewand einer Allowlist.
Leiten Sie die Liste aus Messungen ab und leiten Sie sie erneut ab, wenn sich die Aufgabe ändert. Gehen Sie von dem aus, was der Agent tatsächlich aufruft, nicht von dem, was jemand vermutet.
Komponenten
Vorteile
- Begrenzt die Datenexfiltration selbst nach einer vollständigen Kompromittierung der Logik des Agenten.
- Macht Versuche sichtbar: Ein blockiertes Ziel ist eines der wenigen eindeutigen Angriffssignale, die ein Agenten-Stack erzeugt.
- Modellunabhängig – es funktioniert auch bei Modellwechseln, Prompt-Änderungen und Framework-Migrationen weiterhin.
- Kostengünstig zu erweitern, sobald das Gateway existiert; jeder neue Agent erbt den Durchsetzungspunkt.
Risiken
- Das freigegebene Relay: Ein erlaubter Host, der selbst Daten weiterleitet, macht die Allowlist zu einer reinen Formalität.
- Ausfälle, wenn eine legitime Abhängigkeit den Host wechselt, was unter Zeitdruck Druck erzeugt, die Liste zu erweitern.
- Wildcard-Erosion: Jeder grobe Eintrag, der "vorübergehend" hinzugefügt wird, bleibt dauerhaft bestehen, bis ihn jemand überprüft.
- Durchsetzung auf der falschen Ebene – eine In-Process-Prüfung, die der generierte Code einfach umgehen kann.
Wann nicht zu verwenden
- Vollständig Offline-Agenten, bei denen es keinen Egress einzuschränken gibt und die Kontrollmaßnahme reine Show wäre.
- Wenn das Design bereits genau ein Ziel zulässt, sodass die Allowlist eine Eigenschaft der Architektur ist und keine zusätzlich hinzuzufügende Richtlinie.
- Wenn ein Unternehmens-Proxy bereits dieselbe Richtlinie erzwingt und eine zweite Liste die Zuständigkeit aufteilen würde, ohne eine Einschränkung hinzuzufügen.
Technologien
Beispiele
- Ein Coding-Agent in einem Container, dessen Egress-Richtlinie nur die Paketregistrierung und den internen Git-Host nennt. Eine injizierte Anweisung, das Repository per POST an einen externen Collector zu senden, schlägt auf der Netzwerkesbene fehl und wird als Blockierung erfasst.
- Ein Forschungs-Agent, der weitreichende Abrufe durchführen darf, aber über einen Proxy geleitet wird, der nur GET erlaubt und ausgehende Bodys begrenzt – er kann das Web lesen, hat aber keinen Kanal, um darauf zu schreiben.
- Das für diese Wissensdatenbank veröffentlichte stdio-Paket: Sein einziges ausgehendes Ziel ist der öffentliche Endpunkt, den es per Proxy anspricht, sodass die Allowlist eine Eigenschaft des Designs ist und keine nachträglich überlagerte Richtlinie.
KPIs
- Blockierte Egress-Versuche
- Das Signal, für dessen Erzeugung das Pattern existiert. Ein anhaltender Anstieg ist entweder ein Angriff oder eine Aufgabe, die über ihre Liste hinausgewachsen ist – beides ist wissenswert.
- Größe der Allowlist
- Zugelassene Ziele pro Agentenrolle. Ein Wachstum ohne Löschungen führt dazu, dass die Liste in Richtung "Alles erlauben" verfällt.
- Wildcard-Einträge
- Anzahl grober Einträge. Jeder einzelne ist ein Kanal, über den Sie nicht logisch urteilen können; das Ziel ist null.
- Zeit von der Blockierung bis zur Triage
- Wie lange eine Blockierung wartet, bevor ein Mensch sie ansieht. Eine ungelesene Blockierung ist ein Alarm, den Sie eigentlich nicht haben.
Beobachtete Fehlermuster
- Das freigegebene Relay: Ein zugelassener Host, der alles weiterleitet, was er erhält, sodass die Zielprüfung erfolgreich ist und die Daten dennoch abfließen.
- Wildcard-Erosion: Temporäre grobe Einträge, die den Grund für ihre Hinzufügung überdauern.
- In-Process-Durchsetzung: Die Prüfung findet dort statt, wo der generierte Code ausgeführt wird, sodass der Code sie umgehen kann.
- Stille Blockierungen: Ablehnungen, die als gewöhnliche Netzwerkfehler protokolliert werden, sodass das einzige Signal, das das Pattern erzeugt, niemanden erreicht.
Lessons Learned
- Egress is die letzte Kontrollmaßnahme, die noch funktioniert, nachdem das Modell überzeugt wurde. Bauen Sie sie auf, bevor Sie sie benötigen.
- Leiten Sie die Liste aus dem gemessenen Datenverkehr ab und nicht aus Annahmen. Genau das für die Inbound-Origin-Regel an unserem eigenen MCP-Endpunkt zu tun, führte zu einer Regel, die sich von der unterschied, die wir standardmäßig geschrieben hätten.
- Behandeln Sie eine Blockierung als Alarm, nicht als Fehler. Sie ist das kostengünstigste Angriffssignal im Stack.
- Jede Wildcard ist ein Versprechen, das Sie nicht halten können. Nennen Sie konkrete Hosts, oder akzeptieren Sie, dass Sie keine Allowlist haben.
FAQs
- Ist eine Egress-Allowlist für einen Agenten, der im Web surft, realistisch?
- Ja, wenn Sie eher die Form als die Menge einschränken. Erlauben Sie weitreichenden GET-Datenverkehr über einen Proxy, der Request-Bodys verbietet und die Größe begrenzt: Der Agent kann umfassend lesen, hat aber keinen Kanal, der breit genug ist, um das Gelesene herauszuschreiben.
- Muss DNS auf der Liste stehen?
- Ja. Ein Resolver, den der Agent frei abfragen kann, ist ein Exfiltrationskanal – Daten, die in Subdomain-Abfragen codiert sind, fließen ohne eine einzige HTTP-Anfrage ab. Leiten Sie DNS über dieselbe Richtlinie.
- Wir haben bereits Tools mit dem Prinzip der minimalen Rechtevergabe (Least Privilege). Ist das redundant?
- Nein; sie decken unterschiedliche Hälften ab. Least Privilege begrenzt, was der Agent tun kann, Egress-Kontrolle begrenzt, wohin das bereits Gelesene gelangen kann. Ein Read-Only-Agent mit offenem Egress kann dennoch alles leaken, was er lesen kann.