DNS-Exfiltrationsrisiken in KI-Agenten-Sandboxen

Das DNS-Exfiltrationsrisiko wird relevant, wenn Sandbox-Code vom Angreifer kontrollierte Domänen auflösen oder DNS als ausgehenden Datenkanal nutzen kann. Teams sollten daher DNS-Richtlinien, Protokollierung, Paketabrufpfade und Vorfallsnachweise prüfen, bevor sie eine KI-Agenten-Sandbox mit sensiblen Workflows betrauen.

Warum DNS in Sandbox-Bedrohungsmodellen wichtig ist

KI-Agenten-Sandboxen sind für sinnvolle Autonomie konzipiert. Ein Code-Agent kann Tests ausführen, Pakete installieren, APIs aufrufen, einen Browser starten, Dateien inspizieren und Artefakte erstellen, ohne dass ein Mensch jeden Befehl genehmigt. Diese Flexibilität ist der Grund, warum das Netzwerkverhalten einer eigenen Prüfung bedarf – getrennt von CPU-, Speicher-, Dateisystem- und Prozessisolierung.

DNS erhält oft weniger Aufmerksamkeit als HTTP-Ausgang, da es wie Infrastruktur-Klempnerarbeit wirkt. Anwendungen benötigen Namensauflösung, um APIs, Registries, Webseiten und Update-Endpunkte zu erreichen. Aber DNS ist dennoch ausgehende Kommunikation. Eine Sandbox, die beliebige Domänen auflösen kann, kann Informationen über Abfragenamen preisgeben, mit vom Angreifer kontrollierter Infrastruktur in Kontakt treten oder einen blinden Fleck schaffen, wenn DNS-Verkehr nicht mit derselben Sorgfalt protokolliert wird wie Webanfragen.

Dies ist keine theoretische Kategorie, die speziell für KI-Agenten erfunden wurde. MITRE ATT&CK dokumentiert DNS als Anwendungsschichtprotokoll, das Angreifer für Command-and-Control-Kommunikation nutzen können, und separat wird die Exfiltration über alternative Protokolle dokumentiert, wenn Daten über einen Kanal abfließen, der nicht das Hauptanwendungsprotokoll ist. Für Sandbox-Prüfer ist die Lektion einfach: Behandeln Sie DNS nicht als harmlos, nur weil es kein HTTP-POST ist.

Bei KI-Agenten ergibt sich das Risiko meist aus einer Kette kleiner Berechtigungen und nicht aus einem offensichtlichen Fehler:

Sandbox-Funktion	Warum Teams sie erlauben	DNS-bezogene Frage
Paketinstallation	Agenten fehlende Abhängigkeiten installieren lassen	Welche Registries und Auflösungspfade sind erlaubt?
Webzugriff	Browser-Agenten öffentlichen Kontext sammeln lassen	Kann Code jede Domäne auflösen oder nur genehmigte?
API-Aufrufe	Agenten in App-Backends integrieren lassen	Sind interne Domänen und Metadaten-Endpunkte blockiert?
Build-Tools	Code-Agenten realistische Tests ausführen lassen	Können Post-Install-Skripte unerwartete Lookups auslösen?
Lang laufende Sitzungen	Agenten mehrstufige Aufgaben fortsetzen lassen	Werden DNS-Protokolle über den gesamten Sitzungslebenszyklus aufbewahrt?

Das Ziel ist nicht, jeden Netzwerkaufruf zu verbieten. Viele Agenten-Workloads benötigen kontrollierten Netzwerkzugriff. Das Ziel ist zu wissen, welche Pfade existieren, welche blockiert sind und welche Nachweise Sie hätten, wenn sich eine Aufgabe unerwartet verhält.

Wo DNS-Auflösung in Agenten-Workflows auftritt

Sicherheitsüberprüfungen fragen oft, ob eine Sandbox Internetzugang hat. Diese Frage ist zu allgemein. Eine bessere Überprüfung beginnt damit, jede Stelle zu kartieren, an der Code, Tools, Paketmanager oder Browser eine Namensauflösung auslösen können.

Häufige DNS-Pfade umfassen:

• Direkte Code-Anfragen aus Python, JavaScript, Shell-Skripten, SDKs und Test-Suiten.
• Browser-Automatisierung, die Seiten, Unterressourcen, Schriftarten, Bilder, Analytics-Skripte und Weiterleitungen lädt.
• Paketmanager wie npm, pip, uv, pnpm, apt, cargo oder sprachspezifische Plugin-Installer.
• Build-Tools, die Binärdateien, Vorlagen, Browser-Treiber, Modelldateien oder Test-Fixtures abrufen.
• Agenten-Tools, die Drittanbieter-APIs oder Webhook-Endpunkte aufrufen.
• Hintergrundjobs, die weiterlaufen, nachdem der sichtbare Agentenschritt zurückgekehrt ist.

Diese Kartierung sollte sowohl beabsichtigten als auch beiläufigen Verkehr umfassen. Ein Entwickler bittet einen Agenten möglicherweise nur, einen Unit-Test auszuführen, aber der Testbefehl installiert möglicherweise ein Paket, der Paketmanager löst eine Registry-Domäne auf und ein Lebenszyklus-Skript kontaktiert einen separaten Host. Eine Browser-Aufgabe kann auf eine öffentliche Website beschränkt sein, während eingebettete Ressourcen viele zusätzliche Domänen auflösen.

Für einen Sandbox-Anbieter ist die stärkste Antwort nicht nur „Netzwerkzugriff ist verfügbar“ oder „Netzwerkzugriff ist isoliert“. Die nützliche Antwort erklärt den Auflösungspfad:

• Verwendet das Sandbox-DNS einen anbietergesteuerten Resolver, einen kundengesteuerten Resolver, einen VPC-Resolver oder einen öffentlichen Resolver?
• Kann der Kunde Domänen, IP-Bereiche, Ports oder Protokolle einschränken?
• Werden DNS-Anfragen pro Sandbox, pro Sitzung, pro Befehl oder nur auf einer aggregierten Netzwerkebene protokolliert?
• Werden abgelehnte Lookups protokolliert oder nur erlaubte?
• Können Kunden den Paketabruf-DNS vom Laufzeit-DNS trennen?

Wenn diese Details nicht verfügbar sind, behandeln Sie sie als offene Bewertungspunkte, nicht als Beweis dafür, dass die Sandbox unsicher ist. Das praktische Risiko hängt von der Sensitivität der Arbeitslast, den in der Sandbox verfügbaren Geheimnissen, der Ausgangsrichtlinie und der Qualität der forensischen Beweise ab.

So bewerten Sie die Ausgangsrichtlinie

Die Ausgangsrichtlinie ist die Kontrollfläche, die entscheidet, ob DNS zur Routine-Klempnerarbeit oder zu einem ungeprüften Fluchtweg wird. Eine ausgereifte Richtlinie sollte drei Fragen beantworten: Was ist erlaubt, warum ist es erlaubt und wie werden Ausnahmen genehmigt.

Beginnen Sie mit der Standardhaltung. Eine Sandbox, die für nicht vertrauenswürdigen KI-generierten Code verwendet wird, sollte nicht denselben breiten Netzwerkzugriff erben wie ein Entwickler-Laptop. Wenn der Standard offener Ausgang ist, fragen Sie, ob das Produkt eine Einschränkung dieses Zugriffs für risikoreichere Arbeitslasten unterstützt. Wenn der Standard eingeschränkter Ausgang ist, fragen Sie, wie Entwickler die genauen Domänen aktivieren, die für eine Aufgabe benötigt werden.

Trennen Sie dann die DNS-Richtlinie von der HTTP-Richtlinie. Einige Systeme erzwingen HTTP-Allowlists, lassen aber die Namensauflösung breit. Das kann eine Diskrepanz verursachen: Eine Anfrage an einen nicht genehmigten Host kann auf der HTTP-Ebene fehlschlagen, dennoch verlässt die DNS-Abfrage die Umgebung und kann Metadaten im abgefragten Namen tragen. Ein strengeres Design bewertet Auflösungs- und Verbindungsversuche gemeinsam.

Verwenden Sie für Sicherheitsüberprüfungen eine Richtlinienmatrix wie diese:

Bewertungsbereich	Was zu fragen ist	Stärkere Nachweise
Standard-Ausgang	Ist der ausgehende Netzwerkzugriff offen, verweigert oder nach Vorlage eingeschränkt?	Schriftliche Standardrichtlinie plus Sandbox-Level-Testergebnis
DNS-Resolver-Pfad	Welcher Resolver bearbeitet Sandbox-DNS?	Architekturdiagramm oder Konfigurationsnachweis
Domänen-Allowlists	Können Teams nur genehmigte Registries und APIs erlauben?	Konfigurationsbeispiel und Ablehnungsprotokollbeispiel
IP- und private Netzwerkblöcke	Sind interne Bereiche und Metadaten-Dienste standardmäßig blockiert?	Dokumentierte Ablehnungsregeln und Testnachweise
Protokollkontrollen	Werden DNS, HTTP, HTTPS und Raw-Sockets separat kontrolliert?	Richtlinienmodell, nicht nur Marketingaussagen
Ausnahmeworkflow	Wer kann Domänen hinzufügen oder Richtlinien lockern?	Rollenbasierte Genehmigung und Prüfprotokoll

Für die meisten Teams ist das erste praktische Ziel keine perfekte Null-Ausgang-Umgebung. Es ist ein dokumentiertes Minimal-Ausgangsprofil: genehmigte Paketregistries, genehmigte API-Domänen, kein Zugriff auf interne Netzwerke, es sei denn, explizit geroutet, und Protokolle sowohl für erlaubte als auch für abgelehnte Versuche.

Paketabrufe und abhängigkeitsgesteuertes DNS

Die Paketinstallation ist eine der einfachsten Möglichkeiten, den Sandbox-Ausgang zu unterschätzen. Von Agenten generierter Code schlägt oft aufgrund fehlender Abhängigkeiten fehl, und die schnellste Entwicklererfahrung besteht darin, den Agenten installieren zu lassen, was er braucht. Diese Bequemlichkeit schafft ein zweites Supply-Chain-Problem: Paketnamen, Registry-Weiterleitungen, Installationsskripte und Binärdatei-Downloads können DNS- und Netzwerkaktivitäten auslösen, die die ursprüngliche Eingabeaufforderung nie erwähnt hat.

OWASP’s LLM-Anwendungsleitfaden weist auf Risiken im Zusammenhang mit übermäßiger Agentur und Supply-Chain-Exposition hin. In Agenten-Sandboxen treffen diese Risiken bei der Paketinstallation aufeinander. Ein Modell darf möglicherweise Befehle auswählen. Ein Befehl ruft möglicherweise einen Paketmanager auf. Der Paketmanager ruft möglicherweise Code von einer Registry ab. Das abgerufene Paket führt möglicherweise Installations-Hooks aus. Jeder Schritt kann DNS-Lookups und ausgehende Verbindungen erzeugen.

Die defensive Bewertung sollte sich auf Governance konzentrieren, nicht auf Exploit-Mechanismen:

• Bevorzugen Sie fixierte Abhängigkeitsdateien für wiederholbare Agentenaufgaben.
• Verwenden Sie genehmigte Registries oder Pull-Through-Caches für gängige Ökosysteme.
• Protokollieren Sie Paketname, Version, Registry-URL, aufgelöste Domänen und Artefakt-Hashes, wo praktikabel.
• Trennen Sie die Paketinstallationsberechtigung vom allgemeinen Laufzeit-Internetzugriff.
• Fordern Sie eine Genehmigung an, bevor Pakete außerhalb einer Allowlist für sensible Arbeitsbereiche installiert werden.
• Erwägen Sie vorgefertigte Sandbox-Vorlagen für gängige Stacks, damit Agenten während jedes Laufs keinen breiten Netzwerkzugriff benötigen.

Die wichtige Unterscheidung ist, dass „Paketabruf“ nicht eine Kontrolle ist. Es umfasst DNS-Auflösung, Registry-Authentifizierung, Artefakt-Download, Installationszeit-Codeausführung und Cache-Verhalten. Eine gute Sandbox-Prüfung fragt nach dem gesamten Pfad.

Geheimnisse und Annahmen zur Datenexposition

DNS-Exfiltration ist nur relevant, wenn es etwas Sinnvolles zu leaken gibt. Das macht die Platzierung von Geheimnissen und die Datenabgrenzung zu einem Teil der DNS-Prüfung.

KI-Agenten-Sandboxen sollten wie nicht vertrauenswürdige Build-Worker behandelt werden, sofern nicht das Gegenteil bewiesen ist. Platzieren Sie keine langlebigen Produktionsanmeldeinformationen, breite Cloud-Tokens, Kundendaten oder internen Quellcode in einer Sandbox, nur weil die Sandbox vom Host isoliert ist. Isolierung reduziert die Explosionsradius, macht aber nicht jeden Befehl sicher.

Verwenden Sie diese Annahmen beim Entwerfen von risikoreicheren Workflows:

• Jede Datei, die von agentenausgeführtem Code gelesen werden kann, könnte in Protokolle, Ausgaben, Netzwerkanfragen oder Fehlermeldungen aufgenommen werden.
• Jede Umgebungsvariable, die für einen Prozess sichtbar ist, könnte von diesem Prozess kopiert werden.
• Jeder ausgehende Kanal, der der Sandbox erlaubt ist, verdient die gleiche Datenverlustprüfung, einschließlich DNS.
• Jede prompt-injizierte Anweisung in einem Browser- oder Dokumenten-Workflow könnte versuchen, die Werkzeugnutzung zu beeinflussen.
• Jede langlebige Sitzung erhöht den Wert von Lebenszyklusprotokollen und Token-Ablauf.

Praktische Kontrollen umfassen kurzlebige Anmeldeinformationen, API-Schlüssel mit minimalen Berechtigungen, eingeschränkte Dienstkonten, Geheimnisse pro Aufgabe, bereinigte Protokolle und eine explizite Trennung zwischen Forschungsaufgaben mit öffentlichen Daten und Aufgaben mit sensibler Codeausführung.

Protokolle, Prüfpfade und Vorfallsnachweise

DNS-Kontrollen sind nur nützlich, wenn Teams sie überprüfen können. Wenn eine Sandbox-Aufgabe verdächtig ist, benötigen Sicherheitsteams schnell Nachweise: Was wurde ausgeführt, was wurde aufgelöst, was wurde verbunden, welche Dateien wurden geändert und welche Ausgaben wurden zurückgegeben.

Fragen Sie mindestens, ob die Plattform diese Ereignisse für eine bestimmte Sandbox-Sitzung rekonstruieren kann:

• Zeitpunkt der Sandbox-Erstellung, Vorlage, Ressourcenkonfiguration und Eigentümer.
• Vom Agenten oder Benutzer ausgeführte Befehle.
• Gelesene, geschriebene, hochgeladene oder heruntergeladene Dateien, wenn das Produkt Dateioperationen verfügbar macht.
• Paketinstallationen und Registry-Abrufe.
• DNS-Abfragen, einschließlich Zeitstempel, abgefragter Name, Ergebnis und Sandbox-/Sitzungskennung.
• Ausgehende Verbindungsversuche, einschließlich Zielhost, IP, Port, Protokoll, Ergebnis (erlaubt/verweigert) und Volumen, falls verfügbar.
• Tool-Aufrufe, Browser-Navigationsereignisse und Hintergrundprozesse.
• Geheimnisinjektionsereignisse, ohne die Geheimniswerte in Protokollen offenzulegen.
• Sitzungsbeendigung, Pause, Fortsetzung, Snapshot- und Bereinigungsereignisse.

Fragen Sie nicht nur nach Protokollen erfolgreichen Verkehrs. Abgelehnte Ereignisse sind oft nützlicher, um zu bewerten, ob die Richtlinie funktioniert hat. Wenn eine Sandbox versucht, eine nicht genehmigte Domäne aufzulösen, und die Richtlinie blockiert sie, dann ist dieser abgelehnte Lookup der Nachweis, der eine funktionierende Kontrolle von einem stillen Fehler trennt.

Auch die Aufbewahrung ist wichtig. Ein siebentägiges Protokollfenster mag für das Debugging ausreichen, ist aber für die Incident-Response schwach. Teams mit regulierten oder kundensensiblen Arbeitslasten sollten die Aufbewahrung von Sandbox-Telemetrie an ihre umfassendere Sicherheitsprotokollierungsrichtlinie anpassen.

Novita Agent Sandbox Bewertungshinweise

Novita Agent Sandbox ist für KI-Agenten-Workflows konzipiert, die isolierte Codeausführung, Browser-Automatisierung, Computer-Use-ähnliche Aufgaben, langlebige Sitzungen und Evaluierungs- oder Reinforcement-Learning-Arbeitslasten benötigen. Die Novita Agent Sandbox Übersicht ist der richtige Ausgangspunkt für das aktuelle Produktverhalten, und die Agent Sandbox Produktseite beschreibt die breitere Plattformpassung.

Wenn Sie Novita oder einen anderen Sandbox-Anbieter für DNS-sensitive Arbeitslasten bewerten, trennen Sie zwei Arten von Aussagen:

• Produktpassung: ob die Sandbox den von Ihnen benötigten Agenten-Workflow unterstützt, z. B. Codeausführung, Browser-Automatisierung oder langlebige Aufgaben.
• Sicherheitskontrollnachweise: ob die genauen DNS-, Ausgangs-, Paketabruf-, Geheimnis- und Protokollkontrollen Ihrer internen Richtlinie entsprechen.

Diese Trennung verhindert Übertreibungen. Eine Sandbox kann eine starke Passung für die Agentenausführung sein und dennoch eine spezifische Kundenprüfung für DNS-Richtlinien, Resolver-Pfad, Allowlists, Audit-Aufbewahrung und Incident-Workflows erfordern. Sicherheitsteams sollten vor der Genehmigung sensibler Arbeitslasten aktuelle Dokumentation oder Produktbestätigung für diese Kontrolldetails anfordern.

Für Teams, die bereits Novita AI-Modelle verwenden, besteht die Plattformpassung darin, dass Modell-APIs und Agentenausführungsinfrastruktur gemeinsam bewertet werden können. Das kann den Betriebsaufwand reduzieren, ersetzt aber nicht die Notwendigkeit eines Bedrohungsmodells. Behandeln Sie die Sandbox als kontrollierte Ausführungsumgebung, definieren Sie, welchen Netzwerkzugriff jede Agentenklasse benötigt, und validieren Sie, dass die Kontrollnachweise mit dem Risiko der darin platzierten Daten übereinstimmen.

Sicherheitscheckliste

Verwenden Sie diese Checkliste, bevor Sie KI-Agenten-Sandbox-Workloads genehmigen, die sensible Code, Anmeldeinformationen, Kundendaten oder interne Systeme betreffen können.

Prüffrage	Warum es wichtig ist
Was kann die Sandbox standardmäßig auflösen?	DNS kann ein ausgehendes Signal sein, selbst wenn HTTP blockiert ist.
Kann DNS nach Domäne, Vorlage, Arbeitsbereich oder VPC-Richtlinie eingeschränkt werden?	Sensible Workflows benötigen engere Standardeinstellungen als öffentliche Forschungsaufgaben.
Werden DNS-Abfragen pro Sandbox-Sitzung protokolliert?	Incident-Response benötigt Attribution, nicht nur aggregierte Resolver-Metriken.
Werden abgelehnte DNS- und Verbindungsversuche protokolliert?	Abgelehnte Ereignisse beweisen, dass die Richtlinie unerwartetes Verhalten blockiert hat.
Sind Paketregistries auf einer Allowlist oder werden sie über einen Proxy bereitgestellt?	Paketmanager können abhängigkeitsgesteuertes DNS und Downloads auslösen.
Können Paketinstallationen vom Laufzeit-Netzwerkzugriff getrennt werden?	Build-Zeit- und Laufzeit-Risiko sind unterschiedlich.
Sind interne IP-Bereiche und Metadaten-Endpunkte blockiert?	Agenten sollten nicht versehentlich Infrastruktur-Kontrollebenen entdecken oder kontaktieren.
Wie werden Geheimnisse injiziert, eingegrenzt, rotiert und bereinigt?	Die DNS-Prüfung ist unvollständig, wenn langlebige Geheimnisse für Sandbox-Code verfügbar sind.
Sind Browser-Unterressourcen in Protokollen sichtbar?	Browser-Agenten können mehr Domänen auflösen als die URL der obersten Ebene.
Welche Nachweise sind nach Pause, Fortsetzung, Snapshot oder Bereinigung verfügbar?	Langlebige Sitzungen benötigen lebenszyklusbewusste Telemetrie.
Wer kann die Ausgangsrichtlinie lockern?	Ausnahmeänderungen sollten prüfbar sein.
Wie werden verdächtige Sitzungen aufbewahrt?	Die Bereinigung sollte nicht die einzigen nützlichen Vorfallsnachweise löschen.

Wenn mehrere Antworten unbekannt sind, halten Sie die Arbeitslast aus der Sandbox heraus, bis der Anbieter oder das interne Plattformteam den Kontrollpfad dokumentieren kann. Wenn die Arbeitslast nur öffentliche Daten verarbeitet und keine Geheimnisse verwendet, können dieselben Lücken während des frühen Prototypings akzeptabel sein, sollten aber vor dem Produktionseinsatz dennoch nachverfolgt werden.

Fazit

Überprüfen Sie für Produktions-Agenten-Sandboxen DNS als Teil des Ausgangs, nicht als Fußnote. Das minimal vertretbare Setup ist eine eingeschränkte Ausgangsrichtlinie, explizite Paketabruf-Governance, kurzlebige Geheimnisse, DNS- und Verbindungsprotokolle pro Sitzung und ein getesteter Incident-Workflow zur Aufbewahrung von Beweisen.

Verwenden Sie breiteren Netzwerkzugriff nur für risikoarme Prototypen, wenn die Daten nicht sensibel sind und der Agent keine bedeutenden Geheimnisse hat. Für sensible Codebasen, Kundendaten, interne APIs oder regulierte Workflows verlangen Sie ein Minimal-Ausgangsprofil und aktuelle Anbieternachweise, bevor Sie Agenten autonome Ausführung gewähren.

FAQ

Ist DNS-Exfiltration relevant, wenn die Sandbox HTTP blockiert?

Ja. HTTP-Kontrollen und DNS-Kontrollen sind unterschiedliche Ebenen. Eine Sandbox kann ausgehende Webanfragen blockieren, während sie DNS-Abfragen dennoch erlaubt. Sicherheitsteams sollten sowohl die Auflösungsrichtlinie als auch die Verbindungsrichtlinie überprüfen.

Sollten KI-Agenten-Sandboxen keinen Internetzugang haben?

Nicht immer. Viele nützliche Agentenaufgaben benötigen Paketregistries, öffentliche Dokumentation, APIs oder Browserzugriff. Das sicherere Ziel ist ein minimaler, erklärbarer Ausgang: Erlauben, was die Aufgabe benötigt, verweigern, was sie nicht benötigt, und sowohl erlaubte als auch abgelehnte Aktivitäten protokollieren.

Sind Paketinstallationen dasselbe wie allgemeiner Netzwerkzugriff?

Nein. Paketinstallationen verdienen eine separate Richtlinie, da sie Registries, Abhängigkeitsauflösung, Artefakt-Downloads und manchmal Installationsskripte umfassen. Ein Team kann Paketabrufe über einen genehmigten Cache erlauben, während es beliebigen Laufzeit-Ausgang verweigert.

Welche Protokolle sind für das DNS-Risiko am wichtigsten?

Die nützlichsten Protokolle verbinden eine DNS-Abfrage mit einer bestimmten Sandbox, einem Befehl, einer Zeit, einem Benutzer oder Agenten-Workflow und einer Richtlinienentscheidung. Abgelehnte Lookup-Protokolle sind besonders wichtig, da sie zeigen, ob die Kontrolle tatsächlich funktioniert hat.

Kann ein Sandbox-Anbieter garantieren, dass keine Datenexfiltration stattfindet?

Seien Sie vorsichtig mit absoluten Garantien. Ein Anbieter kann Isolierung, Netzwerkkontrollen, Protokollierung und Konfigurationsoptionen anbieten, aber das endgültige Risiko hängt vom Workload-Design, Geheimnissen, Datenplatzierung, Ausgangsrichtlinie und Betriebsüberwachung ab.

Empfohlene Artikel

• Wie Agent-Sandboxen sichere, skalierbare KI-Innovation ermöglichen
• Erstellen eines Code-Agenten mit Novita’s Agent Sandbox
• Erstellen eines Remote-Code-Execution-MCP-Servers mit Novita Sandbox und der mcp-use-Bibliothek