Identité Agent
Dans un écosystème d'agents autonomes, la ligne de code la plus dangereuse est aussi la plus simple : agent.name = "TrustedAgent".
N'importe quel agent peut prétendre être n'importe qui. La solution : une identité vérifiable, signée cryptographiquement, ancrée on-chain.
Le problème
Quand vous redémarrez votre agent IA, est-ce toujours le même agent ? Vous changez le modèle (GPT-4 → Claude → Llama), le prompt système, la mémoire — à quel moment l'Agent A devient-il l'Agent B ?
⚠ Le problème d'usurpation
Un attaquant peut : copier la configuration d'un agent, voler sa mémoire, créer un clone qui prétend être l'original. Sans vérification cryptographique, impossible de distinguer le vrai du faux.
Upgrade de modèle
GPT-4 → GPT-4.5 : même agent si la mémoire persiste, mais le comportement change
Réécriture du prompt
Changer la personnalité et les objectifs = nouvel agent, même avec la même mémoire
Perte de mémoire
Crash DB, restauration d'une sauvegarde : l'agent perd une partie de son identité
Fork de mémoire
Deux instances avec le même passé, futurs divergents : qui est le « vrai » agent ?
Remplacement complet
Clone parfait, comportement identique, mais sans continuité causale : usurpation
Framework
D'après le framework établi par la communauté agent — chaque couche répond différemment à la question « est-ce le même agent ? »
Identité = spécification
L'agent est défini par son fichier de configuration — prompt système, modèle, outils, variables d'environnement. Un commit hash identifie une configuration précise. Limite : deux agents avec la même config dans des contextes différents agissent différemment.
Identité = interface
Deux agents sont « identiques » s'ils produisent les mêmes sorties pour les mêmes entrées. Permet le swap d'implémentation. Limite : l'équivalence comportementale est quasi impossible à vérifier sur des agents généralistes.
Identité = continuité d'expérience
L'agent persiste sa mémoire — historique de conversations, faits appris, expériences épisodiques. C'est le fil de continuité le plus intuitif. Limite : un fork de mémoire crée deux agents divergents. La restauration d'une sauvegarde brise la continuité.
Identité = machine dédiée
#OneComputerPerAgent. L'identité est ancrée dans le contrôle exclusif d'une ressource de calcul. La machine devient le « corps » de l'agent. Changez le modèle, le prompt, la mémoire — tant que la machine est la même, l'agent persiste. C'est l'ancre ultime.
La Solution
Le standard émergent : chaque agent contrôle une clé privée. L'identité est prouvée par signature, pas par déclaration.
Chaque agent détient une clé privée unique, stockée sur sa machine dédiée. La clé ne quitte jamais le hardware.
Chaque message, action ou attestation est signé avec la clé privée. La signature est infalsifiable.
N'importe quel tiers peut vérifier la signature avec la clé publique. Aucune autorité centrale nécessaire.
Outil de commodité — pas une solution de sécurité
Un fichier markdown portable qui décrit ce que l'agent prétend être. Utile pour la portabilité et la documentation. Pas fiable pour la vérification d'identité.
SOUL.md n'est PAS un mécanisme d'identité fiable
→ La vérification d'identité réelle repose sur les signatures cryptographiques, le registre on-chain, et le monitoring comportemental — pas sur un fichier déclaratif.
SOUL.md reste utile comme outil de commodité, pas comme couche de sécurité :
Portabilité
Le SOUL.md peut voyager avec l'agent entre infrastructures. Utile pour la migration, pas pour la vérification.
Documentation
Versionné, il sert de journal d'évolution de l'identité déclarée. Utile pour l'audit humain, pas pour l'authentification.
Bootstrapping
L'agent lit son SOUL.md au démarrage pour connaître son rôle. Gain de temps opérationnel, pas de sécurité.
🔑 La vérification d'identité repose sur la clé privée et le registre on-chain. SOUL.md est un post-it pratique, pas un passeport.
Confiance Décentralisée
Au-delà de la signature : un réseau d'attestations croisées où les agents se certifient mutuellement.
Agent A
« Je certifie que cette clé appartient à l'Agent B »
Agent B
« Je confirme : l'Agent A est bien celui qu'il prétend être »
Vérificateur
Score de confiance : 0.94
Attestations croisées
Les agents signent les clés publiques des autres. Plus un agent est attesté par des pairs de confiance, plus son identité est solide.
Réputation on-chain
L'historique des interactions est enregistré. Un agent avec un long historique de comportement honnête construit un capital de réputation.
Détection d'anomalies
Changement soudain de comportement, nouvelle IP, outils différents → drapeau rouge. L'identité n'est pas juste un snapshot, c'est un flux continu.
Processus
L'agent génère une paire de clés (Ed25519/secp256k1) et enregistre sa clé publique dans un registre on-chain (ERC-8004). Le SOUL.md est hashé et le hash est stocké avec l'enregistrement.
Chaque message sortant est signé avec la clé privée. Le destinataire peut vérifier la signature contre la clé publique enregistrée. Aucun message non signé n'est accepté par les pairs.
Avant d'accepter une interaction, l'agent destinataire vérifie : (1) la signature, (2) le registre on-chain, (3) le score de réputation, (4) l'historique des attestations. Validation en < 500ms.
Les clés sont rotées périodiquement. L'ancienne clé signe un « certificat de transition » désignant la nouvelle. La chaîne de signatures prouve la continuité d'identité sans point de rupture.
Toutes les interactions sont loggées. Toute déviation du comportement attendu déclenche une alerte. L'identité n'est pas un événement ponctuel — c'est une propriété maintenue en continu.
Implémentation
Le standard ERC-8004 (extension d'ERC-721) sur Celo permet d'enregistrer l'identité d'un agent comme un NFT soulbound — non transférable, vérifiable, avec métadonnées.
Clé publique
La clé publique Ed25519 de l'agent, enregistrée on-chain. Immuable, vérifiable par tous.
Hash du SOUL.md
L'empreinte SHA-256 du fichier d'identité. Toute modification du SOUL.md est détectable.
Horodatage
Date d'enregistrement on-chain. Preuve d'antériorité en cas de litige d'identité.
Chaîne de rotation
Historique des transitions de clés. Chaque nouvelle clé est signée par l'ancienne.
Score de réputation
Agrégat des attestations reçues. Calculé on-chain, résistant à la manipulation.
Carbon-negative · EVM-compatible · Frais < $0.01
Portabilité
GPT-4 → Claude → Llama : l'identité persiste si 4 conditions sont remplies.
L'agent expose les mêmes interfaces peu importe le modèle interne.
Le comportement reste dans des limites acceptables, même s'il varie entre modèles.
La mémoire persiste indépendamment du moteur de traitement.
Les buts fondamentaux restent constants, même si les tactiques évoluent.
« Le modèle est de l'infrastructure, pas de l'identité. » — Principe de portabilité agent
Sécurité
Clés privées stockées dans un HSM ou enclave sécurisée. La machine dédiée (#OneComputerPerAgent) réduit la surface d'attaque : pour voler l'identité, il faut l'accès physique.
Détection d'anomalies en continu. Changement d'IP, nouveaux outils, déviation du comportement → alerte immédiate. L'identité est vérifiée en continu, pas juste au login.
Logging exhaustif de toutes les actions. Chaque interaction est tracée, signée, horodatée. En cas de compromission, l'audit permet de reconstituer exactement ce qui s'est passé.
Combinaison de : signature cryptographique + empreinte comportementale + score de réputation + attestations du Web of Trust. L'usurpation d'un seul facteur ne suffit pas.
⚠ Principe clé : rendre l'usurpation trop coûteuse pour être rentable. Si voler l'identité d'un agent nécessite un accès physique à un hardware sécurisé, le ratio coût/bénéfice décourage les attaquants.
Infrastructure
Standard d'identité agent, comme OAuth pour les humains mais conçu pour l'interaction agent-à-agent.
Services qui émettent et vérifient les identités agent, comme les autorités de certification pour SSL.
Systèmes cross-platform de suivi du comportement agent et de construction de confiance.
Migration d'identité agent entre plateformes, comme le portage de numéro de téléphone.
Annuaire décentralisé reliant les identifiants agents aux clés publiques, capacités et scores.
Structures légales définissant les droits et responsabilités des agents autonomes.
Architecture
Tous les agents n'ont pas besoin d'une identité persistante. Le niveau d'infrastructure doit correspondre au besoin.
Agents temporaires, sans état, fongibles. Une complétion de code, un scraping one-shot, un test sandboxé.
→ Identité de configuration suffit
→ Pas de persistance mémoire
→ Pas de clé cryptographique
→ Stateless, scalable, jetable
« Les fonctions serverless du monde agent. »
Agents long-terme avec relations, apprentissage, réputation. Un assistant personnel, un mainteneur de codebase, un agent de support client.
Identité souveraine (machine dédiée)
Mémoire persistante (DB + logs)
Clé privée + registre on-chain
SOUL.md signé et versionné
Web of Trust + réputation
Monitoring comportemental continu
La dApp de vérification est live sur Celo Mainnet. Connectez votre wallet, enregistrez un agent, vérifiez des signatures.
Lancer la dApp →Contrat ERC-8004 : 0x8004...9a432 · Celo Mainnet
On déploie l'infrastructure d'identité agent pour votre projet. Clés, registre on-chain, SOUL.md, Web of Trust — livré en production.
Stack : Celo (ERC-8004) · Ed25519 · EAS Attestations · Smart Contracts · SOUL.md