Astrid: die Sicherheitsgrenze vom Prompt in die WASM-Laufzeit verschieben

Capsules statt Prompts: wo Astrid die Sicherheitsgrenze hinlegt

Die README von astrid-runtime/astrid beschreibt das Projekt als portables, capability-sicheres System für komponierbare Software, geschrieben in Rust. Der Leitgedanke ist eine Analogie: Astrid behandelt eine Komponente so, wie ein Betriebssystem einen Prozess behandelt. Jede Fähigkeit steckt in einer versiegelten WebAssembly-Kapsel, die sich mit anderen Kapseln kombinieren lässt, nur ausdrücklich erteilte Rechte erhält und austauschbar bleibt, ohne dass ihr Wirkungsbereich wächst. Anbieter, Modell, Agenten-Schleife, Oberfläche und Distribution sind nach eigener Aussage nicht Teil des Kerns.

Im Abschnitt zur Motivation formuliert die README den Gegensatz scharf: Agent-Frameworks setzen ihr Vertrauen in den Prompt, Astrid setzt es in die Laufzeit. Ein Agent sei nicht vertrauenswürdiger Code auf der eigenen Maschine, mit Zugriff auf Dateien, Netzwerk und Zugangsdaten, und die Aufforderung, sich zu benehmen, sei keine Sicherheitsgrenze. Das ist eine klare Absage an promptbasierte Filterung als alleinige Schutzschicht. Ob die Umsetzung hält, was dieses Versprechen andeutet, lässt sich aus dem README-Auszug allein nicht beurteilen.

astrid-daemon als dummer Kernel und die Uplinks am Unix-Socket

Der Kern heißt astrid-daemon und wird in der README ausdrücklich als klein und absichtlich dumm bezeichnet. Er leitet Ereignisse weiter, setzt Capabilities durch, betreibt die Sandbox und schreibt die Audit-Kette. Ein Modell, ein Tool-Schema oder Geschäftslogik hält er nicht. Ein Jailbreak, ein präpariertes Werkzeug oder ein schlichter Fehler soll deshalb keine Datei lesen, kein Netz erreichen und keinen Prozess außerhalb der erteilten Rechte starten können. Diese Aufteilung ist der eigentliche Kunstgriff: Intelligenz liegt in den Kapseln, und ein Fehler in einer Kapsel kann den gemeinsamen Kernelzustand nicht beschädigen.

Was von außen angebunden wird, nennt Astrid Uplink. Kommandozeile, HTTP-Gateway oder Discord-Clients sind Protokoll-Clients, die über einen Unix-Domain-Socket mit dem Daemon sprechen und IPC-Ereignisse austauschen. Es gibt laut README kein Frontend-Trait; ein Uplink veröffentlicht Ereignisse und empfängt Antworten wie jeder andere Teilnehmer am Bus. Wer eine eigene Oberfläche anbinden will, schreibt damit einen Bus-Teilnehmer und keinen privilegierten Kernel-Client. Das ist ein anderer Schnittstellenschnitt als bei Frameworks, die eine UI-Schicht im Kern verankern.

Capsule.toml, astrid:* WIT-Pakete und tool.v1.execute.<name>

Kapseln sprechen ausschließlich über den Bus miteinander. Jede deklariert in einem Capsule.toml, was sie braucht und was sie anbietet, in typisierten Tabellen für Importe und Exporte. Der Kernel löst den Abhängigkeitsgraphen per topologischer Sortierung und startet die Kapseln in der passenden Reihenfolge. Das Verfahren ist überschaubar und hat eine Konsequenz, die man kennen sollte: Zyklen im Abhängigkeitsgraphen lassen sich so nicht auflösen. Wie Astrid mit ringförmigen Abhängigkeiten umgeht, steht im Auszug nicht.

Werkzeuge sind in diesem Modell keine Kernel-Kategorie, sondern eine IPC-Konvention. Eine Werkzeug-Kapsel fängt Ereignisse der Form tool.v1.execute.<name> ab, und der Kernel bekommt nie ein Tool-Schema zu sehen. Das Host-ABI folgt dem WebAssembly-Komponentenmodell mit versionierten astrid:* WIT-Paketen für fs, io, kv, ipc, net, http, sys, process, approval, identity, elicit und uplink. Eine Kapsel importiert nur, was ihr Manifest erlaubt, und jeder Aufruf wird an der Grenze geprüft. Für Autoren heißt das: Wer eine Funktion vermisst, die keinem dieser Pakete entspricht, hat kein Fallback über Syscalls.

Fünf getrennte Tore: Manifest, IPC-ACL, ed25519-Token, Genehmigung, OS-Sandbox

Beim Sicherheitsmodell betont die README die Zerlegung: Es gibt kein einzelnes Tor, durch das jede Aktion läuft, sondern mehrere unabhängige Mechanismen, die jeweils fail-closed arbeiten und dort greifen, wo die Wirkung entsteht. Die Sandbox läuft in Wasmtime ohne Syscalls, ohne Dateideskriptoren und ohne Host-Speicher. Das Manifest-Tor arbeitet mit Allow-Listen für Dateien, Netzwerk und Prozesse, wobei eine leere Liste alles verweigert. Die IPC-ACL erlaubt nur deklarierte Themen, und das Capability-Token ist ein ed25519-Grant, der an ein Ressourcenmuster gebunden, an einen Prinzipal geheftet, mit Ablauf versehen und global widerrufbar ist.

Hinzu kommen ein Genehmigungstor mit den Stufen once, session, always und deny sowie eine Betriebssystem-Sandbox für native Unterprozesse, unter Linux mit bwrap und unter macOS mit Seatbelt. Abgeschlossen wird das durch eine signierte, hash-verkettete Audit-Kette, in der jeder Eintrag den Hash des vorherigen einschließt; wer die Kette bricht, hinterlässt eine Spur. Die README schreibt, diese Mechanismen seien real und unabhängig getestet, und verweist auf das Kapitel zum fünfstufigen Tor im Astrid Book. Belege dafür, etwa Testberichte oder Audit-Ergebnisse, enthält der Auszug nicht.

brew tap astrid-runtime/tap, cargo install astrid und vier Binärdateien

Die Installation läuft unter macOS und Linux über Homebrew mit brew tap astrid-runtime/tap und brew install astrid. Alternativ nennt die README cargo install astrid von crates.io, wofür Rust 1.95 oder neuer nötig ist, sowie den Bau aus dem Quellcode mit git clone und cargo build --release, worauf die Binärdatei unter ./target/release/astrid liegt. Diese Versionsuntergrenze bindet den Einstieg an einen sehr neuen Toolchain-Stand; wer in einer Organisation mit festgelegter Rust-Version arbeitet, sollte das vorher abgleichen.

Vier Binärdateien gehören zusammen, aufgerufen wird normalerweise nur astrid. astrid ist der Kommandozeilen-Uplink und startet den Rest, astrid-daemon ist der Kernelprozess, astrid-build kompiliert und verpackt Kapseln nach wasm32-unknown-unknown, und astrid-emit dient als Brücke von der Standardein- und -ausgabe zum Bus für externe Hook-Erzeuger. Die Aufteilung ist sinnvoll, weil die Kommandozeile selbst keine Kernelrechte braucht, aber sie bedeutet auch vier Artefakte, die bei einem Upgrade zueinander passen müssen.

astrid init --distro: Distro.lock, BLAKE3-Pins und die fehlende Standard-Distribution

Die Ersteinrichtung erfolgt mit astrid init --distro <quelle>. Eine Distro ist ein kuratiertes Bündel von Kapseln; der Befehl holt es, zeigt Auswahlgruppen an und fragt die nötige Konfiguration ab. Astrid Runtime wählt laut README bewusst keine Produktdistribution aus und bündelt auch keine, sondern verlangt einen Namen, ein Repository, eine lokale Distro.toml oder ein signiertes .shuttle-Archiv. Geheimnisse landen pro Prinzipal im Secret-Store und nicht in der Kommandozeile, und init schreibt eine Distro.lock, die jede Kapsel über einen BLAKE3-Hash festpinnt. Für reproduzierbare Installationen ist das der wichtigste Teil des Ablaufs.

Wer keine vollständige Distro will, hat laut README eine zweite Option: Ein unkomponierter Laufzeitbetrieb erlaubt es, init zu überspringen und den Daemon direkt zu starten, um danach einzelne Kapseln nachzuladen. Der Unterschied liegt im Vertrauensmodell. Bei der Distro übernimmt man die Auswahl eines Anbieters als Ganzes, beim unkomponierten Betrieb entscheidet man pro Kapsel und trägt dafür mehr Zusammenstellungsarbeit. Für eigene Kapseln nennt die README astrid capsule new my-capsule, astrid capsule build und astrid capsule install ., wobei die Installation ohne Neustart in den laufenden Daemon lädt. Autoren hängen am astrid-sdk, und das Prozedur-Makro #[capsule] erzeugt den WASM-ABI-Boilerplate für Exporte, Serialisierung und Dispatch.

Redaktionelles Fazit

Passend ist Astrid für Teams, die Agent-Code mit echten Datei- und Netzrechten betreiben und diese Rechte pro Kapsel festlegen wollen, statt sie dem Modell zu überlassen. Weniger passend ist es für den schnellen Prototyp, weil die Ersteinrichtung eine Distro verlangt, die man selbst auswählen muss, und weil cargo install astrid Rust 1.95 oder neuer voraussetzt. Als erstes prüfen: ob die eigenen Werkzeuge sich als Capsule.toml mit Importen und Exporten beschreiben lassen und ob die gebrauchten Host-Funktionen in den astrid:* WIT-Paketen fs, net, http oder process überhaupt vorhanden sind.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes