Architecture du système

INIT Labs propose un agent codé en Rust dont le harness englobe prompts, outils et boucle d’exécution. Le cœur de l’agent, appelé core, est stocké sous forme de fichiers réels ; chaque fichier correspond à une « cellule », comme le montre la version v0.3.3. Le système possède un composant immuable nommé Root qui conserve les clés de signature, le journal des changements et la capacité d’annuler toute modification. Le Root est isolé du sandbox de l’agent et n’est accessible que via un unique socket, ce qui empêche l’agent de le toucher directement.

Lorsqu’une modification du code est proposée, elle passe par quatre portes de validation. Chaque porte exécute un test : compilation, exécution de tests unitaires, évaluation de la performance et vérification de la signature. Si l’une des portes rejette le changement, le Root le revert et consigne la décision. Les changements acceptés sont signés par le service externe qui détient la clé privée, puis injectés dans le processus en cours, ce qui permet le hot‑swap du core sans interrompre la conversation en cours.

Processus de re‑compilation et d’échange à chaud

Le mécanisme repose sur la capacité de Rust à produire des bibliothèques dynamiques rapidement. L’agent compile le nouveau core dans un répertoire temporaire, exécute les tests automatisés, puis, si le score de chaque test dépasse le seuil fixé, le binaire est chargé via dlopen et les symboles sont redirigés vers les nouvelles implémentations. Cette opération se déroule pendant la même session d’interaction, ce qui évite la perte d’état. Le fait que chaque fichier soit une cellule facilite le suivi granulaire des modifications : les fichiers modifiés sont colorés dans le tableau de bord, offrant une visibilité immédiate sur l’étendue du changement.

Analyse des risques et limites

Le modèle d’auto‑modification introduit un vecteur d’attaque inédit : si un adversaire parvient à injecter du code malveillant dans le processus de génération, le hot‑swap pourrait déployer ce code sans intervention humaine. INIT atténue ce risque en imposant la signature cryptographique et le rollback automatique, mais la confiance repose sur la robustesse du service de signature externe. De plus, le sandbox ne possède aucun API key, ce qui réduit la surface d’exposition, mais ne supprime pas la possibilité d’exploitation via des vulnérabilités du runtime Rust ou du chargeur dynamique.

Un autre point critique est la dépendance à la qualité des tests automatisés. Un changement qui passe les tests mais introduit un comportement indésirable dans des scénarios non couverts ne sera pas détecté avant d’être déployé. Le projet collecte chaque modification, signature et résultat de test dans un jeu de données destiné à étudier la corrélation entre mutation du code et stabilité du système, mais les métriques de couverture restent limitées.

Exemple de déploiement

curl -fsSL https://github.com/nagisanzenin/INIT-Agent/releases/latest/download/get.sh | sh