Wie SPACE Anfragen an die richtige Sandbox-Ausführung weiterleitet

Wenn jemand einen KI-Agenten bittet, eine Tabelle zu analysieren oder Software zu testen, vertraut er darauf, dass dieser sicher mit seinen Dateien und Daten arbeitet. Agenten benötigen isolierte Umgebungen, in denen sie diese Arbeit erledigen können, ohne die Daten anderer Nutzer offenzulegen oder deren Workloads zu beeinträchtigen.

Da Agenten zunehmend komplexere Aufgaben mit größerer Autonomie übernehmen, helfen diese Umgebungen, Fehler einzudämmen und den Schaden zu begrenzen, den unsicherer oder bösartiger Code anrichten kann. Sandboxes bieten diese Isolation und teilen sich dabei Control-Plane-Dienste, Worker-Knoten und Routing-Infrastruktur.

Diese gemeinsam genutzte Infrastruktur muss jede Operation an die Ausführung zustellen, die zu ihrer Verarbeitung autorisiert ist. Eine veraltete Route kann eine gültige Anfrage an eine andere Sandbox senden – oder an eine ältere Ausführung der richtigen Sandbox. SPACE, die sichere Sandbox-Plattform von Perplexity, bindet jede Operation an eine ausgewählte Ausführung und prüft das Ziel vor der Weiterleitung.

Seit Monaten verarbeitet SPACE Millionen von Ausführungen pro Tag, jede durch eine eigene kryptografische Identität geschützt, mit einer Fehlerquote unter 0,0002 % und ohne einen einzigen Verbindungsabbruch.

Das Routing-Problem

Die Sicherheit von Sandboxes hängt auch davon ab, dass jede Anfrage das richtige Ziel erreicht. Selbst ein einfacher Dateilesevorgang durchläuft eine gemeinsam genutzte Infrastruktur, die nachverfolgen muss, wo die Sandbox gerade läuft, während sie pausiert, fortgesetzt wird oder zwischen Maschinen wechselt.

Ein Dateilesevorgang durchläuft mehrere Komponenten. Die Control Plane von SPACE ordnet die Sandbox einer Ausführung und einem Worker zu. Die Anfrage gelangt über node-api ins System, wird an den Sandbox-Manager sbx-manager übergeben und passiert einen Unix-Socket zur Host-Bridge spaced-host. Die Bridge leitet sie über VSOCK, den Socket-Transport zwischen Host und Gast, an spaced-guest innerhalb der Firecracker-microVM weiter.

Jede Entscheidung stützt sich auf einen Zustand, der Änderungen an der Infrastruktur hinterherhinken kann. Eine Datenbank kann eine alte Platzierung vorhalten, eine zwischengespeicherte Adresse kann woandershin zeigen, oder ein Socket-Pfad kann einen anderen Listener erhalten. Auch eine erfolgreiche Verbindung kann das falsche Ziel erreichen. Ein Lesevorgang könnte die Daten eines anderen Nutzers offenlegen; ein Schreibvorgang könnte das falsche Dateisystem verändern.

Snapshots bringen ein weiteres Problem mit sich. Wird eine Sandbox auf einem anderen Worker fortgesetzt, bleibt ihre logische Identität erhalten, doch es startet eine neue Ausführung. Eine verzögerte Anfrage oder eine fortbestehende Verbindung kann die vorherige Ausführung erreichen und unter dem richtigen Sandbox-Namen einen alten Zustand zurückgeben.

Vergrößern

Sandbox-Identität und Ausführungsidentität

SPACE trennt die Umgebung des Nutzers von der Laufzeit, die sie bedient:

• Sandbox-Identität: Die stabile ID der logischen Umgebung. Die Autorisierung des Aufrufers legt den Zugriff auf diese Sandbox fest.
• Routen-/Ausführungsidentität: Die ausgewählte Laufzeitinkarnation und ihre Platzierung, einschließlich Worker, Substrat und Aktivierung.

Eine Ausführungsgeneration unterscheidet Laufzeitinstanzen voneinander. Auf Kubernetes umfasst die Route zusätzlich die Pod-UID. Adressen lokalisieren Endpunkte; die Ausführungsidentität bestimmt, ob diese Endpunkte die Operation bedienen dürfen.

Angenommen, Sandbox S läuft als Ausführung 7 auf Worker A und wird dann als Ausführung 8 auf Worker B fortgesetzt. Eine für Ausführung 8 ausgewählte Anfrage muss fehlschlagen, wenn sie Ausführung 7 erreicht. Würde nur die Sandbox-ID geprüft, bliebe diese Abweichung unbemerkt.

Vergrößern

Signierte Ausführungsauswahl

Jede Anfrage enthält einen signierten Nachweis darüber, welche Sandbox-Ausführung sie verarbeiten darf und welcher Zugriff zulässig ist. Die empfangende Komponente prüft diesen Nachweis anhand ihrer eigenen Laufzeitidentität, bevor sie die Anfrage fortfahren lässt.

Nach der Autorisierung des Aufrufers stellt SPACE eine kurzlebige, signierte Capability aus, die Sandbox, Ausführung, Platzierung und zulässigen Zugriff angibt. Capabilities für öffentliche Service-Ports legen zusätzlich den erlaubten Port und das Protokoll fest.

Der empfangende Sandbox-Manager verifiziert die Signatur und vergleicht die vollständige Identität mit seinem lokal gespeicherten Laufzeitdatensatz. Die Signatur belegt, wer die Auswahl autorisiert hat. Der Vergleich belegt, ob diese Auswahl zum Empfänger passt.

ServicePort-Datenverkehr durchläuft eine zweite Prüfung am sandboxspezifischen Netzwerk-Gateway netgtw, bevor eine Verbindung zum Gast geöffnet wird. Das Gateway vergleicht die Identität mit dem vertrauenswürdigen Aktivierungszustand und prüft Port und Protokoll. Bei Steuerungsoperationen folgt anschließend die Verifizierung der Bridge-Endpunkte.

SPACE verwendet Ed25519-Signaturen. Signaturschlüssel der Control Plane stellen Capabilities aus; öffentliche Verifizierungsschlüssel auf Workern und Gateways können keine ausstellen.

Capabilities gelten 120 Sekunden, wobei beim Ablauf eine Uhrenabweichung von bis zu 15 Sekunden toleriert wird. Eine gültige Signatur und ein nicht abgelaufenes Token reichen dennoch nicht aus, wenn ausgewählte und installierte Identität nicht übereinstimmen.

Vergrößern

Ablehnung am falschen Ziel

Der empfangende Worker kann einen Routing-Fehler erkennen, selbst wenn die Anfrage selbst autorisiert ist. Er prüft, ob er die für diese Anfrage ausgewählte Ausführung betreibt, und lehnt die Anfrage ab, wenn beide voneinander abweichen.

Wenn eine für Ausführung 8 ausgewählte Anfrage Worker A erreicht, der noch Ausführung 7 bedient, lehnt Worker A sie vor der Weiterleitung ab. Sobald ein Empfänger die Identität von Ausführung 8 installiert hat, lehnt er auch Capabilities für Ausführung 7 ab, selbst bevor diese ablaufen.

Diese Garantie hat eine wichtige Grenze. Eine Capability für Ausführung 7 kann weiterhin zu einem Worker passen, der Ausführung 7 bedient, bis dieser Worker von der Stilllegung erfährt oder die Capability abläuft. Lokale Durchsetzung und eine begrenzte Lebensdauer der Capabilities greifen ineinander, während sich Aktualisierungen verbreiten.

Vergrößern

Verifizierung der Bridge-Endpunkte

Ein übereinstimmender Laufzeitdatensatz legt die beabsichtigte Ausführung fest. Die Control-Bridge muss zudem die Prozesse und den Transport erreichen, die zu dieser Aktivierung gehören – und nicht einen Ersatz, der dieselbe Adresse geerbt hat.

Die Sandbox- und Node-Manager verifizieren die Peer-Anmeldedaten der Host-Bridge sowie die Prozessidentitäten von Bridge und Firecracker einschließlich ihrer Startzeiten und erkennen so wiederverwendete IDs oder geänderte ausführbare Dateien

Transportprüfungen binden den VSOCK-Listener anhand von Socket-Eigentümerschaft, Gastidentität und Kernel-Socket-Nachweisen an den erwarteten Firecracker-Prozess. Die Bridge leitet Operationen erst nach der Verifizierung weiter und verweigert transparente Wiederverbindungen. Jede neue Verbindung muss die Prüfungen erneut bestehen.

Diese Verifizierung umfasst die Firecracker-Control-Bridge auf Kubernetes und auf direkt verwalteten Hosts. ServicePort-Datenverkehr wird an seinem Gateway über Ausführungs- und Portprüfungen kontrolliert; dabei wird nicht die Identität einer beliebigen Anwendung innerhalb des Gastsystems attestiert.

Vergrößern

Stream-Lebensdauer und Routenwiederherstellung

Manche Verbindungen bleiben geöffnet, während sich die Ausführung einer Sandbox ändert. Daher müssen Identitätsprüfungen über die ursprüngliche Anfrage hinausreichen. SPACE beendet Verbindungen, die an die alte Ausführung gebunden sind, und lässt geeignete Operationen unter denselben Sicherheitsprüfungen eine neue Verbindung zur aktuellen Ausführung herstellen.

Terminals und Dateiüberwachungen können länger bestehen als die Anfragen, die sie geöffnet haben. SPACE bindet Backend-Streams an eine Identitätsepoche, sodass ein Stream nicht mit der vorherigen Ausführung verbunden bleiben kann, nachdem der Empfänger eine Ersatzausführung installiert hat.

SPACE prüft die dauerhafte Identität erneut, bevor ein Stream geöffnet wird. Wird die Route oder die Ausführung ersetzt, wird die Lease des Streams widerrufen, wodurch Ein- und Ausgabe gestoppt werden.

Eigentümerwechsel sind etwas anderes als das Ersetzen einer Ausführung. Eine Übergabe von Lebenszyklusoperationen bei einem unveränderten Kubernetes-Resident bewahrt dessen Routenidentität, nicht abgelaufene Capabilities und Streams. Das Gateway erhält bestehende Streams außerdem bei Änderungen, die nur den Aktivierungsversuch innerhalb derselben Routen- und Ausführungsgeneration betreffen. Für neu geöffnete Streams ist die aktualisierte Identität erforderlich.

Bei der Wiederherstellung bleiben diese Prüfungen erhalten. Der Identitätsvergleicher kann bei einer abweichenden Inkarnation innerhalb derselben Sandbox RefreshRoute zurückgeben oder bei einer anderen Sandbox Deny. Nur ein erkanntes Refresh-Signal löst nach einer Identitätsablehnung eine Routenreparatur aus. Für Transportfehler gelten separate, operationsspezifische Wiederherstellungsregeln. Ungültige Signaturen, Zwecke oder Portprofile werden weiterhin abgelehnt.

Eine dafür geeignete Operation kann die aktuelle Ausführung ermitteln und einen neu aufgebauten Versuch unternehmen. Der Cache-Eintrag wird nur ersetzt, wenn er noch die abgelehnte Route enthält, sodass eine verzögerte Ablehnung keinen neueren Eintrag verdrängen kann. Die Aktualisierung nativer Sitzungen bewahrt den ursprünglichen Cache-Ablauf und trennt so die Routenreparatur von der Erneuerung der Autorisierung des Aufrufers.

Die Regeln für Wiederholungen bleiben operationsspezifisch. Ein Ersatz-Backend muss die Zulassung erneut durchlaufen, selbst wenn der clientseitige WebSocket geöffnet bleibt.

Vergrößern

Kompromisse und Vertrauensgrenzen

Die Ausführungsidentität wird zu einem sicherheitskritischen Zustand. Aktualisierungen der Control Plane und Bündel von Verifizierungsschlüsseln müssen die bedienenden Komponenten erreichen, und eine Stilllegung wird wirksam, sobald der jeweilige Empfänger die Aktualisierung installiert. Kurze Lebensdauern von Capabilities begrenzen die Wiederverwendung während der Verbreitung.

Das Design setzt voraus, dass die Identitätsdurchsetzung aktiviert ist, und vertraut dem Signierer der Control Plane, dem Worker-Kernel und den knotenlokalen Verwaltungsdiensten. Eine Kompromittierung von Root-Zugriff auf dem Worker oder von privilegierten Cluster-Administratorkonten liegt außerhalb des Bedrohungsmodells. Die Bridge-Verifizierung ist eine lokale Prozess- und Transportverifizierung, keine hardwaregestützte Remote-Attestierung.

Signaturverifizierung, Laufzeitvergleiche und Bridge-Validierung verursachen zusätzlichen Aufwand im Anfragepfad. Sie nutzen lokalen Zustand, statt an jedem privaten Hop eine entfernte Autorisierungsabfrage durchzuführen.

Branchenvergleich

Entscheidend ist der Vergleich, wie Plattformen damit umgehen, wenn eine autorisierte Anfrage die falsche Ausführung der richtigen Sandbox erreicht. Diese Ergebnisse betreffen die untersuchten Implementierungen, nicht die Sicherheit der Plattformen insgesamt. SPACE, OpenShell und E2B wurden am 8. Oktober 2026 geprüft:

• OpenShell: Bietet eine vergleichbare Ausführungsauswahl für neue Aufrufe und eine Bindung vom Supervisor an die Laufzeit – über Generations- und Autorisierungsprüfungen am Gateway, die Validierung der Backend-Identität und bestätigte aktive Supervisor-Verbindungen (Gateway-Zulassung, Laufzeitauthentifizierung und -bindung). SPACE führt die signierte Auswahl durch seinen gesamten Serving-Pfad und ergänzt sie um eine Prozess- und Transportverifizierung lokal auf dem Worker; OpenShell verteilt entsprechende Prüfungen auf sein Gateway, die Start-Identität und das authentifizierte Laufzeitprotokoll (Laufzeitdesign).
• E2B: Verfolgt Ausführungs-IDs und isoliert Proxy-Pools nach Firecracker-Lebenszyklus, doch sein eingehender Proxy wählt die logische Sandbox und den Port aus, ohne eine erwartete Ausführungsidentität, die der Empfänger vergleichen könnte (Routenveröffentlichung, Proxy-Zulassung). Eine ältere Ausführung, die auf einem veralteten Empfänger mit passenden Anmeldedaten noch als aktiv registriert ist, lässt sich durch diese Prüfungen nicht von der ausgewählten neueren Ausführung unterscheiden, auch wenn der reguläre Abbau Routen entfernt und an den Lebenszyklus gebundene Verbindungen schließt (Anmeldedaten, Abbau).
• CubeSandbox: Repariert beim Fortsetzen das Routing und invalidiert Caches, doch privater Ingress verwendet Sandbox-bezogene Anmeldedaten und leitet ohne erwartete Laufzeitinstanz weiter (Routing beim Fortsetzen, Ingress-Routing). Die Routenreparatur verkürzt Zeitfenster mit veralteten Routen; die an die Ausführung gebundene Capability von SPACE gibt dem Empfänger zudem eine unabhängige Grundlage, um die falsche Instanz abzulehnen.

Identität als Isolationsgrenze

Sichere Delegation setzt voraus, dass die Arbeit jedes Agenten innerhalb der für ihn vorgesehenen Grenzen bleibt. Eine microVM sorgt für Isolation, während die umgebende Plattform sicherstellen muss, dass jede Anfrage und jede laufende Verbindung die Ausführung erreicht, die zu ihrer Verarbeitung autorisiert ist.

SPACE macht die Ausführungsidentität zu einem Teil dieses Schutzes. Indem SPACE Ziele prüft, Bridge-Endpunkte verifiziert und Verbindungen an die Ausführung bindet, die sie autorisiert hat, wahrt es diese Grenzen, während Sandboxes pausieren, fortgesetzt werden und umziehen.

Wir setzen diese Arbeit fort, während sich die Infrastruktur weiterentwickelt. Für SPACE und andere Sandbox-Plattformen bedeutet Sicherheit, diese Pfade sowohl gegen alltägliche Routing-Fehler als auch gegen feindselige Workloads zu testen und die Grenzen überall dort zu stärken, wo diese Tests Lücken aufdecken.