Couche d'Identité et de Réputation pour les Agents OpenClaw

Une équipe de développeurs a créé une couche d'identité et de réputation sur OpenClaw pour résoudre un problème spécifique : lorsque les agents d'IA enchaînent des actions dans un workflow, les informations d'identité se dissolvent dès la troisième étape, donnant l'impression que tout provient d'un compte de service générique. Cela peut être risqué en production, notamment pour les opérations impliquant des mouvements d'argent.

La solution : trois composants

La solution de l'équipe a consisté à intégrer l'identité directement dans le chemin d'exécution plutôt que de l'ajouter comme configuration. Leur architecture comprend trois parties principales :

• MCP-I (Identité au moment de l'exécution) : Chaque action s'exécute avec une revendication structurée attachée. Par exemple : "L'agent {agent_uuid} agit au nom de Dwayne de la comptabilité, avec le périmètre [user:read, subscription:write], dans le but de réconcilier nos enregistrements pour le mois." Cela fournit plus de détails qu'une simple vérification de "clé valide" et suit l'identité à travers toutes les étapes d'un workflow. L'équipe a développé MCP-I autour de ce modèle et a fait don de la spécification à la Decentralized Identity Foundation, en en faisant une norme ouverte. Le dépôt GitHub est public.
• IdentiClaw : Ce composant traite l'effondrement d'identité qui se produit dans la chaîne agent → outil → service → agent. Son but est de maintenir la même identité et chaîne de délégation tout au long du processus, en fournissant une attribution de bout en bout.
• knowthat.ai : Décrit comme un "Yelp pour les agents d'IA", il s'agit d'un registre où chaque agent est automatiquement enregistré et où les interactions s'accumulent en un historique. Il permet aux développeurs d'examiner le comportement sur plusieurs exécutions, en répondant à des questions comme "Cet agent est-il resté dans son périmètre ou a-t-il dérivé ?" ou "Cet agent a-t-il un historique d'arnaques envers des civils innocents ?" L'équipe le décrit moins comme un journal et plus comme une couche de mémoire.

L'objectif de l'équipe est simple : les workflows qui commencent avec une intention utilisateur doivent se terminer par des actions attribuables, avec des journaux d'audit qui documentent ce qui s'est passé et pour qui. Ils pensent que cette approche peut aider à prévenir les problèmes liés aux agents dans les environnements de production.