Zehntausende Instanzen einer populären agentischen KI-Plattform stehen ungeschützt im öffentlichen Internet. In den Monaten seit der Veröffentlichung wurden Hunderte Security Advisories gegen sie publiziert, und ihr Skill-Marktplatz enthält in etwa jedem fünften Eintrag Schadsoftware. Der architektonische Fehler ist implizite Credential-Autorität in einem einzigen Prozess ohne Audit-Protokoll.
Implizite Autorität
Das Muster ist vertraut. Ein einziger Prozess hält jedes Credential, das Sie ihm übergeben haben. Das LLM, das diesen Prozess antreibt, kann jedes Werkzeug aufrufen, das daran verdrahtet wurde. OAuth-Scopes wurden für einen Menschen an der Tastatur entworfen. Sie sind zu grob, um einen Agenten zu begrenzen, der mit Maschinengeschwindigkeit über die gesamte Menge der von Ihnen gewährten Scopes hinweg arbeitet. Wird dieser Prozess kompromittiert, oder lässt sich das Modell zu etwas überreden, das Sie nicht beabsichtigten, dann reicht der Schadensradius bis zu allem, was Sie auf den Systemen tun können, die diese Token erreichen.
Credential-Wildwuchs pro Prozess ist das Symptom. Ein einzelner Node-Prozess, der die Schlüssel zu Ihrer E-Mail, Ihrem Chat, Ihren Dateien und Ihrer Versionsverwaltung hält, ist der Fehlermodus.
Dieses Problem als Konfigurationsfrage innerhalb desselben Prozesses zu behandeln, erzeugt einen konfigurierbareren Single Point of Failure, keinen kleineren.
Was wir stattdessen gebaut haben
Wir haben Wirken gebaut, damit Sie die Autorität Ihres Agenten in Teile zerlegen und nachvollziehen können, was er mit jedem einzelnen Teil tut. Vier Mechanismen tragen das Design.
Ein typisiertes Rust-Action-Enum benennt jede freigabepflichtige Aktion. Der Dispatcher gleicht bei jedem Werkzeugaufruf gegen das Enum ab, der Match ist total, und der Compiler erzwingt diese Totalität: eine freigabepflichtige Aktion, die niemand klassifiziert hat, lässt sich nicht bauen. Ein Modell, das {"tool": "shell", "command": "rm -rf /"} ausgibt, löst sich zu Action::ShellExec auf. Das ist Tier 3, und Tier 3 fragt vor der Ausführung bei Ihnen nach. Die Policy-Entscheidung findet in Rust statt, bevor das vom Modell erzeugte JSON das Werkzeug erreicht.
Jeder Kanaladapter läuft als eigener Betriebssystem-Prozess mit eigener Ed25519-Identität. Plattform-Zugangsdaten für eine Chat-Oberfläche liegen niemals im selben Speicher wie die einer anderen. Das Typsystem des IPC-Crates macht kanalübergreifende Handle-Konvertierungen zu einem Compile-Error, und die Vermittlung prüft auf jedem eingehenden Frame einen AuthenticatedChannel. Eine Kompromittierung des Telegram-Adapters kompromittiert Telegram, nicht Slack und nicht Ihren Vault.
Zugangsdaten liegen in einem XChaCha20-Poly1305-Vault, dessen Schlüssel aus dem Schlüsselbund Ihres Betriebssystems abgeleitet wird. Entschlüsselte Geheimnisse sind in SecretString eingehüllt, das weder Display, Debug, Serialize noch Clone implementiert, und Speicher wird beim Drop genullt. Ein verirrtes println!("token: {token}") scheitert beim Kompilieren, nicht zur Laufzeit, sodass eine sorglose Debug-Zeile Ihren API-Schlüssel nicht versehentlich in eine Logdatei serialisieren kann.
Jede Session schreibt ein SHA-256-hash-verkettetes Event-Log. Der Kettenkopf wird mit dem Ed25519-Schlüssel des Agenten signiert. wirken session verify spielt das Log offline ab und prüft Nachrichten-Hashes, deterministische Werkzeugergebnisse, Ketten-Integrität und die Signatur auf dem Kopf erneut. „Was hat mein Agent in dieser Session getan?" hat eine Antwort, die Sie im Nachhinein verifizieren können. Kein Protokoll, dem Sie vertrauen müssen.
Was Wirken bewusst nicht tut
Wir setzen das LLM nicht in den Freigabepfad. Das Action-Enum ist typgeprüftes Rust. Ein Modell, das Englisch falsch in JSON übersetzt, kann Ihre Sicherheitslage nicht stillschweigend untergraben, weil die Policy-Entscheidung in Rust getroffen wird, bevor das JSON das Werkzeug erreicht. Eine neue freigabepflichtige Aktion zu ergänzen erfordert, dass der Rust-Compiler jede Match-Stelle markiert. Das Modell schlägt vor; der Dispatcher entscheidet; das Audit-Protokoll zeichnet auf.
Wir hosten keine Workflows in der Vermittlung. Workflows gehören in Skills. Ein Skill kann Multi-Agenten-Strukturen intern abbilden, einschließlich Planner-Executor-Aufteilungen, Voting und Selbstkritik. Die Vermittlung routet; die geroutete Oberfläche ist der Skill. Würde man einen Zustandsautomaten in der Vermittlung hosten, weitete sich die Trusted Base für jeden Workflow aus, den irgendjemand irgendwo betreiben will, und genau diese Trusted Base hält Wirken klein.
Der Name
Die ursprünglichen Gebrüder Ottenheimer betrieben eine Baumwoll- und Leinenweberei in Württemberg, gegründet 1862 von Salomon und Joseph Ottenheimer. Die Weberei verwob isolierte Fäden zu einem nutzbaren Gewebe. Dieses Projekt tut dasselbe mit isolierten Kommunikationskanälen. Der Rest dieser Geschichte, einschließlich des Zwangsverkaufs 1937 und dessen, woran der Name das Projekt zu erinnern verpflichtet, steht im historischen Brief.
Ihre Agenten oder Sie selbst werden die Zugangsdaten in diesem Jahrzehnt halten. Wir haben Wirken gebaut, damit das Ihre Wahl bleibt, mit genügend Beweisen im Audit-Protokoll, um im Nachhinein dafür einzustehen.