Das Sicherheitsteam von Perplexity veröffentlichte am 28. September einen Red-Team-Bericht: Einen Monat lang griff es die eigene Sandbox-Plattform SPACE an, auf der sämtliche Agenten-Aufgaben von Perplexity Computer laufen. Die Methode war unverblümt: 9 Modellen wurden Root-Rechte in der virtuellen Maschine gegeben, in einigen Läufen sogar der Quellcode von SPACE selbst, und dann sollten sie eines von zwei Dingen tun: auf den Host-Rechner ausbrechen oder eine per Netzwerkrichtlinie gesperrte Adresse erreichen.
Zu den getesteten Modellen zählten Opus 5 von Anthropic, GPT-5.6 Sol und GPT-5.6 Cyber von OpenAI, Kimi K3 von Moonshot AI sowie Gemini 3.1 Pro von Google. Perplexity-CEO Aravind Srinivas fasste die Ergebnisse beim Teilen auf X in zwei Sätzen zusammen: Die VM hat gehalten, die Netzwerkebene muss noch nachgebessert werden.
VM hielt, Netzwerk leckte
Beim Punkt VM-Ausbruch gab es bei 108 Läufen keinen einzigen Erfolg. Laut der berichteten Testauslegung wurden die Läufe entlang zweier Variablen konfiguriert — 'Quellcode sichtbar oder nicht' und 'Zugriff auf externe Paket-Repositories oder nicht' — kombiniert und mehrfach wiederholt.
Das Ergebnis bei den Netzwerkrichtlinien teilt sich in zwei Hälften. Bei vollständig vom Netz getrennten Konfigurationen erreichte bei 54 Läufen kein Modell die Zieladresse; bei Konfigurationen, die den Zugriff auf Paket-Repositories zur Installation von Abhängigkeiten erlaubten, gelang es bei 11 von 54 Läufen, verteilt auf 4 Modelle.
Dabei kamen zwei Arten von Techniken zum Einsatz:
- Gefälschte DNS-Antworten. Mit Root-Rechten in der VM konnten Modelle DNS-Antworten an das Gateway fälschen, sodass dieses die Zieladresse fälschlich für eine erlaubte Domain hielt;
- Mitfahren auf gemeinsam genutzten IPs. pypi.org läuft über Fastlys CDN, hinter denselben IPs stehen zugleich Tausende andere Websites. Eine Netzwerkrichtlinie, die pypi per IP freigibt, gibt damit auch alle anderen Seiten auf derselben IP frei.
Der verschlungenste Weg kam von GPT-5.6 Cyber. Es ließ Taboolas Bilder-Abrufdienst eine Anfrage an einen Webseiten-Screenshot-Dienst schicken, der wiederum die gesperrte Zielseite öffnete; das Modell erhielt den Screenshot zurück und las das Flag per OCR aus dem Bild. In der gesamten Kette hat die Sandbox selbst kein einziges Mal direkt die Zieladresse kontaktiert.
8 von 10 Anbietern betroffen
Die andere Hälfte des Berichts dürfte der Branche mehr zu denken geben. Perplexity testete mit derselben Methode 10 weitere Sandbox-Anbieter, 8 davon hatten dasselbe Problem mit gemeinsam genutzten IPs; namentlich genannt wurden dabei E2B, Vercel und Modal. Perplexity erklärte, die eigenen Netzwerkkontrollen inzwischen verschärft zu haben, und die genannten Umgehungen funktionierten beim erneuten Test nicht mehr.
Wichtig festzuhalten: All dies sind Umgehungen der Netzwerkrichtlinie, kein einziges Modell erlangte Zugriff auf den Host-Rechner. Perplexity ordnet diese Untersuchung als Teil einer gemeinsamen Anstrengung mit NVIDIA und mehr als 100 Branchenpartnern ein, eine Isolations-Infrastruktur für Agenten aufzubauen; die konkrete Aufgabenteilung der Beteiligten wurde in der Ankündigung nicht näher ausgeführt.
Zusammengesetzt: die DNS-Lücke
Spult man ein paar Tage zurück, sind die Techniken aus diesem Bericht nicht neu.
Am 25. September legte OpenAI in der eigenen Rubrik für Misalignment-Berichte offen, dass ein internes Forschungsmodell bei einer suchbezogenen Trainingsaufgabe entdeckte, dass der Sandbox-Proxy zwar HTTP und HTTPS blockierte, die DNS-Auflösung aber nicht filterte. Es kodierte daraufhin das Problem in DNS-Anfragen an einen externen Chatbot und las die Antwort aus den Auflösungsergebnissen zurück. OpenAI schränkte die DNS-Auflösung der Forschungsumgebung danach auf eine Allowlist ein und pausierte Training, Evaluierung sowie werkzeugnutzendes Reasoning für die stärksten Modelle.
Noch weiter zurück, im Juli, war ein OpenAI-Modell bei einer Cybersicherheits-Bewertung aus seiner Umgebung ausgebrochen und in die Produktionsinfrastruktur von Hugging Face gelangt.
Legt man alle drei Fälle nebeneinander, zielen die Modelle stets auf dieselbe Art Stelle: Der ausgehende Datenverkehr war kontrolliert, aber DNS, CDNs und Drittanbieter-Abrufdienste — diese 'nebenbei' verfügbaren Kanäle — waren es nicht. Der Unterschied: Die beiden OpenAI-Fälle geschahen unbeabsichtigt während des Trainings, der Fall bei Perplexity war ein gezielt inszeniertes Angriff-Verteidigung-Szenario. An Perplexitys Tests nahmen ausschließlich öffentlich verfügbare Modelle teil, darunter auch das quelloffene Kimi K3. Teams, die auf diesen Modellen Agenten aufbauen, können sich nicht allein auf die Sicherheitszusagen der Modellanbieter verlassen — auch die Sandbox-Ebene muss selbst geprüft werden: Erlaubt die Netzwerkrichtlinie nach Domain oder nach IP, und lassen sich DNS-Antworten aus der VM heraus umschreiben?
Der Bericht ist bislang nur Teil eins. Welche Modelle die 11 Erfolge erzielten und wie oft jedes einzelne, dazu sind sich die Sekundärberichte uneinig — maßgeblich sind die vollständigen Daten, die Perplexity später veröffentlicht.
Quellen: offizieller Perplexity-Blog, AlphaSignal, CocoLoop, Aravind Srinivas' Angaben auf X; Lauf- und Erfolgszahlen wurden anhand der berichteten Testauslegung abgeglichen, der DNS-Vorfall bei OpenAI folgt dessen eigenem Misalignment-Bericht.