20 Tage vor
WebAssembly ist die Antwort auf die unangenehmste Frage im Agenten-Bau: Wem gibst du eigentlich exec?
Jeder, der ein Plugin-System für einen LLM-Agenten baut, landet irgendwann an derselben Stelle. Der Kern funktioniert, der Tool-Loop läuft, und dann sollen Erweiterungen dazukommen – von Nutzern, von Kollegen, aus dem Netz. Und plötzlich steht die Frage im Raum, über die in Demos nie gesprochen wird:
Was darf dieser fremde Code auf meinem Rechner eigentlich?
Die ehrliche Antwort lautet bei den meisten Setups: alles. Ein Plugin ist ein Skript, das Skript läuft im selben Prozess wie der Agent, der Agent hat deine API-Keys in der Umgebung, dein Dateisystem unter sich und eine offene Netzverbindung. Zwischen "nützliche Erweiterung" und "Exfiltration deiner Secrets" liegt genau nichts – außer Vertrauen.
Das ist der Punkt, an dem WebAssembly aufhört, ein Browser-Thema zu sein.
WASM IST KEIN SCHNELLERES JAVASCRIPT. ES IST EIN SICHERHEITSMODELL.
Die meiste Aufmerksamkeit für WebAssembly dreht sich um Performance. Interessanter ist aber die Eigenschaft, die WASM von Anfang an mitbringt und die andere Plugin-Formate mühsam nachrüsten müssen: Ein WASM-Modul kann per Konstruktion nichts.
Kein Dateisystem. Kein Netz. Keine Uhr, keine Umgebungsvariablen, keine Syscalls. Ein WASM-Modul sitzt in einem linearen Speicherbereich und hat exakt die Fähigkeiten, die der Host ihm als Funktionen hineinreicht – nicht eine mehr. Der Default ist nicht "großzügig". Der Default ist leer.
Damit dreht sich die Beweislast um. Bei einem nativen Plugin muss man einschränken, was es kann. Bei einem WASM-Plugin muss man erlauben, was es können soll. Ein kleiner Unterschied in der Formulierung – ein sehr großer in der Praxis.
WIE WIR DAS IN SEPP MINI NUTZEN
Ich baue sepp mini: einen leichtgewichtigen, erweiterbaren Agent-Harness in Rust. Eine statische Binary, kein Node, kein Ballast. Ein Agenten-Loop mit Streaming, parallelem Tool-Dispatch und Compaction – nutzbar als TUI, als One-shot-Kommando oder als JSONL-RPC zum Einbetten in andere Programme.
Erweiterbarkeit ist dort in vier Tiers geschichtet, gestuft nach Macht und Isolation:
Tier 1 – Resources: Skills, Prompt-Templates, Themes. Reine Daten, kein Code.
Tier 2 – Hooks: In-process Rhai-Skripte, die den Agent-Loop steuern. Sprach-Sandbox.
Tier 3 – WASM: Plugins aus jeder Sprache, memory-sandboxed via wasmi.
Tier 4 – MCP: Out-of-process-Server als Tool-Quelle, OS-sandboxed.
Je mehr eine Erweiterung darf, desto härter isoliert sie der Kern.
Tier 3 ist die Stelle, an der WebAssembly genau das liefert, was sonst teuer ist: echter Fremdcode ohne echtes Risiko. Ein Plugin deklariert im Manifest seine Capabilities – FsRead, FsWrite, Net, Env, Exec. Der Kern parst das zu einer Policy, der Mensch bestätigt sie, und dann registriert der Host nur die Funktionen, die die Policy erlaubt.
Der entscheidende Satz daran: Ein Plugin ohne Net-Capability bekommt keine Netz-Host-Funktion. Es ist damit nicht "gebeten, nicht ins Netz zu gehen" – es ist nachweislich offline. Es gibt keinen Syscall, den es aufrufen könnte. Der Default ist deny, und deny ist hier keine Konfiguration, sondern eine Abwesenheit.
Dazu kommt: Ein .wasm-Modul ist sprachagnostisch. Rust, Go, TinyGo, C, Zig, AssemblyScript – wer ein Plugin schreiben will, muss nicht meine Sprache lernen, sondern nur mein Interface treffen. Für ein Open-Source-Projekt ist das der Unterschied zwischen einem Ökosystem und einem Monolog.
WAS WASM NICHT LÖST – UND WOFÜR WIR DAS BETRIEBSSYSTEM BRAUCHEN
Ehrlichkeit gehört dazu, sonst wird es Marketing: WASM ist keine Universallösung.
Ein WASM-Modul kann keinen git-Prozess starten, keinen Language-Server sprechen, keine bestehende CLI wrappen. Sobald eine Erweiterung wirklich Prozesse ausführen muss, hilft keine Memory-Sandbox – dann muss die Grenze dorthin, wo sie hart ist: ins Betriebssystem. Genau dafür existiert Tier 4. MCP-Server laufen out-of-process, OS-sandboxed über Landlock unter Linux und Seatbelt (sandbox_init) unter macOS, beides fail-closed, plus Environment-Scrubbing – damit ein Subprozess keine API-Keys erbt, die ihm niemand geben wollte.
Die Architektur-Aussage ist also nicht "WASM für alles". Sie lautet: Die Isolationsmethode folgt der geforderten Macht. Daten brauchen keine Sandbox. Logik braucht eine Memory-Sandbox. Prozesse brauchen das OS. WebAssembly besetzt in dieser Staffelung die mittlere – und aus meiner Sicht wertvollste – Stufe: mächtig genug für echte Logik, isoliert genug, um Fremdcode ohne Bauchschmerzen laufen zu lassen.
WARUM DAS JETZT ZÄHLT
Agenten schreiben Code, führen ihn aus, rufen Tools auf. Das Ökosystem drumherum wächst schneller, als die Sicherheitsmodelle nachgezogen werden. Wir werden in den nächsten Jahren sehr viele Agent-Erweiterungen aus sehr unterschiedlichen Quellen installieren – und die Frage "was darf das eigentlich?" wird von einer Detailfrage zur zentralen Frage.
WebAssembly beantwortet sie mit dem einzigen Default, der skaliert: nichts, bis jemand etwas anderes sagt.
sepp mini ist Open Source, Rust, eine statische Binary, Linux und macOS inklusive Apple Silicon.
https://sepp.kionova.de
Wer selbst an Plugin- oder Sandbox-Architekturen für Agenten arbeitet: Ich bin ernsthaft an Gegenargumenten interessiert. Wo seht ihr die Grenzen des Capability-Ansatzes?
#WebAssembly #WASM #Rust #aiagents #opensource #SoftwareArchitecture
Jeder, der ein Plugin-System für einen LLM-Agenten baut, landet irgendwann an derselben Stelle. Der Kern funktioniert, der Tool-Loop läuft, und dann sollen Erweiterungen dazukommen – von Nutzern, von Kollegen, aus dem Netz. Und plötzlich steht die Frage im Raum, über die in Demos nie gesprochen wird:
Was darf dieser fremde Code auf meinem Rechner eigentlich?
Die ehrliche Antwort lautet bei den meisten Setups: alles. Ein Plugin ist ein Skript, das Skript läuft im selben Prozess wie der Agent, der Agent hat deine API-Keys in der Umgebung, dein Dateisystem unter sich und eine offene Netzverbindung. Zwischen "nützliche Erweiterung" und "Exfiltration deiner Secrets" liegt genau nichts – außer Vertrauen.
Das ist der Punkt, an dem WebAssembly aufhört, ein Browser-Thema zu sein.
WASM IST KEIN SCHNELLERES JAVASCRIPT. ES IST EIN SICHERHEITSMODELL.
Die meiste Aufmerksamkeit für WebAssembly dreht sich um Performance. Interessanter ist aber die Eigenschaft, die WASM von Anfang an mitbringt und die andere Plugin-Formate mühsam nachrüsten müssen: Ein WASM-Modul kann per Konstruktion nichts.
Kein Dateisystem. Kein Netz. Keine Uhr, keine Umgebungsvariablen, keine Syscalls. Ein WASM-Modul sitzt in einem linearen Speicherbereich und hat exakt die Fähigkeiten, die der Host ihm als Funktionen hineinreicht – nicht eine mehr. Der Default ist nicht "großzügig". Der Default ist leer.
Damit dreht sich die Beweislast um. Bei einem nativen Plugin muss man einschränken, was es kann. Bei einem WASM-Plugin muss man erlauben, was es können soll. Ein kleiner Unterschied in der Formulierung – ein sehr großer in der Praxis.
WIE WIR DAS IN SEPP MINI NUTZEN
Ich baue sepp mini: einen leichtgewichtigen, erweiterbaren Agent-Harness in Rust. Eine statische Binary, kein Node, kein Ballast. Ein Agenten-Loop mit Streaming, parallelem Tool-Dispatch und Compaction – nutzbar als TUI, als One-shot-Kommando oder als JSONL-RPC zum Einbetten in andere Programme.
Erweiterbarkeit ist dort in vier Tiers geschichtet, gestuft nach Macht und Isolation:
Tier 1 – Resources: Skills, Prompt-Templates, Themes. Reine Daten, kein Code.
Tier 2 – Hooks: In-process Rhai-Skripte, die den Agent-Loop steuern. Sprach-Sandbox.
Tier 3 – WASM: Plugins aus jeder Sprache, memory-sandboxed via wasmi.
Tier 4 – MCP: Out-of-process-Server als Tool-Quelle, OS-sandboxed.
Je mehr eine Erweiterung darf, desto härter isoliert sie der Kern.
Tier 3 ist die Stelle, an der WebAssembly genau das liefert, was sonst teuer ist: echter Fremdcode ohne echtes Risiko. Ein Plugin deklariert im Manifest seine Capabilities – FsRead, FsWrite, Net, Env, Exec. Der Kern parst das zu einer Policy, der Mensch bestätigt sie, und dann registriert der Host nur die Funktionen, die die Policy erlaubt.
Der entscheidende Satz daran: Ein Plugin ohne Net-Capability bekommt keine Netz-Host-Funktion. Es ist damit nicht "gebeten, nicht ins Netz zu gehen" – es ist nachweislich offline. Es gibt keinen Syscall, den es aufrufen könnte. Der Default ist deny, und deny ist hier keine Konfiguration, sondern eine Abwesenheit.
Dazu kommt: Ein .wasm-Modul ist sprachagnostisch. Rust, Go, TinyGo, C, Zig, AssemblyScript – wer ein Plugin schreiben will, muss nicht meine Sprache lernen, sondern nur mein Interface treffen. Für ein Open-Source-Projekt ist das der Unterschied zwischen einem Ökosystem und einem Monolog.
WAS WASM NICHT LÖST – UND WOFÜR WIR DAS BETRIEBSSYSTEM BRAUCHEN
Ehrlichkeit gehört dazu, sonst wird es Marketing: WASM ist keine Universallösung.
Ein WASM-Modul kann keinen git-Prozess starten, keinen Language-Server sprechen, keine bestehende CLI wrappen. Sobald eine Erweiterung wirklich Prozesse ausführen muss, hilft keine Memory-Sandbox – dann muss die Grenze dorthin, wo sie hart ist: ins Betriebssystem. Genau dafür existiert Tier 4. MCP-Server laufen out-of-process, OS-sandboxed über Landlock unter Linux und Seatbelt (sandbox_init) unter macOS, beides fail-closed, plus Environment-Scrubbing – damit ein Subprozess keine API-Keys erbt, die ihm niemand geben wollte.
Die Architektur-Aussage ist also nicht "WASM für alles". Sie lautet: Die Isolationsmethode folgt der geforderten Macht. Daten brauchen keine Sandbox. Logik braucht eine Memory-Sandbox. Prozesse brauchen das OS. WebAssembly besetzt in dieser Staffelung die mittlere – und aus meiner Sicht wertvollste – Stufe: mächtig genug für echte Logik, isoliert genug, um Fremdcode ohne Bauchschmerzen laufen zu lassen.
WARUM DAS JETZT ZÄHLT
Agenten schreiben Code, führen ihn aus, rufen Tools auf. Das Ökosystem drumherum wächst schneller, als die Sicherheitsmodelle nachgezogen werden. Wir werden in den nächsten Jahren sehr viele Agent-Erweiterungen aus sehr unterschiedlichen Quellen installieren – und die Frage "was darf das eigentlich?" wird von einer Detailfrage zur zentralen Frage.
WebAssembly beantwortet sie mit dem einzigen Default, der skaliert: nichts, bis jemand etwas anderes sagt.
sepp mini ist Open Source, Rust, eine statische Binary, Linux und macOS inklusive Apple Silicon.
https://sepp.kionova.de
Wer selbst an Plugin- oder Sandbox-Architekturen für Agenten arbeitet: Ich bin ernsthaft an Gegenargumenten interessiert. Wo seht ihr die Grenzen des Capability-Ansatzes?
#WebAssembly #WASM #Rust #aiagents #opensource #SoftwareArchitecture
