IronProxy hält echte Zugangsdaten aus Agenten-Sandboxes heraus

Der gefährliche Moment beginnt nicht mit einem spektakulären Angriff, sondern mit einem gewöhnlichen Paket-Download. Ein Coding-Agent führt fremden Code aus, der Container enthält einen echten API-Schlüssel, und plötzlich kann eine manipulierte Abhängigkeit das Secret lesen und an einen beliebigen Server schicken.

IronProxy verändert diese Ausgangslage: Die Sandbox sieht nur ein Ersatz-Token, ausgehende Ziele brauchen eine Freigabe, und erst an der Netzgrenze wird das echte Secret eingesetzt. Damit wird aus der Frage „Ist der Container isoliert?“ eine strengere Frage: Welche Verbindung darf ihn verlassen, und welche Zugangsdaten sind dort überhaupt verwertbar?

Zwei Kontrollen, eine Sicherheitsentscheidung

IronProxy kombiniert einen Egress-Proxy mit einem integrierten DNS-Server. Ausgehende Verbindungen sind zunächst gesperrt und müssen über Regeln für Domains oder Netzbereiche freigegeben werden. Nicht erlaubte HTTP-Anfragen beantwortet der Proxy mit Status 403.

Eine erlaubte Domain genügt dabei nicht automatisch. Löst sie in einen gesperrten IP-Bereich auf, wird die Verbindung ebenfalls abgewiesen. Dazu zählen standardmäßig Loopback-Ziele und der unter 169.254.169.254 erreichbare Cloud-Metadaten-Endpunkt. Diese zweite Kontrolle soll verhindern, dass eine freigegebene Domain über DNS-Rebinding oder eine ähnliche Umleitung plötzlich auf interne Infrastruktur zeigt.

An derselben Grenze werden auch Zugangsdaten ausgetauscht. In der Sandbox liegt lediglich ein Ersatz-Token. Erst der Proxy ersetzt ihn beim erlaubten ausgehenden Aufruf durch das echte Secret. Der Agent kann damit einen Dienst benutzen, ohne dessen Schlüssel direkt auslesen zu können.

Beide Kontrollen müssen gemeinsam greifen. Ein Ersatz-Token hilft wenig, wenn er über den Proxy beliebig eingesetzt werden kann. Eine Domain-Freigabe schützt umgekehrt keinen API-Schlüssel, der weiterhin als Umgebungsvariable im Container liegt. Zielregeln und Secret-Austausch gehören deshalb in dieselbe Sicherheitsentscheidung.

Eine Blockierung ist ein Prüfsignal

IronProxy erzeugt für Anfragen strukturierte JSON-Protokolle. Sie erfassen unter anderem die angewendete Regel, vorgenommene Secret-Ersetzungen und den Grund einer Blockierung. Damit lässt sich ein fehlgeschlagener API-Aufruf einem konkreten Ziel und einer konkreten Kontrolle zuordnen.

Das ist im Agentenbetrieb mehr als Diagnosekomfort. Ein blockierter Zugriff kann auf eine zu enge Freigabe hindeuten, aber auch auf eine manipulierte Abhängigkeit oder eine unerwünschte Reaktion auf fremden Inhalt. Die Protokolle liefern keine fertige Ursachenanalyse. Sie schaffen jedoch die Grundlage, um zwischen Fehlkonfiguration und verdächtigem Verhalten zu unterscheiden.

Ich würde eine Freigabe deshalb nicht unmittelbar nach einem fehlgeschlagenen Lauf erweitern. Zuerst sollte klar sein, welcher Prozess das Ziel angefragt hat, ob der Zugriff zum vorgesehenen Arbeitsablauf gehört und welche Daten dabei hätten abfließen können.

Zu einem kontrollierten Test gehört außerdem ein absichtlich nicht freigegebenes Ziel. Erwartet werden eine blockierte Verbindung und ein Log-Eintrag mit passender Regel oder Begründung. Fehlt dieser Eintrag oder erreicht der Prozess das Ziel trotzdem, ist die Netzgrenze nicht belastbar. Ohne diesen Negativtest wird aus einer engen Freigabeliste schnell wieder allgemeiner Netzzugang.

Probeaufbau: Paketdienst hinter dem Proxy

Hermes Agent kann einen persistenten Docker-Container als Terminal-Backend verwenden. Befehle laufen damit in einer isolierten Arbeitsumgebung, während der Agent selbst außerhalb des Containers arbeiten kann. Die Containergrenze beschränkt Datei- und Prozesszugriffe, kontrolliert ausgehende Verbindungen aber nicht zwangsläufig.

Als Beispielarchitektur bietet sich ein Agent an, der Quellcode bearbeitet, Tests startet und anschließend auf einen privaten Paketdienst zugreift. Im Container liegt nur ein Ersatz-Token; als Ziel ist ausschließlich der Paketdienst erlaubt. Versucht eine manipulierte Abhängigkeit zusätzlich einen unbekannten Server oder den Cloud-Metadaten-Endpunkt zu erreichen, soll IronProxy die Verbindung blockieren und den Grund protokollieren.

Diese Kombination ist ein plausibles Einsatzmodell, aber kein hier praktisch verifizierter Integrationstest zwischen Hermes Agent und IronProxy. Genau deshalb sollte der Betreiber vor einem unbeaufsichtigten Einsatz prüfen, ob sämtlicher Verkehr des Containers tatsächlich über den Proxy läuft und ein alternativer Netzpfad ausgeschlossen ist.

Bei einer fälschlich blockierten legitimen Anfrage wäre eine pauschale Netzfreigabe die falsche Reaktion. Der sichere Weg führt über den protokollierten Zielhost, eine möglichst enge Regeländerung und einen erneuten Negativtest gegen weiterhin verbotene Ziele. Lässt sich die Ausnahme nicht sauber begrenzen, bleibt die alte Regel bestehen und der Lauf wird abgebrochen.

Für unbeaufsichtigte Gateways kommen weitere Grenzen hinzu, etwa harte Stopps gegen wiederholte Werkzeugschleifen. Das adressiert ein anderes Risiko, folgt aber demselben Betriebsprinzip: Eine einzelne Sandbox-Grenze genügt nicht. Ein Circuit Breaker begrenzt ausufernde Ausführung, während der Egress-Proxy erreichbare Ziele und den Zugriff auf echte Secrets beschränkt. Wie mehrere Schutzschichten zusammenspielen, zeigt auch der Beitrag zu Sandboxing und Exec Approvals.

Die Schutzgrenze verschiebt sich

IronProxy macht die Ausführung unbekannten Codes nicht automatisch sicher. Der Proxy verwaltet Regeln, echte Zugangsdaten und sicherheitsrelevante Protokolle. Er braucht daher stärkeren Schutz als die Sandbox. Vor allem darf die Arbeitsumgebung keinen alternativen Weg ins Netz besitzen, über den sie die Kontrolle umgehen könnte.

Auch erlaubte Ziele bleiben Teil des Bedrohungsmodells. Kann ein Agent beliebige Anfragen an einen freigegebenen Dienst senden, ist Missbrauch innerhalb dieses Kanals weiterhin möglich. Freigaben sollten deshalb so eng wie praktikabel sein, Ersatz-Tokens nur für den vorgesehenen Zweck funktionieren und auffällige Anfragen in die bestehende Sicherheitsüberwachung einfließen. Für die Ablage echter Schlüssel gelten daneben die Regeln aus dem Praxisbeitrag zur sicheren Verwaltung von Secrets und API-Keys.

Drei Bedingungen für den Einsatz

IronProxy ist für unbeaufsichtigte Agenten nur dann eine tragfähige Grenze, wenn drei Bedingungen gleichzeitig erfüllt sind:

1. Die Sandbox besitzt keinen alternativen Weg ins Netz.
2. Ein Negativtest belegt, dass verbotene Ziele blockiert und protokolliert werden.
3. Jede neue Freigabe bleibt eng genug, dass sie nicht zum allgemeinen Ausleitungskanal wird.

Scheitert eine dieser Bedingungen, löst auch der Ersatz-Token das Grundproblem nicht. Bestehen alle drei, bleiben echte Zugangsdaten außerhalb der unvertrauenswürdigen Arbeitsumgebung und blockierte Zugriffe werden zu untersuchbaren Ereignissen statt zu stillen Datenabflüssen.