Von OpenClaw zu Agentor: Sichere AI Agents in Rust entwickeln

Wir wurden beauftragt, die Sicherheit eines Open-Source AI-Agents-Frameworks zu auditieren. Der Kunde wollte die Gewissheit, dass seine Agenten-Infrastruktur -- die sensible Daten ueber mehrere LLM-Anbieter hinweg verarbeitete -- die fuer ein Enterprise-Deployment erforderlichen Standards erfuellte. Was als routinemaessiger Sicherheitsauftrag begann, wurde zum Katalysator fuer den Aufbau von etwas voellig Neuem. Das Framework war gut gemeint, auf GitHub beliebt und aktiv gepflegt. Doch je tiefer wir gruben, desto klarer wurde: Die Probleme waren keine Bugs, die man beheben konnte. Es waren Architekturentscheidungen, die im Fundament verankert waren.

Was wir gefunden haben: Die Grenzen Python-basierter Agent-Frameworks

Das Framework, das wir auditiert haben, folgte einem im Python-basierten Agenten-Oekosystem gaengigen Muster. Agenten fuehrten Tools aus, indem sie Subprozesse starteten oder Funktionen direkt innerhalb desselben Python-Prozesses aufriefen. Es gab kein Sandboxing: Ein Tool mit einem Bug oder einer boesartigen Prompt-Injection konnte auf das Dateisystem zugreifen, Netzwerkanfragen stellen oder Umgebungsvariablen mit API-Keys auslesen. In einem unserer Tests demonstrierten wir, dass ein sorgfaeltig konstruierter Prompt einen Agenten dazu bringen konnte, Anmeldedaten zu exfiltrieren, die von einem anderen Agenten im selben Prozess im Speicher abgelegt worden waren.

Der Runtime-Overhead verschaerfte die Sicherheitsprobleme. Pythons Global Interpreter Lock bedeutete, dass Multi-Agent-Orchestrierung grundsaetzlich single-threaded war. Kaltstartzeiten lagen je nach Abhaengigkeitsbaum zwischen 2 und 5 Sekunden. Der Speicherverbrauch fuer einen einzelnen Agenten mit einem bescheidenen Tool-Set lag bei 200-400MB: handhabbar fuer eine Demo, unerschwinglich beim Betrieb von Dutzenden Agenten in der Produktion. Und jeder Neustart des Agenten lud die gesamte Abhaengigkeitskette neu, weil Python kein Konzept fuer Ahead-of-Time-Kompilierung fuer diese Art von Arbeitslast hat.

Die Compliance-Implikationen waren die letzte Sorge. Dynamische Typisierung bedeutete, dass Daten, die durch die Agent-Pipeline flossen, keine Compile-Time-Garantien ueber Form oder Inhalt hatten. Personenbezogene Daten konnten durch Logging-Middleware fliessen, ohne erkannt zu werden, weil es kein Typ-Level-Enforcement gab. DSGVO-Compliance zu erreichen erforderte es, jeden Datenzugriffspunkt in Runtime-Pruefungen einzuwickeln -- Pruefungen, die leicht vergessen, systematisch unmoeglich durchzusetzen und fuer statische Analyse unsichtbar waren. Fuer eine ISO-27001-zertifizierte Organisation wie unsere war die Empfehlung dieses Frameworks fuer den Produktionseinsatz keine Option.

Die Entscheidung: Von Grund auf in Rust bauen

Unser erster Instinkt war, Patches upstream beizusteuern. Wir entwarfen einen Vorschlag fuer eine Sandbox-Schicht, Speicherisolation zwischen Agenten und ein typisiertes Nachrichtenuebermittlungssystem. Doch je mehr wir den Umfang der Aenderungen definierten, desto klarer wurde, dass wir keine Verbesserungen vorschlugen -- wir schlugen einen Neubau vor. Die Plugin-Architektur des Frameworks setzte direkten Speicherzugriff zwischen Komponenten voraus. Das Tool-Ausfuehrungsmodell war um Pythons Import-System herum gebaut. Isolation nachtraeglich hinzuzufuegen haette jede bestehende Erweiterung zerstoert und den Zweck des Oekosystems zunichtegemacht.

Wir waehlten Rust aus Gruenden, die ueber das Folgen eines Trends hinausgingen. Unser Team hatte zwei Jahre damit verbracht, Smart Contracts fuer die Stellar-Blockchain mit Soroban zu schreiben: Rust-basierte Contracts, die zu WASM kompilieren und in einer Sandbox-Umgebung ausgefuehrt werden. Wir verstanden Rusts Ownership-Modell, sein Async-Oekosystem und, entscheidend, seine Faehigkeit, nach WebAssembly zu kompilieren. Jede Eigenschaft, die wir fuer ein sicheres Agent-Framework brauchten -- Speichersicherheit ohne Garbage Collection, Zero-Cost-Abstraktionen, deterministische Ressourcenbereinigung und ein WASM-Kompilierungsziel -- stellte Rust nativ bereit.

Die Entscheidung wurde nicht leichtfertig getroffen. Rust hat eine steilere Lernkurve als Python, das Oekosystem fuer KI-Tooling ist juenger, und die Entwicklungsgeschwindigkeit in den ersten Wochen war langsamer. Aber wir bauten Infrastruktur, die jahrelang in der Produktion laufen wuerde, sensible Daten in regulierten Branchen verarbeitend. Die anfaengliche Investition in Korrektheit wuerde sich an jedem Tag auszahlen, an dem das System ohne Sicherheitsvorfall lief.

Agentor-Architektur: 13 Crates, eine Mission

Agentor ist als Rust-Workspace mit 13 Crates strukturiert, jeder mit einer einzigen Verantwortlichkeit und klar definierten Grenzen. Es ist kein Monolith, der in Ordner aufgeteilt wurde: Jeder Crate kompiliert unabhaengig, hat seine eigene Test-Suite und stellt eine oeffentliche API ueber Rusts Modulsystem bereit. Abhaengigkeiten zwischen Crates sind explizit und werden vom Compiler durchgesetzt. Wenn ein Crate keinen Dateisystemzugriff braucht, haengt er einfach nicht von std::fs ab, und kein Runtime-Trick kann das aendern.

• agentor-core -- Agenten-Lifecycle-Management, Nachrichtenrouting und die Trait-Definitionen, die jeder andere Crate implementiert. Das Rueckgrat: definiert was ein Agent ist, wie Agenten kommunizieren und wie das System Multi-Agent-Workflows orchestriert.
• agentor-runtime -- Die async, Tokio-basierte Laufzeitumgebung, die die Agentenausfuehrung, Ressourcenlimits und Graceful Shutdown verwaltet. Handhabt Backpressure, Task-Priorisierung und stellt sicher, dass kein Agent andere von CPU oder Speicher berauben kann.
• agentor-providers -- LLM-Provider-Abstraktionsschicht mit Unterstuetzung fuer OpenAI, Anthropic und lokale Modelle ueber einen einheitlichen Trait. Den Provider zu wechseln erfordert die Aenderung eines Konfigurationswerts, nicht das Umschreiben von Code.
• agentor-tools -- Framework zur Tool-Definition und -Ausfuehrung mit Compile-Time-Typepruefung. Jedes Tool deklariert seine Inputs, Outputs und erforderlichen Berechtigungen als Rust-Typen.
• agentor-mcp -- Vollstaendige Implementierung des Model Context Protocol, die es Agentor-Agenten ermoeglicht, mit jedem MCP-kompatiblen System zu interoperieren.
• agentor-sandbox -- Die WASM-Isolationsschicht. Jede Tool-Ausfuehrung findet innerhalb einer sandboxed WASM-Instanz mit expliziten Capability-Grants statt.
• agentor-cli -- Kommandozeilenschnittstelle zum Erstellen, Ausfuehren und Verwalten von Agentenprojekten. Scaffoldet neue Projekte, fuehrt lokale Entwicklungsserver aus und verwaltet Deployments.
• agentor-codegen -- Codegenerierungs-Pipeline mit AST-aware Transformationen, Multi-File-Koordination und integrierter Kompilierungsverifikation.
• agentor-config -- Konfigurationsmanagement mit umgebungsabhaengigen Defaults, Secret-Handling und Validierung.
• agentor-telemetry -- Strukturiertes Logging, verteiltes Tracing und Metrikerfassung mit OpenTelemetry-Kompatibilitaet.
• agentor-auth -- Authentifizierung und Autorisierung fuer Agent-zu-Agent- und Agent-zu-Service-Kommunikation.
• agentor-storage -- Persistentes State-Management mit austauschbaren Backends (SQLite, PostgreSQL, In-Memory).
• agentor-testing -- Test-Utilities, Mock-Provider und Snapshot-Testing fuer Agentenverhalten.

WASM Sandbox: Sicherheit durch Design

Die Sandbox-Schicht ist die Architekturentscheidung, die Agentor von jeder Python-basierten Alternative unterscheidet. Wenn ein Agent ein Tool aufruft -- sei es das Lesen einer Datei, eine HTTP-Anfrage oder das Ausfuehren von generiertem Code -- laeuft dieses Tool innerhalb einer isolierten WASM-Instanz. Die Instanz hat keinen Zugriff auf das Host-Dateisystem, keine Netzwerkfaehigkeiten und keinen gemeinsamen Speicher mit anderen Tools oder dem Host-Prozess. Der Zugriff auf jede Ressource muss explizit ueber ein Capability-System gewaehrt werden, das zum Deployment-Zeitpunkt definiert wird.

Jede WASM-Instanz laeuft mit konfigurierbaren Speicherlimits und Ausfuehrungstimeouts. Wenn ein Tool versucht, mehr Speicher als erlaubt zuzuweisen, wird die Instanz beendet -- nicht der Agent, nicht die Runtime, nur diese einzelne Tool-Invokation. Wenn ein Tool sein Ausfuehrungstimeout ueberschreitet, wird es sauber mit vollstaendiger diagnostischer Ausgabe beendet. Das unterscheidet sich grundlegend von Pythons Ansatz, Subprozesse zu starten und zu hoffen, dass sie sich korrekt verhalten. In Agentor gibt es kein Hoffen: Die Beschraenkungen werden von der WASM-Runtime auf Instruktionsebene durchgesetzt.

Die praktische Auswirkung ist erheblich. In dem Framework, das wir auditiert haben, konnte ein Prompt-Injection-Angriff, der ein Tool zur Ausfuehrung beliebigen Codes veranlasste, das gesamte System kompromittieren. In Agentor bleibt derselbe Angriff auf eine sandboxed WASM-Instanz ohne Capabilities beschraenkt: Sie kann rechnen, aber sie kann nicht kommunizieren, persistieren oder auf irgendetwas ausserhalb ihrer Sandbox zugreifen. Der Schadensradius jedes Sicherheitsvorfalls wird von 'totale Systemkompromittierung' auf 'eine Tool-Invokation hat einen Fehler zurueckgegeben' reduziert.

Optimiert fuer Codegenerierung

Dies ist der Kern dessen, warum Agentor existiert und was es von Frameworks unterscheidet, die Codegenerierung als nur ein weiteres Tool behandeln. Agentor wurde von Grund auf als Runtime fuer KI-getriebene Codegenerierung gebaut: nicht Textgenerierung, die zufaellig Code produziert, sondern eine strukturierte Pipeline, die Code als erstklassiges Artefakt mit Syntax, Semantik und Abhaengigkeiten versteht.

Die Pipeline beginnt mit spezifikationsgetriebenem Development. Bevor ein Agent eine einzige Codezeile generiert, erstellt er eine strukturierte Spezifikation: die zu erstellenden oder zu aendernden Dateien, die zu implementierenden Interfaces, die erforderlichen Abhaengigkeiten und die Tests, die die Korrektheit validieren werden. Diese Spezifikation ist kein Vorschlag -- sie ist ein Vertrag, den die Generierungspipeline durchsetzt. Wenn der generierte Code nicht mit der Spec uebereinstimmt, weist die Pipeline ihn zurueck, bevor er das Dateisystem erreicht.

Die Multi-File-Ausgabekoordination ist der Punkt, an dem die meisten Codegenerierungstools scheitern. Eine einzelne Funktion zu generieren ist unkompliziert. Ein Modul mit fuenf Dateien zu generieren, die sich gegenseitig importieren, gemeinsame Interfaces implementieren und zusammen kompilieren muessen, ist um eine Groessenordnung schwieriger. Der Codegen-Crate von Agentor pflegt einen Abhaengigkeitsgraphen aller Dateien in einem Generierungsbatch, stellt sicher, dass Imports dateiuebergreifend korrekt aufgeloest werden, und validiert, dass die gesamte Ausgabe als Einheit kompiliert, bevor irgendetwas auf die Festplatte geschrieben wird.

AST-aware Transformationen ersetzen die naive Textersetzung, die die meisten Frameworks verwenden. Wenn Agentor bestehenden Code modifiziert, parst es den Quellcode in einen abstrakten Syntaxbaum, wendet Transformationen auf semantischer Ebene an und regeneriert den Quellcode. Das bedeutet, dass das Hinzufuegen einer Methode zu einer Klasse die Formatierung nicht zerstoert, das Einfuegen eines Imports keinen bestehenden dupliziert und das Umbenennen einer Funktion alle Aufrufstellen aktualisiert. Der Unterschied zwischen Textersetzung und AST-Transformation ist der Unterschied zwischen einem Suchen-und-Ersetzen-Tool und einem Compiler: Einer von beiden versteht den Code.

Die integrierte Testpipeline schliesst den Kreis. Jeder Generierungszyklus folgt derselben Sequenz: Generieren, Kompilieren, Testen, Iterieren. Wenn der generierte Code nicht kompiliert, erfasst Agentor die Compilerfehler, fuettert sie zusammen mit dem relevanten Kontext zurueck an das LLM und fordert eine korrigierte Version an -- automatisch, ohne menschliches Eingreifen. Wenn der Code kompiliert, aber Tests fehlschlagen, folgt die Testausgabe demselben Feedback-Loop. Dieser Generieren-Kompilieren-Testen-Iterieren-Zyklus konvergiert typischerweise in 2-3 Iterationen, und jede Iteration profitiert von Rusts Zero-Copy-Architektur, die den Overhead der Weitergabe grosser Codebasen zwischen Pipeline-Stufen minimiert.

MCP-Protokoll: Universelle KI-Interoperabilitaet

Das Model Context Protocol wird zum Standard fuer die Interoperabilitaet von KI-Systemen, und Agentor implementiert es als erstklassigen Buerger durch den agentor-mcp Crate. Jeder Agentor-Agent kann seine Faehigkeiten als MCP-Tools exponieren, Tools von externen MCP-Servern konsumieren und an Multi-System-Workflows teilnehmen, ohne benutzerdefinierten Integrationscode. Das bedeutet, dass ein Agentor-Codegenerierungsagent Tools verwenden kann, die von einem IDE-Plugin, einem CI/CD-System oder einem Cloud-Deployment-Service bereitgestellt werden -- alles ueber dasselbe Protokoll, mit denselben Sicherheitsgarantien, die von der Sandbox-Schicht durchgesetzt werden.

MCP-Unterstuetzung bedeutet auch, dass Organisationen Agentor schrittweise einfuehren koennen. Bestehende KI-Workflows, die auf anderen Frameworks aufgebaut sind, koennen Agentor-Agenten ueber MCP aufrufen, ohne ihre aktuelle Infrastruktur zu ersetzen. Wenn Teams Vertrauen in die Sicherheits- und Performance-Eigenschaften gewinnen, koennen sie zusaetzliche Workloads in ihrem eigenen Tempo migrieren. Es ist keine Big-Bang-Migration erforderlich: Agentor wurde fuer die Koexistenz konzipiert.

Compliance ohne Kompromisse

Als ISO-27001-zertifiziertes Unternehmen haben wir Agentor mit Compliance als Design-Beschraenkung gebaut, nicht als nachtraegliche Ergaenzung. Jede Architekturentscheidung wurde anhand der Anforderungen der regulatorischen Rahmenwerke bewertet, innerhalb derer unsere Kunden operieren.

• DSGVO -- Der Datenfluss durch die Agent-Pipeline wird auf Typ-Ebene verfolgt. PII-Felder werden mit Rusts Typsystem markiert, und jeder Versuch, PII ohne explizite Schwuerzung zu loggen, zu serialisieren oder zu uebertragen, wird zur Compile-Time erkannt. Die Sandbox stellt sicher, dass Tools nicht auf Daten zugreifen koennen, fuer die ihnen keine explizite Berechtigung erteilt wurde.
• ISO 27001 -- Zugriffskontrollen, Audit-Logging und Incident-Containment sind keine optionalen Module: Sie sind in die Runtime eingebaut. Jede Agentenaktion wird mit kryptographischer Integritaet geloggt, jede Tool-Invokation wird mit ihren Capability-Grants aufgezeichnet, und Sicherheitsereignisse loesen automatisches Containment ueber die Sandbox-Schicht aus.
• DPGA (Digital Public Goods Alliance) -- Agentor ist so konzipiert, dass es die Open-Source-Standards fuer digitale oeffentliche Gueter erfuellt, mit transparenter Governance, zugaenglicher Dokumentation und plattformunabhaengigem Deployment ueber WASM.

Der Kontrast zum auditierten Framework ist deutlich. DSGVO-Compliance in diesem Python-basierten System zu erreichen erforderte das Hinzufuegen von Runtime-Middleware an jeder Datengrenze, ohne Compiler-Enforcement und ohne Vollstaendigkeitsgarantie. In Agentor ist Compliance strukturell: Wenn der Code kompiliert, werden die Datenverarbeitungsregeln durchgesetzt.

Performance: Rust vs Python

Wir sind vorsichtig mit Benchmarks, weil sie irreführend sein koennen. Diese Zahlen stammen aus unserer internen Test-Suite, die denselben Agent-Workflow ausfuehrt -- eine Codegenerierungsaufgabe, die eine Spezifikation liest, drei Dateien generiert, sie kompiliert, Tests ausfuehrt und einmal iteriert -- auf derselben Hardware.

• Kaltstartzeit -- Agentor: 38ms. Das Python-Framework: 3,2 Sekunden. Das ist entscheidend, wenn man Agenten on-demand in Serverless-Umgebungen betreibt, wo jeder Kaltstart ein wartender Benutzer ist.
• Speicher-Footprint -- Agentor-Agent mit vollstaendigem Tool-Set: 42MB. Aequivalenter Python-Agent: 380MB. Eine 9-fache Reduktion, die sich direkt in Infrastrukturkosteneinsparungen beim Betrieb in grossem Massstab uebersetzt.
• Gleichzeitige Agenten -- Agentor auf einer 4-Core-Maschine: ueber 200 Agenten gleichzeitig mit linearer Throughput-Skalierung. Das Python-Framework: 12-15 Agenten, bevor der GIL zum Flaschenhals wird.
• Test-Suite -- 483 Tests, null Unsafe-Bloecke, null Verwendungen von unwrap() im Produktionscode. Jeder Fehlerpfad wird explizit behandelt.
• WASM-Sandbox-Overhead -- Die Sandbox-Isolation einer Tool-Invokation hinzuzufuegen kostet ungefaehr 1,2ms pro Invokation. Die Sicherheitsgarantie vollstaendiger Isolation fuer weniger als zwei Millisekunden Latenz ist ein Kompromiss, den wir ohne Zoegern akzeptieren.

Die aussagekraeftigste Zahl ist kein einzelner Benchmark: Es ist die gesamte Wall-Clock-Zeit fuer einen vollstaendigen Codegenerierungszyklus. Agentor schliesst den Generieren-Kompilieren-Testen-Iterieren-Loop in etwa 40% der Zeit ab, die das Python-Framework benoetigt, hauptsaechlich weil der Overhead zwischen Pipeline-Stufen in Mikrosekunden statt in Hunderten von Millisekunden gemessen wird. Wenn man Tausende dieser Zyklen pro Tag ausfuehrt, summiert sich diese Differenz zu Stunden eingesparter Zeit und deutlich niedrigeren LLM-API-Kosten durch weniger verschwendete Token.

Was als Naechstes kommt

Agentor befindet sich in aktiver Entwicklung, und unsere Roadmap spiegelt die Prioritaeten wider, die wir von Early Adoptern und aus unserem eigenen internen Einsatz hoeren.

• Language-Server-Integration -- Tiefe Integration mit VS Code und anderen IDEs ueber das Language Server Protocol, die es Agentors Codegenerierungsagenten ermoeglicht, als intelligente Coding-Assistenten mit vollstaendigem Projektkontext zu agieren.
• Verteilte Agentenorchestrierung -- Multi-Node-Agentenausfuehrung mit automatischer Arbeitsverteilung, Fehlertoleranz und State-Replikation fuer Enterprise-Scale-Deployments.
• Visueller Pipeline-Editor -- Ein browserbasiertes Tool zum visuellen Entwurf von Agenten-Workflows, mit Drag-and-Drop-Komposition von Tools, Providern und Orchestrierungsmustern.
• Erweiterte Sprachunterstuetzung -- AST-aware Transformationen unterstuetzen derzeit Rust, TypeScript und Python. Wir fuegen Go, Java und C# hinzu, um die gaengigsten Enterprise-Sprachen abzudecken.
• Open-Source-Release -- Wir bereiten Agentor fuer die oeffentliche Veroeffentlichung unter einer permissiven Open-Source-Lizenz vor. Die Core-Crates, Dokumentation und Beispielprojekte werden auf GitHub verfuegbar sein.

Was als Sicherheitsaudit begann, ist zur Grundlage geworden, wie wir KI-betriebene Systeme bei Xcapit bauen. Agentor ist nicht nur ein Framework, das wir an Kunden verkaufen: Es ist das Framework, das wir intern fuer unsere eigene AI-Agent-Entwicklung, unsere Codegenerierungs-Workflows und unsere compliance-kritischen Deployments verwenden. Jede Verbesserung, die wir vornehmen, ist in unserer eigenen Produktionsumgebung kampferprobt, bevor sie jemand anderem erreicht.

Die Lektion aus dieser Reise ist eine, die wir im Software-Engineering immer wieder neu lernen: Wenn das Fundament falsch ist, kann kein noch so grosser Patch es reparieren. Manchmal ist die verantwortungsvolle Entscheidung, mit den richtigen Beschraenkungen, der richtigen Sprache und der richtigen Architektur von vorne zu beginnen. Agentor ist unsere Antwort auf die Frage, die wir mit Patches nicht loesen konnten: Wie baut man AI Agents, die sicher genug, schnell genug und zuverlaessig genug fuer die Systeme sind, die am meisten zaehlen?