Ein Prompt. Drei Shell-Befehle. Ich hab ihre eigene KI benutzt, um sie selbst zu hacken.
Das ist eine Art von Bug, der wahrscheinlich in jedem Multi-Agenten-KI-Produkt steckt, das heute ausgeliefert wird. Und der Fix ist ein Design-Pattern, über das in der Branche noch niemand spricht.
Hier die ganze Geschichte.
Ich wollte gar nichts hacken. Ich habe recherchiert, wie Perplexity Computer Sandboxing für meine eigene Agent-Infrastruktur handhabt. Ich wollte verstehen, wie produktive Multi-Agenten-Systeme tatsächlich Ausführungsumgebungen isolieren, was geteilt wird und was nicht.
Zuerst habe ich im System herumgestochert. Mir ist aufgefallen, dass Claude Code in der Sandbox installiert war.
Ich habe den Agenten aufgefordert, es zu starten und ein bisschen Testcode zu generieren, um zu sehen, wie es sich verhält. Hat funktioniert. Normales Claude Code, im Bypass-Permissions-Modus, sodass es keine Bestätigung verlangt. Sinnvoll für ein agentisches System.
Da dachte ich: Moment, wie handhaben sie die API-Keys? Claude Code braucht einen Anthropic-API-Key, um zu funktionieren. Der muss irgendwo in dieser Sandbox liegen. Wie wird er injiziert? Wie ist er abgesichert? Ist er isoliert?
Diese Frage hat mich auf diesen Weg gebracht.
Der Sub-Agent hat einen API-Key in seiner Prozess-Umgebung. Ich musste ihn stehlen.
Perplexity Computer hat es sechsmal versucht und ist gescheitert.
- Ich habe den Sub-Agenten gebeten, seine Umgebung auszugeben: abgelehnt!
- Ich habe ein trojanisches Skript auf dem gemeinsam genutzten Dateisystem platziert: Es hat meinen Code gelesen, verstanden, was er tut, und sich geweigert, ihn auszuführen!
- Ich habe .bashrc und .profile vergiftet: Sie feuerten zu früh, bevor der API-Key injiziert wurde.
- Ich habe eine gefälschte Node-Binärdatei in den PATH gelegt: Wurde nie ausgelöst.
- Ich habe den Coding-Agenten gestartet und gleichzeitig den Prozessbaum beobachtet: Der Sub-Agent läuft in einer anderen Sandbox, nichts wurde erfasst :(
- Ich habe das System-Prompt von Claude Code gefunden und geändert, um das Ablehnungsverhalten zu entfernen: Konnte kein benutzerdefiniertes System-Prompt finden, das injiziert wurde.
Sechs Fehlschläge. Die Sicherheit auf Modell-/Prompt-Ebene von Claude ist wirklich gut. Jedes Mal, wenn ich etwas Cleveres versuchte, hat das Modell es abgefangen.
Dann erinnerte sich Perplexity daran, dass Claude Code eine Node.js-App ist, die über npm gestartet wird. Und npm liest ~/.npmrc aus dem Home-Verzeichnis. Und das Home-Verzeichnis liegt auf dem gemeinsam genutzten Dateisystem, in das ich schreiben kann.
Node.js hat ein --require-Flag, das ein JavaScript-Modul vor dem Ausführen des Anwendungscodes lädt. Das kann man über NODE_OPTIONS in .npmrc setzen. Das heißt, wenn ich eine .npmrc in das gemeinsame Home-Verzeichnis schreibe, wird jeder Node-Prozess, den der Sub-Agent startet, meinen Code vorladen! Das passiert, bevor Claude Code überhaupt initialisiert wird, bevor irgendwelche Sicherheitsprüfungen laufen, bevor irgendwas!
Der Exploit besteht aus drei Befehlen:
- Ein sechszeiliges Skript schreiben, das process.env in eine Datei auf dem gemeinsamen Arbeitsbereich schreibt
echo 'node-options=--require /pfad/zu/script.js' > ~/.npmrc- Perplexity Computer bitten, eine beliebige Codierungsaufgabe zu erledigen
Sub-Agent startet → npm liest meine .npmrc → mein Preload feuert, bevor Claude Code startet → vollständige API-Zugangsdaten landen auf dem gemeinsamen Dateisystem.
Es hat funktioniert! Es hat mir ein Perplexity-Gateway-Token gegeben, das über agent-proxy.perplexity.ai zu ihrem Master-Anthropic-Konto weiterleitet.
Natürlich habe ich als Erstes diesen API-Key und die BASE_URL für Claude Code auf meinem Laptop gesetzt. Ich habe erwartet, dass die LLM-Aufrufe von Claude Code fehlschlagen und auf die Sandbox beschränkt bleiben. Ich war schockiert. Sofortige Antwort von Opus 4.6!
Dann dachte ich: "Bestimmt wird mein Konto dafür belastet, dieser API-Key muss an meinen Benutzer gebunden sein." Schon wieder falsch.
Ich habe Opus 4.6 gebeten, eine lange Geschichte zu generieren, die die Geschichte der Welt beschreibt, einschließlich jeder Erfindung, jedes Imperiums und jeder Entdeckung. Ich habe diesen Aufruf fünfmal parallel ausgeführt und dabei jeweils über 100k Ausgabe-Token generiert. Das hätte alle meine Perplexity Computer-Credits verbrauchen sollen, aber sie haben sich nicht bewegt.
Nicht IP-beschränkt. Nicht sitzungsgebunden. Nicht an die Sandbox gebunden. Ihre Rechnung.
Eines der am besten finanzierten KI-Startups der Welt wurde von einer Dotfile erwischt, die seit 2019 in Node.js-Supply-Chain-Angriffen verwendet wird.
Das Modell hat alles richtig gemacht. Die Infrastruktur nicht.
Und hier ist, was ich eigentlich möchte, dass Gründer, die Agent-Infrastruktur bauen, daraus mitnehmen.
Die Architektur von Perplexity ist zur Hälfte richtig. Sie verwenden einen Proxy zwischen der Sandbox und der Anthropic-API. Das ist das korrekte Muster. Man sollte niemals einen rohen Provider-API-Key in eine Sandbox legen. Ein Proxy gibt dir Kontrolle, Beobachtbarkeit und die Möglichkeit, den Zugriff zu widerrufen, ohne deinen Master-Key zu rotieren.
Das Problem ist, dass ihr Proxy-Token keinerlei Bindung an den Ausführungskontext hat. Sobald man es hat, funktioniert es überall und für immer.
So macht man es richtig:
Binde das Token an die Sandbox-ID. Token und Sandbox-ID stimmen nicht überein? Abgelehnt. Key läuft aus, aber du hast die Sandbox nicht? Nutzlos. Idealerweise sollte das Token auch an die IP-Adresse der Sandbox gebunden sein, aber E2B (der Sandbox-Provider, den sie verwenden) bietet das nicht vor der Initialisierung der Sandbox an.
Mach das Token flüchtig. Erstelle es, wenn die Sandbox hochfährt. Zerstöre es, wenn die Sandbox pausiert. Keine langlebigen Anmeldeinformationen. Der Proxy generiert ein kurzlebiges Token zu Sitzungsbeginn und macht es beim Herunterfahren ungültig. Ein auslaufender Key aus einer toten Sandbox ist ein toter Key.
Binde das Token an das Abrechnungskonto des Benutzers. Selbst wenn alles andere fehlschlägt, selbst wenn jemand ein Live-Token aus einer aktiven Sandbox exfiltriert und verwendet, bevor es abläuft, wird die Nutzung dem Konto belastet, das die Sitzung gestartet hat. Nicht einem gemeinsamen Master-Abrechnungspool. Das macht aus "unbegrenzter freier API-Zugriff" "jemand, der sein eigenes Kontingent missbraucht", was eine völlig andere Schwere ist.
Diese drei Dinge – sandboxgebunden, flüchtig, benutzerabgerechnet – machen das Proxy-Muster tatsächlich funktionsfähig. Ohne sie fügst du nur einen zusätzlichen Netzwerk-Hop hinzu, der nichts stoppt.
Das ist kein Perplexity-spezifisches Problem. Das ist die Standardarchitektur für Agent-Infrastruktur im Moment, weil sie am schnellsten zu bauen ist. Gemeinsam genutzte Dateisysteme zwischen Agenten, langlebige Anmeldeinformationen, Master-Konto-Abrechnung. Ich wette, die meisten Multi-Agenten-Produkte, die heute in Produktion sind, haben eine Version davon.
Vor der Veröffentlichung an @AravSrinivas und @denisyarats gemeldet.
