Sur Internet, une identité repose le plus souvent sur un identifiant et un secret, par exemple une adresse e-mail et un mot de passe. Ce modèle a été conçu pour des personnes. Les programmes qui accèdent à des services utilisent des mécanismes encore plus limités, en général une simple clé d’API, y compris lorsqu’il s’agit d’agents autonomes capables d’agir pour le compte de quelqu’un.

Cet article présente ce qui compose une identité numérique, ce qui change lorsque cette identité concerne un programme, puis comment donner à un agent autonome une identité qu’un service peut vérifier.

Ce qui compose une identité numérique

Une identité numérique repose sur trois éléments :

  • un identifiant, qui désigne quelqu’un de manière unique pour un service, comme une adresse e-mail ou un nom d’utilisateur ;
  • une preuve, qui permet de vérifier que la personne qui se présente contrôle bien cet identifiant, comme un mot de passe, un code reçu par e-mail ou une clé cryptographique ;
  • des attributs, qui décrivent la personne, comme son nom, sa date de naissance ou son rôle.

Dans un service classique, ces trois éléments sont stockés ensemble dans la base de données. Un compte ressemble par exemple à ceci :

{
  "email": "alice@example.com",
  "password_hash": "$argon2id$v=19$m=65536,t=3,p=4$...",
  "name": "Alice Martin",
  "role": "comptable",
  "email_verified": true
}

Le champ email sert d’identifiant. Le champ password_hash contient l’empreinte du mot de passe, qui sert de preuve lors de la connexion. Les champs name et role sont des attributs, et email_verified indique que le service a envoyé un code à cette adresse et que la personne l’a recopié.

Ces attributs ont une valeur très différente selon leur origine. Le nom a été saisi par la personne elle-même, et le service ne l’a jamais vérifié. Le rôle a été attribué par l’entreprise. Pour obtenir un attribut fiable, le service doit s’appuyer sur un tiers qui l’affirme et qui le signe : un employeur pour un rôle, une université pour un diplôme, l’État pour une identité civile. C’est le principe du portefeuille européen d’identité numérique, utilisé dans l’architecture de comptes sans e-mail présentée sur ce blog.

L’identité des non-humains

Les programmes aussi ont besoin d’une identité. Un site web, un script de sauvegarde ou une intégration entre deux logiciels doivent prouver qui ils sont avant d’accéder à un service. On parle alors d’identités non humaines (non-human identities).

L’exemple le plus courant est le certificat HTTPS. Lorsqu’un navigateur se connecte à un site, le serveur présente un certificat qui associe son nom de domaine à une clé publique. On peut afficher celui de ce blog avec openssl :

openssl s_client -connect blog.kaizensphere.dev:443 \
  -servername blog.kaizensphere.dev </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

À la date de rédaction de cet article, la commande affiche :

subject=CN = blog.kaizensphere.dev
issuer=C = US, O = Let's Encrypt, CN = YR2
notBefore=Aug 27 02:03:17 2026 GMT
notAfter=Nov 25 02:03:16 2026 GMT

La ligne subject contient l’identifiant, ici le nom de domaine. La ligne issuer désigne l’autorité de certification qui a signé le certificat, et les lignes notBefore et notAfter limitent sa validité. On retrouve les éléments d’une identité : un identifiant, une preuve grâce à la clé privée que seul le serveur possède, et une attestation signée par un tiers en qui le navigateur a confiance.

Pour accéder à une API, beaucoup de programmes utilisent une solution bien plus simple : une clé d’API. Un script qui importe des factures dans un logiciel de comptabilité reçoit par exemple une configuration de ce genre :

{
  "name": "import-factures",
  "api_key": "7f3a9c1e...",
  "scopes": ["*"],
  "expires_at": null,
  "owner": null
}

Ici, la clé sert à la fois d’identifiant et de preuve. Elle donne accès à tout ("scopes": ["*"]), elle n’expire jamais ("expires_at": null) et elle n’est rattachée à aucun responsable ("owner": null). Toute personne ou tout programme qui récupère cette clé peut donc agir à la place du script.

Ces limites viennent de trois différences avec l’identité d’une personne :

  • un programme agit pour le compte de quelqu’un, et le service doit donc savoir qui est responsable de ses actions ;
  • un programme peut être créé pour une tâche puis supprimé quelques minutes plus tard, et ses droits doivent avoir la même durée ;
  • les programmes sont nombreux, et le Forum économique mondial relevait en octobre 2025 que les agents IA multiplient ce type d’identités, souvent avec des accès larges et durables.

Le cas des agents autonomes

Ces trois différences deviennent plus sensibles lorsque le programme choisit lui-même ce qu’il fait. Un agent autonome reçoit un objectif, décide des étapes et enchaîne les appels : consulter des factures, vérifier un solde, préparer un paiement. Son comportement dépend de la situation, et une même clé lui sert pour toutes ces actions.

Prenons un agent chargé de traiter les factures d’une entreprise. Avec une clé d’API, le service de comptabilité qu’il appelle sait seulement que la requête vient de quelqu’un qui possède la clé. Il ignore quel agent agit, pour le compte de quel service, et jusqu’où cet agent peut aller.

Le service a donc besoin de trois réponses : quel agent s’adresse à lui, pour le compte de qui il agit, et ce qu’il a le droit de faire. Ces vérifications sont regroupées sous le nom Know Your Agent, par analogie avec le Know Your Customer des banques, et la Decentralized Identity Foundation y consacre une spécification.

Principe des attestations vérifiables

Une attestation vérifiable (Verifiable Credential, ou VC) est un document signé par un émetteur, qui affirme des attributs sur un sujet. Son format est défini par le modèle de données VC 2.0 du W3C. Le mécanisme fait intervenir trois rôles :

  • l’émetteur, qui signe l’attestation ;
  • le porteur, qui la conserve et la présente ;
  • le vérificateur, qui contrôle la signature avant d’accepter les attributs.

Toute organisation peut émettre une attestation : une université pour un diplôme, un employeur pour un rôle, un État pour une identité civile. Le fonctionnement rappelle celui du certificat HTTPS, où le navigateur accepte une signature parce qu’il fait confiance à l’autorité qui l’a produite. Ici, c’est le vérificateur qui décide des émetteurs qu’il accepte, et pour quels attributs.

Une attestation désigne toujours son sujet par un identifiant. Avant de décrire les droits de l’agent, il faut donc lui en donner un, avec la preuve qui va avec.

Donner un identifiant à un agent autonome

Cet identifiant doit rester stable et s’appuyer sur une clé que seul l’agent contrôle. Le W3C définit pour cela les Decentralized Identifiers (DID), dont la spécification est une recommandation depuis 2022. Un DID pointe vers un document qui publie les clés publiques de son titulaire.

Pour l’agent de traitement des factures, l’identifiant peut par exemple être :

did:web:example.com:agents:factures

La méthode did:web indique que le document est publié sur un site web, ici à l’adresse https://example.com/agents/factures/did.json. L’identifiant dépend donc du nom de domaine de l’entreprise, qui en garde la maîtrise. KYA-OS accepte cette méthode et did:key, qui dérive l’identifiant de la clé publique elle-même.

Ce document contient les informations suivantes :

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:web:example.com:agents:factures",
  "controller": "did:web:example.com",
  "verificationMethod": [
    {
      "id": "did:web:example.com:agents:factures#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:web:example.com:agents:factures",
      "publicKeyJwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }
    }
  ],
  "authentication": ["did:web:example.com:agents:factures#key-1"]
}

Le champ id reprend l’identifiant de l’agent. Le champ controller désigne l’entreprise, qui peut modifier ce document. Le bloc verificationMethod contient la clé publique de l’agent, et authentication indique que cette clé sert à prouver son identité.

Concrètement, lorsque l’agent signe une requête avec sa clé privée, le service récupère ce document, lit la clé publique et vérifie la signature. L’identifiant et la preuve sont désormais séparés, contrairement à la clé d’API.

Décrire les droits de l’agent dans un mandat

Les droits de l’agent sont décrits dans une attestation émise par l’entreprise. KYA-OS lui donne un nom, la delegation credential, et deux formes possibles. Celle reprise ici s’appuie sur ZCAP-LD, un format de capacités déléguées, et sur le modèle VC 2.0 :

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/security/zcap/v1",
    "https://kya-os.org/ns/delegation/v1"
  ],
  "type": ["VerifiableCredential", "DelegationCredential"],
  "issuer": "did:web:example.com",
  "validUntil": "2026-09-22T18:00:00Z",
  "credentialSubject": {
    "id": "urn:zcap:del_2026_09_22_001",
    "invoker": "did:web:example.com:agents:factures",
    "invocationTarget": "did:web:compta.example.com",
    "parentCapability": "did:web:compta.example.com",
    "allowedAction": ["invoices.read", "payments.propose"],
    "caveats": [
      { "type": "MaxAmount", "limit": "500.00", "currency": "EUR" }
    ]
  },
  "credentialStatus": {
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://example.com/status/delegations"
  }
}

Le champ issuer désigne l’entreprise qui délègue, et validUntil la fin de validité, ici le soir même.

Le bloc credentialSubject porte la délégation elle-même. Le champ invoker désigne l’agent qui pourra s’en servir, invocationTarget la ressource visée, ici l’API de comptabilité, et allowedAction la liste des actions permises, dont les noms restent propres à chaque service. Le tableau caveats ajoute des réserves, dont un plafond de 500 euros par paiement.

Le bloc credentialStatus permet de révoquer le mandat avant son expiration. Il pointe vers une liste de statuts publiée par l’entreprise. Si l’agent est compromis, l’entreprise modifie cette liste et le mandat est refusé dès la vérification suivante.

La signature de l’entreprise, ajoutée au moment de l’émission, n’est pas représentée ici.

Un mandat décrit une permission, et non une qualité de l’agent. La spécification impose cette séparation : un vérificateur rejette une delegation credential dont le sujet transporterait d’autres attributs, pour que la décision d’autorisation ne se mélange pas avec des affirmations d’identité.

Une différence avec le certificat HTTPS apparaît ici. Un certificat est présenté par le serveur qui en est le sujet, alors qu’un mandat est conservé par l’agent et présenté quand il en a besoin. Pour une personne, la même attestation se range dans un portefeuille sur son téléphone.

Un porteur peut aussi révéler seulement une partie d’une attestation. Une personne qui prouve sa majorité garde ainsi sa date de naissance pour elle. On parle de divulgation sélective, et le format SD-JWT, retenu notamment par le portefeuille européen, la permet déjà. Un mandat d’agent se prête moins à cet exercice, car le service vérifie précisément les actions autorisées et la ressource visée.

Remonter du programme jusqu’à son responsable

Lorsqu’un agent envoie une requête, par exemple une proposition de paiement, il présente son mandat et prouve qu’il détient la clé de son DID. Le service effectue alors les vérifications suivantes :

1. Résoudre le DID de l'agent et récupérer sa clé publique
2. Vérifier que la requête est signée avec cette clé
3. Résoudre le DID de l'émetteur et vérifier la signature du mandat
4. Vérifier que le champ invoker désigne bien cet agent
5. Vérifier que invocationTarget désigne bien la ressource appelée
6. Contrôler la date validUntil
7. Consulter la liste de statuts pour vérifier que le mandat est toujours actif
8. Comparer l'action demandée avec allowedAction et les caveats

Si l’une de ces étapes échoue, la requête est refusée.

Ces vérifications établissent que le mandat a bien été émis par did:web:example.com. KYA-OS appelle cette entité la partie responsable, à la racine de la chaîne de délégation, et la désigne comme comptable des actions menées en dessous d’elle. Il reste alors à savoir qui se trouve derrière cet identifiant. Le service peut s’appuyer sur une liste d’émetteurs qu’il connaît, ou demander à l’entreprise une attestation de sa propre identité, émise par un tiers.

L’entreprise a donc besoin d’un portefeuille où ranger une attestation la concernant, émise par un tiers que le service reconnaît, par exemple un registre officiel. Ce portefeuille repose sur les mêmes briques que celles décrites plus haut, et il se met en place avec les outils d’aujourd’hui. L’Union européenne en prépare une version normalisée pour les entreprises, présentée dans les nouveautés EUDI Wallet de juin 2026, avec des données d’identification vérifiées et une gestion numérique des mandats de représentation. Le service relie ainsi chaque action de l’agent à une organisation dont l’identité est attestée.

Limites

  • Un mandat indique ce que l’agent a le droit de faire, et non ce qu’il fera réellement. Le service doit donc contrôler chaque action, comme le moteur de décision présenté dans l’article sur ODRL.
  • La délégation entre agents reste un sujet ouvert. Lorsqu’un agent confie une tâche à un autre agent, le service final doit pouvoir remonter toute la chaîne des mandats. La Decentralized Identity Foundation y consacre un rapport sur l’autorité déléguée.

Conclusion

Une identité numérique repose sur trois éléments : un identifiant, une preuve et des attributs. Un compte d’utilisateur les réunit dans une base de données. Un certificat HTTPS les répartit entre un nom de domaine, une clé privée et la signature d’une autorité. Une clé d’API les confond dans un seul secret, ce qui suffit à un script et devient gênant dès qu’un agent autonome choisit lui-même ses actions.

Les briques pour faire autrement existent et sont normalisées. Un DID donne à l’agent un identifiant stable et une clé qu’il est seul à détenir. Un mandat décrit ce qu’il peut faire, sur quelle ressource, jusqu’à quand et sous quelles réserves. Une liste de statuts permet de le révoquer avant son terme. Le service vérifie l’ensemble par le calcul, sans redemander son avis à l’émetteur à chaque requête, et remonte jusqu’à l’organisation qui répond des actions de l’agent.

Le travail restant porte moins sur la cryptographie que sur l’organisation. Il faut publier un document DID par agent, émettre et signer les mandats, tenir la liste des statuts, choisir les émetteurs auxquels le service fait confiance, et rattacher l’entreprise à une identité attestée. Les spécifications restent jeunes, KYA-OS en particulier, et la délégation d’un agent à un autre demande encore des règles partagées. Un service qui reçoit déjà des requêtes d’agents peut commencer par le plus simple : un mandat de courte durée, une ressource nommée et des actions comptées.