E2B Secrets hält API-Schlüssel aus den Sandboxes von KI-Agenten fern

Das Problem mit Umgebungsvariablen

Agenten benötigen häufig Zugriff auf Dienste, die Zugangsdaten verlangen, etwa eine Such-API für einen Recherche-Agenten oder ein externes LLM für einen Workflow zur Dokumentenverarbeitung. Laut E2B hat es eine Schwachstelle, ein Secret als Umgebungsvariable zu übergeben: Code in der Sandbox kann es auslesen, in ein Log schreiben oder an eine andere Stelle senden.

E2B formuliert es so: "Sandbox isolation doesn't protect a credential you've placed inside the sandbox." E2B Secrets soll Agenten mit externen Diensten verbinden und die Secrets dabei außerhalb der Ausführungsumgebung für den Code halten.

So funktioniert die Request-Injektion

Entwickler hinterlegen ein Secret bei E2B, verweisen per Namen darauf und legen fest, welches HTTPS-Ziel und welche Request-Header es erhalten sollen. Der Agent sendet anschließend eine HTTPS-Anfrage ohne das echte Secret. Außerhalb der Sandbox fängt E2B Anfragen ab, die zu den konfigurierten Netzwerkregeln passen, löst das hinterlegte Secret auf und trägt dessen Wert in die gewählten Header ein, bevor die Anfrage weitergeleitet wird. Werte lassen sich in jeden beliebigen HTTP-Request-Header einfügen.

In E2Bs Beispiel ruft eine Sandbox Claude auf, um ein Dokument zusammenzufassen. Aus einem vertrauenswürdigen Backend speichert der Entwickler einmalig einen Anthropic-API-Schlüssel mit dem E2B-SDK. Das SDK verbindet sich per HTTPS mit der E2B-API, und TLS verschlüsselt das Secret bei der Übertragung.

Die Sandbox wird dann mit Netzwerkregeln erstellt, die Datenverkehr zu api.anthropic.com erlauben und sonstigen ausgehenden Verkehr blockieren. Die Regel weist E2B an, den Header x-api-key mit Secret.fill() zu befüllen. Dabei entsteht eine Referenz, sodass die Sandbox-Konfiguration den Namen des Secrets enthält und nicht dessen Wert.

In der Sandbox enthält ein curl-Befehl an den Messages-Endpunkt von Anthropic nur den Prompt, das Modell und die API-Version. API-Schlüssel oder x-api-key-Header sind nicht nötig. E2B ergänzt den Header, nachdem die Anfrage die Sandbox verlassen hat. Laut E2B funktioniert dasselbe Muster auch für kostenpflichtige Such-APIs, andere Modellanbieter oder interne HTTPS-Dienste eines Unternehmens.

Speicherung und Rotation

E2B speichert Secret-Werte nach eigenen Angaben verschlüsselt (Encryption at Rest). Die Management-API ist für Werte schreibgeschützt in einer Richtung: Entwickler können ein Secret anlegen und aktualisieren, Lese- und Listenabfragen liefern aber nur Metadaten. Für die Request-Injektion wird der Wert außerhalb der Umgebungsvariablen und des Dateisystems der Sandbox gehalten.

Die Rotation erfolgt aus dem Backend mit Secret.update(). Dasselbe gespeicherte Secret kann von mehreren Sandboxes eines Projekts referenziert werden. Nach einer Rotation verwenden nachfolgende passende Anfragen dieser Sandboxes den neuen Wert, ohne dass Sandboxes neu gestartet oder ihre Netzwerkregeln geändert werden müssen. Pausierte Sandboxes übernehmen beim Fortsetzen den aktuellen Wert. Anfragen, die den vorherigen Wert bereits aufgelöst haben, können damit noch abgeschlossen werden.

Wie es weitergeht

Die Unterstützung für Bring Your Own Cloud (BYOC) soll bald folgen, interessierte Kunden können sich an [email protected] wenden. Außerdem arbeitet E2B an einfacheren Integrationen mit Drittanbieterdiensten. Darüber hinaus ist geplant, Secrets und Workload-Tokens direkt in Sandboxes auszuliefern, für Tools, die Zugangsdaten in ihrer Ausführungsumgebung benötigen.

Für Teams, die Agenten auf E2B bauen, bietet die Funktion eine Möglichkeit, Agenten Zugriff auf kostenpflichtige oder interne Dienste zu geben und zugleich zu begrenzen, was Code in der Sandbox preisgeben kann. E2B verweist Entwickler auf seine Dokumentation, darunter Seiten zu Request-Injektion und Secret-Rotation.