La société d’investissement en cryptomonnaies Paradigm et Tempo ont publié en open source, le 21 mai, Centaur, un framework d’exécution d’AI Agent auto-hébergeable et collaboratif à plusieurs, largement utilisé au sein de Paradigm dans plusieurs départements (investissements, ingénierie, etc.) depuis janvier. Centaur fonctionne sous la forme de « virtual employees partagés », qui peuvent être appelés via des threads Slack ou via une API.
Sécurité : Iron Proxy injecte des identifiants au niveau réseau
La conception de sécurité centrale de Centaur est la suivante : « l’Agent ne détient jamais de clé API ». Tous les identifiants sont centralisés dans un gestionnaire de clés isolé, et entre chaque conteneur de sandbox et le réseau externe est déployé un pare-feu Iron Proxy. Quand l’Agent envoie une requête à une API externe, le pare-feu identifie l’hôte cible, récupère le(s) identifiant(s) correspondant(s) depuis le gestionnaire de clés, injecte les en-têtes de la requête sortante puis la transfère : l’Agent ne voit que la réponse de l’API, et n’obtient jamais la valeur des clés originales. Toutes les requêtes sortantes sont enregistrées par le pare-feu ; la réponse des API LLM est scannée en temps réel pour détecter d’éventuelles fuites et les masquer.
Architecture : Slackbot, FastAPI, Postgres et conteneurs de sandbox
Centaur adopte une architecture de services sans état : tout état est persisté dans Postgres, et si les services redémarrent, le contexte n’est pas perdu. Les composants clés incluent : Slackbot (un écouteur webhook Next.js), le plan de contrôle FastAPI (qui gère le cycle de vie des sessions d’Agent et les points d’accès des outils), ainsi que des conteneurs de sandbox indépendants pour chaque thread Slack (préinstallés avec Node.js, Python, Rust et Git, avec accès limité au réseau interne). Le moteur de workflow consigne l’avancement des tâches par checkpoints de niveau étape via Postgres ; après un crash, il reprend avec précision à partir de la dernière étape terminée, sans exécuter à nouveau les travaux déjà achevés. L’inspiration pour la conception vient de l’architecture pilotée par Postgres d’Absurd.
Mécanisme d’extension : interfaces ouvertes pour outils, compétences et workflows
Le mécanisme d’extension de Centaur se compose de trois parties. Les outils (Tools) sont de type Python : une fois ajoutés dans le répertoire tools/, ils sont découverts automatiquement par l’API et des endpoints REST sont générés ; ils prennent en charge le hot reload. Les outils déclarent, dans pyproject.toml, les hôtes d’API et les identifiants nécessaires afin de s’adapter à l’injection par le pare-feu. Les compétences (Skills) sont des fichiers .agents/skills/*/SKILL.md : une fois ajoutées, chaque session d’Agent hérite automatiquement. Les workflows (Workflows) sont des fichiers Python dans le répertoire workflows/ : ils prennent en charge l’exécution planifiée cron, le déclenchement par API et la composition de workflows. Les entreprises peuvent monter des images Docker via Overlay, pour fournir des outils et compétences spécifiques à leur entreprise. Centaur exécute chaque jour une auto-réflexion : sans modifier le code central, il améliore automatiquement les compétences et les outils.
Questions fréquentes
Comment Centaur s’assure que les clés API ne sont pas volées par l’Agent ?
Toutes les clés API sont centralisées dans un gestionnaire de clés isolé ; l’Agent ne détient aucune clé dans les variables d’environnement, sur le disque ou en mémoire. Le pare-feu Iron Proxy injecte les identifiants au niveau réseau ; la politique réseau impose que tout le trafic sortant passe par le pare-feu. Toutes les requêtes sortantes sont enregistrées et scannées. Même si l’Agent subit une attaque d’injection en temps réel, l’attaquant ne peut pas extraire les valeurs des clés.
Comment le moteur de workflow de Centaur réalise-t-il la reprise après crash ?
Le moteur de workflow persiste l’état d’exécution de chaque étape dans des checkpoints Postgres. En cas de crash pendant l’exécution, le moteur reprend avec précision à partir de la dernière étape terminée, sans réexécuter et sans perdre les résultats intermédiaires. Les temps d’attente entre les étapes (par exemple une mise en sommeil de 24 heures) n’entraînent aucun surcoût de ressources ; lorsque le délai arrive à expiration, le moteur réveille automatiquement le workflow.
Que contient la partie déjà open source, et quels sont les projets pour la suite ?
Les éléments open source incluent le code des services principaux (API, pare-feu, gestionnaire de clés) ainsi que le dépôt de modèles d’extension. L’architecture de Centaur sépare volontairement le noyau et l’espace utilisateur (outils, compétences, workflows). L’officiel indique que les plans futurs consistent à renforcer davantage les capacités de l’espace utilisateur, mais aucune feuille de route fonctionnelle ou calendrier précis n’a encore été publié.
