Selvedge und Umsetzung mit Belegen
Eine Sandbox ist kein Zeuge
Unvertrauten Code auszuführen gehört zu den Ideen, die in einer Besprechung gut klingen, weil noch niemand den Vorfallbericht geschrieben hat. Lassen wir den Agenten ein Tool aufrufen. Lassen wir das Plugin eine Datei transformieren. Lassen wir das Partnermodul die Daten verarbeiten. Packen wir es in eine Sandbox. Wunderbar. Der Code kann nicht entkommen. Alle nicken. Dann fragt der Prüfer, was der Code in der Sandbox tatsächlich getan hat, und plötzlich stellt der Raum fest, dass Eindämmung nicht dasselbe ist wie Beweis.
Eine Sandbox beantwortet eine Frage: Ist die Arbeitslast innerhalb der Grenze geblieben? Das ist notwendig. Es ist nicht genug. Die schwierigere Frage ist, was während des Laufs passiert ist. Welches Artefakt wurde ausgeführt? Welche Richtlinie wurde angewendet? Welche Fähigkeiten wurden angefordert? Welche Host-Aufrufe wurden erlaubt oder verweigert? Wie viel Fuel, Speicher und Zeit hat es verbraucht? Was kam heraus? Kann der Lauf wiederholt werden, ohne der ursprünglichen Maschine zu vertrauen? Wenn diese Antworten in Logs und Vertrauen leben, hat das System ein Kostüm, keine Prüfspur.
Selvedge existiert für diese Lücke. Die Seite nennt es die Ausführungstranskript-Ebene für unvertrauten Code: AION beweist Argumentation, Ledger zeichnet Systemereignisse auf, und Selvedge erfasst die Ausführung. Die Implementierung folgt dieser Form. Der Arbeitsbereich ist ein Rust-2024-Projekt mit Crates für Kern-Digests und Ressourcengrenzen, Ausführungs-Engines, Wasmtime- und Kera-Backends, Determiniertheit, WASI- und Kera-Hosts, Richtlinien, AION-Verifikation, CLI, MCP, Registry, Runner, Daemon, Audit- und Gast-SDK-Oberflächen. Das öffentliche Versprechen ist bewusst schlicht: Selvedge führt unvertrauten Code unter deterministischer Ausführung, Richtliniendurchsetzung und Verifikationsdisziplin aus.
Der nützliche Unterschied ist klein und brutal. Eine Sandbox sagt, der Code hat den Bereich nicht verlassen. Selvedge ist dafür ausgelegt zu sagen, was der Code getan hat.
Das Transkript ist kein Log
Logs sind nützlich für Menschen, die bereits debuggen. Sie sind weniger nützlich, wenn die Frage ist, ob ein Lauf später von jemandem verifiziert werden kann, der dem ursprünglichen Host nicht vertraut hat. Eine Log-Zeile kann fehlen, neu geordnet, gefiltert, abgeschnitten, neu formatiert oder wegerklärt werden. Ein Transkript muss Teil des Ausführungsvertrags sein.
Selvedge Core definiert SHA3-256-Digests, Fehlertypen, Pfadvalidierung, Authentifizierungstoken und gemeinsame Ressourcengrenzen. Die README beschreibt Transkripte mit Hashes von Bytecode, Einstellungen, stdout, stderr, Ausgabe, Speicher und Globals, plus Fuel-Verbrauch und Host-Aufrufzahlen. Die Seite beschreibt, dass jeder Host-Aufruf in eine SHA3-256-Kette gehasht und das Ergebnis in einen AION-artigen Beweisumschlag mit Ed25519-Versiegelung eingebettet wird. Das ist der Unterschied zwischen einem System, das sagt vertrau mir, und einem System, das sagt hier ist das Paket.
In diesem Design steckt eine gesunde Portion Paranoia. Der Artefakt-Digest benennt den Code. Der Einstellungs-Digest benennt das deterministische Profil. Das Transkript benennt, was die Host-Grenze überschritten hat. Der signierte Umschlag macht Manipulation sichtbar. Offline-Verifikation bedeutet, dass die ursprüngliche Laufzeitumgebung nicht der einzige Zeuge ist. Das ist der Teil, den viele Sandbox-Geschichten auslassen, weil er weniger unterhaltsam ist als ein Plugin, das in einer Demo läuft. Demos fragen selten, wer das Audit-Log bearbeitet hat. Prüfer tun das.
Default Deny braucht auch Belege
Defaultdeny ist eine gute Haltung und ein schlechter Slogan, wenn es beim Folienbild bleibt. Selvedge-Policy verleiht dem Slogan Zähne. Die Policy-Crate definiert WASM-Fähigkeiten wie Uhr, Zufall, Dateisystem, Netzwerk, Umgebung, Stdio, Prozess und benutzerdefiniert. Sie trägt Ressourcengrenzen für Speicher, Dateigröße, Anweisungsanzahl und Zeit. Sie validiert Invarianten, lehnt doppelte Fähigkeiten ab, liefert strukturierte Fehler und bildet Fehler auf das gemeinsame Dweve-Fehlervokabular ab. Der Runner wendet die Ressourcengrenzen dann auf die Ausführungskonfiguration an, bevor die Workload startet.
Das bedeutet, die Policy ist kein Fragebogen, der nach dem Lauf beantwortet wird. Sie ist Eingabe für die Ausführung. Wenn die Workload Zugriff auf Zeit, Zufall, Dateisystem, Netzwerk, Umgebung oder Prozess anfragt, muss diese Anfrage die Policy passieren. Wenn sie zu viel Fuel, Speicher oder Wanduhrzeit verbraucht, endet der Lauf als kontrollierter Fehlschlag. Wenn eine Policy inkonsistent ist, sollte sie fehlschlagen, bevor das Artefakt anfängt, etwas Interessantes zu tun. Sehr langweilig. Sehr nützlich. Langweilig ist, wie wir uns die Wochenenden freihalten.
Der wichtige Punkt ist, dass Policy-Entscheidungen nicht getrennt von Beweisen sind. Eine Sandbox kann eine breite Kategorie erlauben oder verweigern und dennoch die Prüfspur dünn lassen. Selvedge ist darum herum gebaut, dass jede Gate-Entscheidung und jeder Ressourcenwert zur Geschichte des Laufs gehört. Das macht es nützlich für Agent-Tools, die Ausführung von Drittanbieter-Plugins, Kera-Inferenz, regulierte Workloads und Partnercode. Die Arbeit darf unvertrauenswürdig sein. Die Beweise sollten es nicht sein.
Determinismus ist, wo der Host aufhört zu improvisieren
Replay ist leicht zu versprechen und schwer zu halten. Der Host hat eine Uhr. Der Host hat Zufall. Das NaN-Verhalten von Gleitkommazahlen kann unangenehm sein. SIMD kann sich zwischen Architekturen unterscheiden. Dateisysteme, Umgebungsvariablen und Prozesszustand sind hervorragende Wege, Nichtdeterminismus an Orte zu schmuggeln, wo niemand ihn erwartet hat. Wenn Sie Replay wollen, müssen Sie diese Quellen entfernen oder kontrollieren, bevor sie zu Ausreden werden.
Selvedge macht deterministische Ausführung zum Standard. Die README beschreibt eine virtuelle Uhr, die auf die Epoche 2024-01-01 fixiert ist, geseedete ChaCha20-Zufälligkeit, Fuel-Messung, Transkripterzeugung und NaN-Kanonisierung. Sie sagt auch, dass SIMD-Erkennung am schnellsten ist, aber nur für dieselbe Architektur gilt, während das Deaktivieren von SIMD der vollständig portable, plattformübergreifende Weg ist. Dieser letzte Teil ist wichtig, weil Determinismus kein Gebet ist. Er ist eine Konfigurations- und Architekturentscheidung, und manchmal ist der ehrliche Kompromiss Geschwindigkeit gegen Portabilität.
Der Runner verwendet standardmäßig das Wasmtime-Backend mit aktivierter deterministischer Ausführung. Kera ist das andere Backend, ausgerichtet auf Graph-IR- und binäre neuronale Netzwerk-Workloads. Diese Aufteilung ist sinnvoll. WASM ist der allgemeine Pfad für unvertrauenswürdige Komponenten. Kera ist der KI-Graph-Pfad. Beide brauchen dieselbe umgebende Disziplin: Policy vor der Ausführung, deterministische Einstellungen, Transkript nach der Ausführung und Beweis um das Ergebnis herum.
Warum Agents dies weniger optional machen
Agentensysteme machen unvertraute Ausführung wieder salonfähig, ein Satz, bei dem jeder Sicherheitsverantwortliche hellhörig werden sollte. Ein Modell fordert einen Tool-Aufruf an. Ein Plugin führt eine Transformation aus. Ein generiertes Hilfsskript greift auf Daten zu. Ein Partner-Tool kommt über MCP herein. Das Modell hat das Tool nicht geschrieben, das Tool wurde möglicherweise nicht mit derselben Sorgfalt geprüft wie Produktcode, und der Benutzer erwartet trotzdem, dass das System erklärt, was passiert ist. Viel Glück dabei, wenn die einzige Antwort ein Logverzeichnis und Bauchgefühl sind.
Selvedge bietet eine MCP-Serveroberfläche für Agent-Tools, eine CLI für Build-, Verify-, Run- und Replay-Workflows, einen Daemon für langlaufende Ausführungen, Runner-Pooling und Cache-Warming, Registry-Client- und Server-Crates sowie ein Gast-SDK. Es geht nicht darum, dass jede Oberfläche gleich ist. Es geht darum, dass die Form der Nachweise vergleichbar sein sollte. Ob eine Arbeitslast als WASM-Komponente, als Kera-Graph, als Agent-Tool oder als Service-Job eintritt, die Ausführung sollte mit etwas enden, das sich verifizieren lässt.
Leistung ist ein Handel, kein Zauber
Die Selvedge-Seite enthält Benchmark-Zahlen aus der Datei BENCHMARKS.md des Repositorys: Der Kaltstart ist der wichtigste Gewinn, der heiße Pfad ist differenzierter, Kera JIT hat eine Geschichte mit warmen Graphen, und Vanilla-Wasmtime hält weiterhin einige Hot Paths mit wiederholten Aufrufen. Das ist die richtige Art, darüber zu sprechen. Laufzeitarbeit ist voller Kompromisse. Wenn ein Komponentenmodell ein Transkript und eine Nachweishülle erzeugt, hat es andere Kosten als der Minimalpfad. Wenn Kaltstart Ihr Problem ist, kann dieser Nachweispfad helfen. Wenn die Arbeitslast ein enger, wiederholter Aufruf ohne Transkript-Overhead ist, kann die Antwort anders ausfallen. Sehr unbequem, die Realität. Sie weigert sich, ein Werbeprospekt zu sein.
Die Artikelversion der Leistungsgeschichte ist daher einfach: Wählen Sie die Laufzeit für die Arbeitslast. Verwenden Sie keine Nachweishülle als magischen Geschwindigkeitstrank. Nutzen Sie sie, wenn die Kosten für fehlende, wiederholbare Nachweise höher sind als der Overhead. Bei Agent-Tools, regulierter Datenverarbeitung, Drittanbieter-Plugins und Ausführungen, bei denen später ein Mensch fragen wird, was passiert ist, sind diese Kosten oft real.
Was vor der Verwendung zu prüfen ist
Entscheiden Sie zunächst, ob Sie Eindämmung, Nachweise oder beides benötigen. Wenn die Arbeitslast vertrauenswürdig und intern ist, ist Selvedge möglicherweise mehr Mechanik als nötig. Wenn die Arbeitslast unvertraut, partnerbereitgestellt, modellausgelöst oder prüfungsrelevant ist, beginnt das Transkript seinen Platz zu verdienen.
Zweitens: Prüfen Sie die Richtlinie. Welche Fähigkeiten sind erlaubt? Welche sind verboten? Wie hoch sind die Grenzen für Fuel, Speicher und Zeit? Ist der deterministische Modus erforderlich oder nur erlaubend? Sind Dateisystem- und Netzwerkzugriff eng genug gefasst? Ist die Richtlinie mit dem Artefakt versioniert? Wenn die Richtlinie in einem Wiki lebt und die Ausführung woanders stattfindet, driftet das Design bereits.
Drittens: Testen Sie Replay als Produktverhalten. Warten Sie nicht auf ein Audit, um herauszufinden, ob die Hülle offline verifiziert. Führen Sie dasselbe Artefakt, dieselbe Richtlinie und dieselben Eingaben zweimal aus. Vergleichen Sie Transkripte. Versuchen Sie verweigerte Fähigkeiten. Brechen Sie die Prüfsumme. Ändern Sie den Seed. Deaktivieren Sie SIMD, wenn plattformübergreifende Identität wichtig ist. Die lästigen Tests sind der Punkt.
Die Lektion
Selvedge ist keine hübschere Sandbox. Es ist eine Ausführungs-Nachweisschicht. Es führt WASM- und Kera-Artefakte aus, startet mit Standardverweigerung, begrenzt Ressourcen, steuert deterministische Eingaben, hasht die Ausführung in Transkripte und verpackt Ergebnisse in eine Nachweishülle, die später geprüft werden kann. Das ist ein anderes Versprechen als der Code blieb in seiner Ecke.
Da KI-Systeme mehr Tools aufrufen, mehr generierte Helfer ausführen und mehr Komponenten von Drittanbietern akzeptieren, verliert diese Unterscheidung ihren akademischen Charakter. Die Frage wird nicht nur sein, ob die Arbeitslast entkommen ist. Die Frage wird sein, was sie getan hat, unter welcher Richtlinie, mit welchen Eingaben, mit welchen Ausgaben und ob jemand anderes diese Behauptung nachvollziehen kann.
Eine Sandbox ist eine Mauer. Selvedge versucht, auch der Zeuge zu sein.