Die Krypto-Investmentfirmen Paradigm und Tempo haben am 21. Mai gemeinsam Centaur als Open-Source-Projekt veröffentlicht. Centaur ist ein selbstgehostetes, multi-personelles KI-Agent-Laufzeit-Framework, das seit Januar in Paradigm intern branchenübergreifend in mehreren Abteilungen wie Investments und Engineering breit eingesetzt wird. Centaur arbeitet in Form „gemeinsam genutzter virtueller Mitarbeiter“ und kann über Slack-Threads oder per API aufgerufen werden.
Sicherheitsarchitektur: Iron Proxy injiziert Zertifikate auf Netzwerkebene
Das zentrale Sicherheitsdesign von Centaur lautet: „Der Agent hält niemals API-Schlüssel.“ Sämtliche Zertifikate werden in einem isolierten Key-Management-Manager gebündelt gespeichert. Zwischen jedem Sandbox-Container und dem externen Netzwerk wird ein Iron-Proxy-Firewall-Setup eingesetzt. Wenn der Agent an eine externe API eine Anfrage sendet, identifiziert die Firewall den Zielhost, zieht die entsprechenden Zertifikate aus dem Key-Management-Manager, injiziert die Zertifikate in die ausgehenden Anfrage-Header und leitet weiter – der Agent sieht nur die API-Antwort und erhält niemals den ursprünglichen Schlüsselwert. Alle ausgehenden Anfragen werden von der Firewall protokolliert, und die LLM-API-Antwort wird in Echtzeit gescannt, um eine mögliche Offenlegung zu erkennen und zu verschleiern.
Service-orientierte Architektur: Slackbot, FastAPI, Postgres und Sandbox-Container
Centaur nutzt eine zustandslose Service-Architektur; sämtlicher Zustand wird in Postgres persistiert, sodass nach einem Neustart der Dienste kein Kontext verloren geht. Zu den Kernkomponenten gehören: Slackbot (Next.js-Webhook-Listener), FastAPI-Control-Plane (verwaltet die Sitzungslebenszyklen der Agenten sowie Tool-Endpunkte) und pro Slack-Thread eigenständige Sandbox-Container (mit vorkonfiguriertem Node.js, Python, Rust und Git; nur Zugriff auf internes Netzwerk). Die Workflow-Engine zeichnet den Aufgabenfortschritt auf Schrittebene über Postgres-Checkpoints auf. Nach einem Crash wird exakt ab dem letzten abgeschlossenen Schritt präzise wiederhergestellt, ohne bereits erledigte Arbeiten erneut auszuführen. Der Entwurf orientiert sich an der Absurd-Postgres-Driven-Architektur.
Erweiterungsmechanismus: Offene Schnittstellen für Tools, Skills und Workflows
Der Erweiterungsmechanismus von Centaur besteht aus drei Teilen. Tools (Tools) sind Python-ähnlich: Sobald sie in das tools/-Verzeichnis gelegt werden, werden sie automatisch per API entdeckt und es werden REST-Endpunkte generiert. Es gibt Hot Reloading-Unterstützung; Tools deklarieren in der pyproject.toml die benötigten API-Hosts und Zertifikate, um die Firewall-Injektion zu unterstützen. Skills sind Dateien im Pfad .agents/skills/*/SKILL.md; nach dem Hinzufügen übernimmt jede Agenten-Sitzung sie automatisch. Workflows sind Python-Dateien im workflows/-Verzeichnis; sie unterstützen cron-Zeitpläne, API-Trigger und Workflow-Kombinationen. Unternehmen können per Overlay Docker-Images einbinden und dadurch unternehmensspezifische Tools und Skills bereitstellen. Centaur führt täglich ein Selbst-Reflecting aus und verbessert automatisch Skills und Tools, ohne den Kerncode zu ändern.
Häufige Fragen
Wie stellt Centaur sicher, dass API-Schlüssel nicht vom Agent gestohlen werden?
Alle API-Schlüssel werden zentral in einem isolierten Key-Management-Manager gespeichert; der Agent hält die Schlüssel weder in Umgebungsvariablen noch auf der Festplatte noch im Speicher. Die Iron-Proxy-Firewall injiziert Zertifikate auf Netzwerkebene, und Netzwerkregeln erzwingen, dass sämtlicher ausgehender Traffic durch die Firewall laufen muss; alle ausgehenden Anfragen werden protokolliert und gescannt. Selbst wenn der Agent einem Injektionsangriff in Echtzeit ausgesetzt ist, kann der Angreifer die Schlüsselwerte nicht extrahieren.
Wie realisiert die Workflow-Engine von Centaur den Wiederanlauf nach einem Crash?
Die Workflow-Engine persistiert den Ausführungsstatus jedes Schritts in Postgres-Checkpoints. Wenn es während der Ausführung zu einem Crash kommt, startet die Engine exakt ab dem letzten abgeschlossenen Schritt wiederherstellen, ohne erneut auszuführen, und ohne Zwischenresultate zu verlieren. Wartezeiten zwischen den Schritten (z. B. 24 Stunden Schlafen) verursachen keine Ressourcen-Kosten; wenn die Engine abläuft, weckt sie den Workflow automatisch auf.
Welche Teile sind bereits Open Source, und was ist für die Zukunft geplant?
Zu den bereits Open-Source-veröffentlichten Inhalten gehören der Kernservice-Code (API, Firewall, Key-Management-Manager) sowie das Erweiterungs-Template-Repository. Die Centaur-Architektur trennt bewusst den Kern von dem Benutzerbereich (Tools, Skills, Workflows). Die offiziellen Angaben besagen, dass man in Zukunft die Fähigkeiten im Benutzerbereich weiter stärken will, aber es wurden noch kein konkreter Funktions-Fahrplan oder Zeitplan veröffentlicht.
