Identité d'agent et DID (Identifiants Décentralisés)

1. Aperçu du concept et problématique systémique

Aux débuts de l'ère des agents, les développeurs se contentaient d'exposer leurs clés API personnelles ou mots de passe dans les variables d'environnement de leurs scripts. En 2026, alors que les agents gèrent des transactions financières, pilotent des serveurs de production et interagissent avec des contreparties externes, cette approche est devenue inacceptable :

• Absence d'audit : Les logs indiquent qu'un commit a été réalisé par "Alexandre", alors qu'Alexandre dormait et que le code a été écrit par un agent autonome.
• Rayon d'action catastrophique : Si un agent est compromis via une injection de prompt, l'attaquant obtient tous les droits de l'utilisateur humain, y compris l'accès à la messagerie personnelle et aux panneaux d'administration.

Agent Identity introduit la notion d'agent en tant que sujet numérique à part entière, doté d'un passeport cryptographique, de clés publiques et de privilèges restreints.

2. Taxonomie architecturale et modèle mental

┌─────────────────────────────────────────────────────────────┐
│               AGENT IDENTITY & TRUST STACK                  │
├─────────────────────────────────────────────────────────────┤
│ 1. Cryptographic Key Management (HSM / Secure Enclave)      │
│    • Private Key (never leaves isolated memory)             │
│    • Public Key / DID URI (did:key:z6MkuT...)               │
├─────────────────────────────────────────────────────────────┤
│ 2. Verifiable Credentials & Delegation Chains               │
│    • Issuer: Human Owner (Org Root Certificate)             │
│    • Scope: "Can execute read/write on repo:app, max $10"   │
│    • Expiration: Ephemeral tokens (TTL = 1 hour)            │
├─────────────────────────────────────────────────────────────┤
│ 3. Attestation & Proof of Execution                         │
│    • Git Commit Signatures (GPG / SSH Sig)                  │
│    • Signed MCP & A2A Requests                              │
├─────────────────────────────────────────────────────────────┤
│ 4. Audit & Revocation Infrastructure                        │
│    • Instant Key Revocation (Kill Switch)                   │
│    • Immutable Append-Only Ledger for Audit Logs            │
└─────────────────────────────────────────────────────────────┘

1. DID (Decentralized Identifier) : Identifiant unique de l'agent au format W3C (par exemple, did:web:company.com:agents:devops-01), permettant à tout système de récupérer sa clé publique sans recourir à des bases de données centralisées.
2. Short-Lived Delegation (Délégation éphémère) : L'humain signe une autorisation pour l'agent valable 60 minutes. Même si l'agent échappe au contrôle, son certificat expirera automatiquement.

3. Scénarios d'ingénierie concrets en production

01. Déploiement contrôlé de l'infrastructure

L'agent reçoit un certificat temporaire pour mettre à jour un cluster Docker spécifique sur un VPS. Si l'agent tente d'exécuter une commande sur un autre serveur, la passerelle de sécurité rejette la requête en raison d'une signature invalide.

02. Signature des commits pour la conformité ISO 27001 / SOC 2

Tous les commits générés par l'IA sont marqués d'une signature distincte GPG Signed by Agent ID: 4092. Les auditeurs voient clairement quelles lignes de code ont passé une revue humaine et lesquelles ont été créées de manière autonome.

4. Pièges courants, erreurs typiques et sécurité

• Stockage des clés privées dans des fichiers accessibles : Si l'agent écrit son private_key.pem dans le répertoire de travail, un attaquant peut le voler via un appel de lecture de fichier. Les clés doivent être stockées dans un Secure Enclave ou HashiCorp Vault.
• Absence de mécanisme de révocation d'urgence (Kill-Switch) : Chaque agent doit avoir un statut de vérification d'activité : une simple modification d'un flag dans le système IAM doit annuler instantanément toutes ses signatures et tokens.

5. Conclusion stratégique pour l'ingénieur de 2026

Agent Identity fait passer le travail avec l'IA du stade d'expérimentations amateurs à celui de la sécurité d'entreprise et de la responsabilité juridique. Un agent sécurisé n'est pas simplement un modèle dans une boucle, c'est un sujet vérifié avec des frontières de confiance clairement définies.