SPACE entwickeln: Sichere und effiziente Laufzeiten für langlebige Agenten

Da agentische Workflows länger und autonomer werden, sind die Umgebungen, in denen KI-Agenten operieren, ebenso wichtig wie die Modelle, die sie steuern. Agenten müssen echte Arbeit verrichten, wie etwa Code ausführen, Dateisysteme bearbeiten und mehrstufige Aufgaben über Stunden oder Tage hinweg durchführen. Nutzer möchten, dass Agenten Zugriff auf die Tools und Dateien haben, die sie zur Erledigung dieser Aufgaben benötigen, müssen jedoch auch darauf vertrauen können, dass ihre Systeme sicher bleiben, selbst wenn Agenten kompromittiert werden. Eine Sandbox macht all dies möglich: eine isolierte Umgebung, in der ein Agent frei agieren kann, während der Host, andere Mandanten und sensible Anmeldedaten geschützt bleiben.

Herkömmliche containerbasierte Sandbox-Ansätze sind nicht für diese Aufgaben konzipiert. Sie setzen in der Regel kurzlebige, zustandslose Jobs voraus und betrachten den Kernel als einen Single Point of Failure. Im Gegensatz dazu sind Agenten-Sitzungen langlebig und zustandsbehaftet: Ein Agent sammelt über Stunden hinweg Kontext, ein Arbeitsdateisystem und laufende Prozesse an, die nicht einfach verworfen und von Grund auf neu aufgebaut werden können. Darüber hinaus sollte die Arbeitslast im Inneren standardmäßig als nicht vertrauenswürdig eingestuft werden, was strengere Sicherheitsmaßnahmen erforderlich macht. Langlebige Agenten-Sitzungen benötigen ein Substrat, das einen feindseligen Gast isolieren, seinen Zustand bewahren und dennoch im großen Maßstab betrieben werden kann.

Die größte Herausforderung bei der Sandbox-Entwicklung ergibt sich aus dem Spannungsfeld, das häufig zwischen Sicherheit, Funktionalität und Effizienz entsteht. Zum Beispiel:

Die Gewährung eines umfassenderen Zugriffs ermöglicht es einem Agenten, mehr zu erreichen, setzt jedoch mehr vom System einer Arbeitslast aus, der Sie nicht vertrauen.

Das Teilen von mehr Ressourcen zwischen Sandboxes beschleunigt die Erstellung, erweitert jedoch die Angriffsfläche.

Häufigere Snapshots verbessern die Wiederherstellung und ermöglichen Funktionen wie Rollbacks, erfordern jedoch Zeit und Speicherplatz.

Agentische Sandboxes, wie sie für die Codeausführung erforderlich sind, die Agent Skills nutzen oder Search as Code-Pipelines in Computer-Abfragen durchführen, benötigen alle drei Aspekte. Wir haben in den letzten Monaten intensiv an der Entwicklung der nächsten Generation der Agenten-Infrastruktur gearbeitet, die unsere Produkte antreibt. Heute stellen wir SPACE (Sandboxed Platform for Agentic Code Execution) vor: eine Sandbox-Plattform für agentische Workflows, die sicher, zuverlässig und effizient skalierbar ist. Letzten Monat haben wir mit der Einführung von SPACE als Sandbox-Ebene begonnen, die Perplexity Computer antreibt. In der letzten Woche hat sie sicher Millionen von Sandbox-Erstellungen und zig Millionen Wiederverbindungen unterstützt, wobei die Startzeiten 3- bis 5-mal schneller sind als bei unserer vorherigen Lösung.

Dieser Artikel stellt die Architektur- und Designentscheidungen hinter SPACE vor. Stand heute laufen 100 % der Computer-Sitzungen auf SPACE. Wir freuen uns darauf, diese Plattform auf noch mehr Oberflächen einzusetzen, um unseren Nutzern und Entwicklern eine erstklassige agentische Laufzeitumgebung zu bieten.

Architektur

Auf hoher Ebene ist das System in drei Schichten organisiert.

Die Steuerungsebene (Control Plane) bildet das Gehirn des Systems und entscheidet, was wo existieren soll. Sie besteht aus dem API-Gateway und Modulen zur clusterweiten Zustandsverwaltung.

Die Node-lokalen Dienste sind die lokale Maschinerie, die zur Ausführung des Plans der Steuerungsebene erforderlich ist. Sie verwalten den Sandbox-Lebenszyklus, Speicher, Netzwerk und die privilegierten Operationen im Hintergrund.

Die Sandbox ist die isolierte Ausführungsumgebung selbst. Sie ist als virtuelle Maschine implementiert, die mit dem space-Daemon gekoppelt ist: einem Hintergrundprozess im Gastsystem, der den Dateisystem-, Prozess- und Netzwerkzugriff für die Arbeitslast vermittelt.

Steuerungsebene

Das API-Gateway ist der Einstiegspunkt. Eingehende Anforderungen werden authentifiziert und autorisiert, dann in Datensätze des gewünschten Zustands übersetzt.

Die Steuerungsebene ist konzeptionell zustandslos, wobei alle dauerhaften Informationen in eine gemeinsam genutzte Datenbank ausgelagert werden. Sie verfolgt clusterweite Informationen über Sandboxes, wie z. B. welcher Node ihnen zugewiesen ist, wo sie ausgeführt werden und ob sie auf einem dauerhaften Speicher gesichert wurden. Sie vergleicht kontinuierlich den gewünschten Zustand mit dem beobachteten Zustand und führt beide zur Konvergenz. Die Vorgänge sind idempotent, sodass sich die Steuerungsebene nach einem Absturz, Neustart oder teilweisen Ausfall automatisch erholen kann.

Node-lokale Dienste

Node-lokale Dienste übernehmen die eigentliche Arbeit des Vorbereitens von Vorlagen, Startens von Sandboxes, Einrichtens der Vernetzung und Ausführens von Host-seitigen Laufzeitdiensten. Jeder Node führt eine kleine Gruppe von Daemons aus, die jede auf ihm platzierte Sandbox verwalten, und der Node ist die Quelle der Wahrheit für den Live-Zustand dieser Sandboxes.

Der Sandbox-Manager weiß, welche Sandboxes ausgeführt werden, angehalten, suspendiert oder gestoppt sind, zusammen mit ihren realen Ressourcen. Er läuft mit niedrigen Privilegien und delegiert alle privilegierten Arbeiten an den Node-Manager, den einzigen Root-Prozess, der die zugrunde liegenden Primitive vermittelt. Der Speicher wird lokal und dauerhaft verwaltet: Snapshots aktueller Sandbox-Zustände werden auf dem Node gespeichert, und ein Volume-Manager verschiebt Snapshots und Vorlagen bei Bedarf in den und aus dem Objektspeicher, um Node-übergreifende Operationen zu ermöglichen. Sicherheitsschleusen schützen den Zugriffsbereich einer Sandbox: Der Anmeldedaten-Manager regelt die Injektion von Anmeldedaten unter per-Dienst-Autorisierung, und das Netzwerk-Gateway erzwingt die Egress-Richtlinie jeder Sandbox.

Sandbox

Die Sandbox selbst ist eine virtuelle Maschine (VM) mit eigenem Gast-Kernel, die die Arbeitslast des Benutzers hinter einer Hardware-Isolationsgrenze ausführt. Da jede Sandbox über einen eigenen Kernel verfügt, kann eine kompromittierte Arbeitslast nicht auf einen gemeinsam genutzten Host-Kernel als Single Point of Failure zurückgreifen; selbst wenn der Gast-Kernel erfolgreich ausgenutzt wird, bleibt diese Kompromittierung auf die VM-Grenze der Sandbox beschränkt, anstatt sich auf andere Arbeitslasten auszuweiten.

Ein space-Daemon läuft innerhalb jeder virtuellen Maschine und dient als leichtgewichtiger Agent, der jede Aktion oder Änderung reguliert, die die Plattform innerhalb des Gasts durchführt. Er verwaltet den Dateisystemzugriff und die Prozesssteuerung. Er meldet zudem die Einsatzbereitschaft des Gasts und verfolgt die Aktivität, damit die Plattform weiß, wann eine Sandbox im Leerlauf ist und angehalten oder zurückgewonnen werden kann. Entscheidend ist, dass der space-Daemon nicht direkt mit Clients kommuniziert, sondern über einen privaten In-VM-Kanal mit dem Host kommuniziert. Dies hält die gesamte Gastinteraktion auf einem kontrollierten Pfad und reserviert das Netzwerk der Sandbox ausschließlich für den ausgehenden Datenverkehr der Arbeitslast.

Drei Säulen: Sicherheit, Funktionalität und Effizienz

Als Nächstes tauchen wir in die Schlüsselmerkmale ein, die SPACE über drei Säulen hinweg liefern muss: Sicherheit, Funktionalität und Effizienz. Wie bereits erwähnt, stehen diese drei Aspekte in einem Spannungsverhältnis. Dennoch können wir bei keinem von ihnen Kompromisse eingehen, wenn wir leistungsstarke Agenten unterstützen wollen, die den heutigen Modellfähigkeiten gerecht werden. Sicherheit schützt den Host, andere Mandanten oder die Geheimnisse eines Benutzers vor einer nicht vertrauenswürdigen, möglicherweise feindseligen Arbeitslast. Funktionalität bietet Agenten den reichhaltigen Lebenszyklus, den sie benötigen. Effizienz macht all dies bei begrenztem Speicher, Festplattenplatz und Rechenleistung erschwinglich.

Sicherheit: Schutz von Daten und Systemen

Sandbox-Plattformen benötigen eine starke Sicherheit, um sicherzustellen, dass fehlerhafter oder sogar bösartiger Code, der in Sandboxes ausgeführt wird, keine schädlichen Auswirkungen an anderer Stelle verursachen kann. Ohne die Durchsetzung strenger Egress-Kontrollen und das Fernhalten von Geheimnissen aus der Sandbox könnte ein einziger falscher Schritt eines Agenten die Schlüssel eines Benutzers preisgeben oder Arbeitsdaten exfiltrieren.

SPACE verfolgt einen geschichteten Ansatz zur Gewährleistung der Sicherheit für Sandboxes. Die Sandbox-Isolierung besteht aus zwei Komponenten: VM-Isolierung und Host-OS-Prozessisolierung. Beide müssen durchbrochen werden, um einen Zugriff über Sandbox-Grenzen hinweg zu ermöglichen. Die Kommunikation mit der Sandbox ist streng kontrolliert; Prozesse können nur über dedizierte Kanäle kommunizieren. Das Netzwerk-Gateway zwingt den gesamten Egress-Datenverkehr durch sich selbst. Der space-Daemon ist der einzige sanktionierte Kanal zwischen der (nicht vertrauenswürdigen) Sandbox und der (vertrauenswürdigen) Plattform.

Anmeldedaten befinden sich niemals dort, wo ein Agent sie stehlen kann. Der Anmeldedatenspeicher befindet sich außerhalb der Sandbox-Grenze und ist für den Lebenszyklus der Anmeldedaten verantwortlich. Er speichert und ruft Geheimnisse über ein anschließbares Vault-Backend ab, löst Anmeldedaten unter Verwendung hierarchischer Scoping-Regeln auf, verwaltet Metadaten wie Injektionsmethode und Ablaufdatum und erzwingt Ratenbegrenzungen sowie Audit-Logging bei allen Zugriffen. Bei Bedarf werden Anmeldedaten auf Netzwerkebene injiziert oder von einem Browser-Agenten automatisch ausgefüllt, anstatt direkt in die Sandbox einzutreten.

Daten sind im ruhenden Zustand geschützt. SPACE unterstützt BYOK (Bring Your Own Key) zum Schutz extern gespeicherter Daten. Verschlüsselungsschlüssel stammen aus dem Schlüsselverwaltungssystem des Kunden und gelangen niemals in die Sandbox. Wenn das Unternehmen den Schlüssel widerruft, werden seine Daten unlesbar.

Funktionalität: Unterstützung agentischer Workflows

Um agentische Workflows zu unterstützen, benötigen Sandboxes eine umfassende Unterstützung des Lebenszyklus. Sie müssen schnell und skalierbar erstellt werden, da ein Agent viele davon gleichzeitig starten kann und nicht darauf warten sollte, dass irgendeine davon startet. Sie müssen für eine unbestimmte Dauer bestehen bleiben, da eine Sitzung Minuten dauern oder über Monate laufen kann. Sie müssen sauber anhalten können, manchmal über lange Zeiträume, etwa wenn eine Aufgabe auf menschliche Eingaben wartet. Und sie müssen Forking, Rollback und Absturzwiederherstellung unterstützen, damit eine Sitzung verzweigen, einen Fehler rückgängig machen oder nach einem Fehler fortgesetzt werden kann, anstatt neu zu beginnen.

SPACE unterstützt all das oben Genannte. Es modelliert den gesamten Sandbox-Lebenszyklus als explizite Zustandsmaschine, was Vorgänge wie Erstellen, Anhalten, Fortsetzen, Suspendieren und Wiederherstellen ermöglicht.

Snapshots sind der Mechanismus, der den meisten dieser Funktionen zugrunde liegt. Ein Scheduler tickt in regelmäßigen Abständen und erfasst zwei Arten von Snapshots: Festplatten-Snapshots (punktuelle Kopien des Dateisystems) und vollständige Snapshots (Checkpoints der gesamten angehaltenen VM). Festplatten-Snapshots werden häufig erfasst, während vollständige Checkpoints seltener sind. Alles verbleibt auf dem Node, und die Aufbewahrungsdauer nimmt je nach Ebene ab. Diese Snapshots können zur Wiederherstellung innerhalb einer Sitzung verwendet werden; beispielsweise können Festplatten-Snapshots verwendet werden, um das Dateisystem zurückzusetzen, um einen destruktiven Befehl rückgängig zu machen, und vollständige Checkpoints lassen eine abgestürzte Sandbox an einem kürzlich gelaufenen Punkt wieder aufnehmen, anstatt von einer leeren Festplatte zu starten.

Wenn eine Sandbox suspendiert wird, wird die VM angehalten, ein vollständiger Snapshot erstellt und die Artefakte des vollständigen Snapshots werden in den Objektspeicher hochgeladen. Eine Datenbankzeile verfolgt den Snapshot und wird erst dann wiederherstellbar, wenn jedes Artefakt gelandet ist, sodass ein teilweise hochgeladener Snapshot niemals in einen korrupten Zustand wieder aufgenommen werden kann. Die Wiederherstellung ist das Gegenstück zur Suspendierung. Da der Snapshot eher im Objektspeicher als auf dem ursprünglichen Node liegt, kann jeder Node die Sandbox zurückholen. Der Scheduler wählt einen Node aus, dieser Node lädt die Artefakte herunter, wendet das Dateisystem-Delta über der Vorlage erneut an und nimmt die VM aus ihrem erfassten Zustand wieder auf.

Effizienz: Optimierung von Zeit und Speicherplatz

Es reicht nicht aus, die oben genannten Funktionen im luftleeren Raum zu implementieren; sie müssen auch unter engen Ressourcenbeschränkungen möglich sein. Speicher und Festplattenplatz auf einem Node sind endlich, und Benutzer möchten, dass Agenten so schnell wie möglich agieren, daher müssen Lebenszyklusoperationen zeitlich und speicherplatztechnisch günstig sein. Wir können es uns nicht leisten, bei jeder Erstellung, jedem Anhalten oder jeder Verzweigung einer Sandbox ein vollständiges Maschinenabbild zu kopieren.

Eine entscheidende Designentscheidung macht dies möglich: das Dateisystem. SPACE verwendet btrfs als Node-lokales Dateisystem für die Sandbox-Speicherung. Btrfs (B-tree-Dateisystem) kombiniert ein Copy-on-Write-Dateisystem mit integrierter logischer Volume-Verwaltung. Dies hat einige Vorteile:

Reflink-Kopien sind schnell, da Sie die zugrunde liegenden Extents gemeinsam nutzen, sodass nur Metadaten kopiert werden müssen.

Snapshots sind atomar und schnell, da Sie einfach ein neues Root-Verzeichnis erstellen.

Es ist minimaler Speicherplatz erforderlich, da nur das gespeichert wird, was sich geändert hat.

Infolgedessen können Sandboxes schnell erstellt und wiederhergestellt werden. Anstatt jedes Mal eine Sandbox von Grund auf neu zu erstellen, halten wir einen warmen Pool von Pods bereit, bei denen häufige Vorlagen bereits auf der Festplatte materialisiert sind, und erfüllen eine Anforderung, indem wir sie an einen Pod binden, dessen Vorlage bereits übereinstimmt. Das Geben eines eigenen beschreibbaren Root-Dateisystems an diese Sandbox ist dann ein Copy-on-Write-Klon anstelle einer vollständigen Kopie. Wenn kein warmer Pod passt, materialisieren wir die Vorlage bei Bedarf; wir fassen gleichzeitige Anfragen für dasselbe Image in einem einzigen Download zusammen, sodass ein Ansturm identischer Anfragen nicht zu einem Ansturm identischer Arbeit führt.

Das Ergebnis ist eine Sandbox-Laufzeitumgebung, die gleichzeitig leistungsstark, leichtgewichtig und extrem schnell ist. Als wir SPACE eingeführt haben, haben wir es zusammen mit unserem vorherigen Sandbox-Anbieter mit demselben Produktionsdatenverkehr betrieben. Während der Einführungswoche erstellte SPACE Sandboxes drei- bis fünfmal schneller über die gesamte Verteilung hinweg. Insbesondere sank die mittlere Erstellungslatenz von 185 Millisekunden auf 60 Millisekunden (3,1-fache Verbesserung), und die Latenz im 90. Perzentil sank von 447 Millisekunden auf 89 Millisekunden (5,0-fache Verbesserung). Wir beobachteten ähnliche Verbesserungen um eine Größenordnung bei anderen Indikatoren für Leistung und Ressourcennutzung.

Dies erleichtert auch das Erstellen fortlaufender Festplatten-Snapshots, da diese schnell und speichereffizient sind und kein Anhalten der Sandbox erfordern. Zudem reduziert eine effiziente Delta-Speicherung den für das Speichern dieser Snapshots benötigten Platz.

Fazit

Beim Entwerfen komplexer Systeme ist es verlockend, ein einzelnes Ziel zur isolierten Optimierung zu wählen. Aber Entwickler von Frontier-Agenten fordern gleichermaßen Sicherheit, Funktionalität und Effizienz. Mit SPACE haben wir uns vorgenommen, eine Pareto-Verbesserung über alle drei Säulen hinweg zu erreichen.

Jede einzelne Designentscheidung kann mehreren Zielen gleichzeitig dienen, was dieses empfindliche Gleichgewicht ermöglicht. VMs pro Sandbox geben jeder Arbeitslast einen eigenen Kernel, stärken die Sicherheit durch starke Isolierung und bieten gleichzeitig die saubere Checkpoint-Grenze, auf die sich Snapshots stützen. Btrfs ermöglicht die effiziente Implementierung von Snapshotting, Forking und anderen für agentische Laufzeitumgebungen wesentlichen Vorgängen. Der space-Daemon hält die gesamte Gastinteraktion auf einem kontrollierten Host-seitigen Pfad, versiegelt die Gast-Host-Grenze und bewahrt gleichzeitig die Bewegungsfreiheit der Agenten. Das zentrale Netzwerk-Gateway vermittelt Egress und Anmeldedaten-Injektion, ohne jemals Geheimnisse gegenüber dem Gast preiszugeben.

Das Ergebnis dieser und anderer Designentscheidungen ist eine Plattform, die reale Agentenorchestrierung in großem Maßstab ermöglicht. SPACE bietet das Substrat, auf dem langlebige, zustandsbehaftete Agenten sicher Aufgaben beliebiger Komplexität oder Dauer bewältigen können, ohne dabei Einbußen bei Leistung oder Sicherheit in Kauf nehmen zu müssen.

Heute betreibt SPACE bereits Millionen von Perplexity Computer-Sitzungen. Wir beabsichtigen, dass SPACE als einheitliche Ebene für die Bereitstellung und Steuerung von Sandboxes in jeder Umgebung dient: von Linux-MicroVMs über Windows-Gäste bis hin zur eigenen lokalen Maschine eines Benutzers. Wir arbeiten hart daran, SPACE in diese neuen Umgebungen zu bringen, damit Entwickler KI-Produkte ausliefern können, die überall dort funktionieren, wo Benutzer arbeiten.

Wenn Sie begierig darauf sind, die Rechenebene zu gestalten, die die Frontier-Agenten von morgen antreibt, laden wir Sie ein, unserem Team beizutreten.