Know Your Agent (KYA) : vérifier l'identité des agents IA

Le prochain compte ouvert sur votre plateforme ne sera pas ouvert par un humain.

Cela ressemble à du marketing. Ça n'en est pas. En 2026, l'entité qui remplit un formulaire, appelle votre API ou tente un paiement est de plus en plus un agent d'IA autonome agissant sous les instructions d'une personne. Visa a lancé Agentic Ready comme infrastructure de paiement pour le commerce piloté par IA. Mastercard a suivi avec Agent Pay. OpenAI, Anthropic et Google livrent des runtimes d'agents avec usage d'outils, contrôle de navigateur et autorité de paiement intégrés. Le Model Context Protocol a fait de l'invocation d'outils par des agents un standard.

Votre stack KYC a été conçu pour répondre à une question : l'humain de l'autre côté est-il bien celui qu'il prétend être ? Dans un monde où l'acteur est un logiciel, cette question n'a plus de sens. Vous en avez besoin d'une autre : quel agent est-ce, qui l'a autorisé, et qu'a-t-il le droit de faire ? C'est le KYA — Know Your Agent — et le traiter comme une note de bas de page du KYC est la brèche par laquelle passeront aussi bien les fraudeurs que les auditeurs.

Ce qu'est vraiment le KYA

Le KYA est la couche de vérification pour les acteurs non humains. Il valide trois choses, dont aucune n'est optionnelle :

Identité. L'agent possède une identité cryptographique qui se résout à son propriétaire, son opérateur et son contexte d'exécution — pas un nom d'utilisateur, pas une clé d'API dans la poche de quelqu'un. C'est exactement ce pour quoi les W3C Decentralized Identifiers (DIDs) et les Verifiable Credentials ont été normalisés, appliqués à des acteurs logiciels au lieu d'humains.

Autorité. L'agent peut prouver qu'il agit dans le cadre d'un mandat que le titulaire lui a accordé : cet utilisateur a autorisé cet agent à dépenser jusqu'à ce montant dans cette catégorie de commerce pendant cette fenêtre. Autorisation de type capability, pas « faites confiance au token porteur ». La présence d'une clé n'est pas la même chose que la présence d'un consentement.

Provenance. L'agent tourne sur un modèle et un stack d'outils que vous pouvez attester — poids connus, garde-fous connus, chaîne d'approvisionnement connue. L'écosystème croissant des constructeurs d'agents, et la montée des agents d'IA autonomes en conformité, ne fonctionne que si le vérificateur en aval peut distinguer un modèle sanctionné d'un modèle jailbreaké.

Une vérification KYC vous dit « un humain s'est vérifié une fois ». Une vérification KYA vous dit « cet agent, avec ce mandat, sur ce modèle, agit en ce moment ». Elles ne sont pas interchangeables, et l'une ne subsume pas l'autre.

Pourquoi c'est urgent en 2026, pas en 2030

Trois forces ont compressé le calendrier.

Les paiements agentiques sont sortis du laboratoire. Visa Agentic Ready, Mastercard Agent Pay et les toolkits d'agents de Stripe sont désormais des rails de production qui transportent des autorisations réelles sans présence de carte émises par des agents autonomes. L'infrastructure existe ; la couche de vérification des agents est largement improvisée. La brèche que nous cartographions dans Know Your Human : la lacune KYC des paiements agentiques est la même brèche vue du côté de l'institution financière.

L'usage d'outils est la nouvelle surface d'attaque. Un agent doté d'un navigateur, d'un outil de paiement et d'une mémoire a la capacité d'action d'un employé avec carte d'entreprise — mais avec la vulnérabilité d'injection de prompt d'un chatbot. Le Top 10 OWASP pour les LLM (LLM01 injection de prompt, LLM06 gestion non sécurisée des sorties, LLM07 fuite du prompt système) décrit des attaques qui, appliquées à un agent utilisant des outils, deviennent des transactions non autorisées au lieu de texte fuité. Vérifier l'identité et le mandat de l'agent est la seule chose qui empêche un agent dont le prompt a été détourné de dépenser l'argent de son titulaire.

Les régulateurs commencent à poser la question. La loi européenne sur l'IA inclut des obligations de transparence à l'Article 50 pour les systèmes d'IA qui interagissent avec les personnes, et le cadre plus large des obligations à haut risque d'août 2026 crée une responsabilité pour les déployeurs lorsqu'un agent agit au nom de l'utilisateur. La logique de CDD continue d'AMLR ne s'arrête pas à l'humain ; si un agent déplace de l'argent, l'action de l'agent est l'événement CDD pertinent.

Si votre plateforme a au moins un client utilisant un assistant à base d'agents pour interagir avec elle — et à mi-2026 vous en avez, que vous le sachiez ou non — vous avez du trafic non humain non vérifié dans votre tunnel d'authentification.

Les trois piliers, ancrés dans des standards réels

Identité cryptographique de l'agent. Chaque agent porte un DID et un Verifiable Credential émis par son opérateur, qui à son tour lie l'agent à un titulaire. Le handshake est une présentation vérifiable, pas un token porteur. C'est la même mécanique que le déploiement du portefeuille EUDI sous eIDAS 2.0, appliquée un niveau au-dessus : le portefeuille vérifie l'humain, le credential vérifie l'agent à qui l'humain a délégué.

Vérification du mandat et de l'intention. Le Verifiable Credential que l'agent présente inclut le périmètre : montant, catégorie de commerce, juridiction, fenêtre temporelle, type d'action. Votre plateforme n'a pas à faire confiance à la déclaration de l'agent sur ce qu'il fait ; elle valide que l'action demandée est à l'intérieur du mandat signé cryptographiquement. Si l'agent tente quelque chose hors du mandat — parce qu'il a été injecté, détourné ou simplement confus — l'action échoue à la couche de vérification, pas à la file des rétrofacturations.

Provenance et réputation du modèle. Une attestation signée du runtime de l'agent — modèle de base, fine-tunes, ensemble d'outils, configuration de sécurité — liée au credential. C'est l'idée du ML-BOM (un SBOM pour le stack d'IA) rendue opérationnelle. Le motif qui défait la dynamique IA contre IA de la Fraude 4.0 à la couche de l'agent est exactement celui-ci : un agent dont le modèle est sanctionné et dont le runtime est attesté appartient à une classe de risque différente de celle d'un agent dont le runtime est inconnu.

Ces trois éléments produisent quelque chose qu'une clé d'API statique ne peut pas : un acteur vérifié à l'exécution, lié à un mandat, à provenance attestée. C'est le plancher pour laisser un non-humain exécuter des actions à conséquences sur votre plateforme.

Ce qui casse si vous le sautez

Sauter le KYA ne crée pas seulement une exposition à la fraude. Cela effondre plusieurs contrôles d'un coup.

Un utilisateur légitime délègue à un agent, l'agent subit une injection de prompt via une page web malveillante qu'il parcourt et exécute un paiement que l'utilisateur n'a pas autorisé. Sans KYA, votre système antifraude voit une transaction depuis l'appareil d'un utilisateur vérifié et approuve. Avec KYA, le paiement échoue parce que le mandat n'incluait pas « envoyer des fonds à une adresse contrôlée par l'attaquant ».

Un acteur malveillant construit un agent qui imite un agent légitime — même nom, même UX, mêmes motifs d'API. Sans KYA, les distinguer demande de l'heuristique. Avec KYA, les credentials ne valident simplement pas.

Un auditeur demande qui a effectué une action et sous quelle autorité. Sans KYA, vous pouvez montrer une session authentifiée et un identifiant d'utilisateur. Avec KYA, vous pouvez montrer la chaîne cryptographique humain → mandat → agent → action. La seconde survit à un régulateur.

La réponse en 20 points de l'industrie à la fraude d'identité par IA le reconnaît explicitement. Plusieurs de ses mesures ne fonctionnent que s'il existe une couche d'identité d'agent en dessous ; vous ne pouvez pas vous défendre contre la fraude pilotée par agents à l'échelle sans pouvoir d'abord identifier les agents.

Le KYA est la moitié supérieure de l'infrastructure d'identité

Le KYC vérifie l'humain. Le KYC 3.0 transforme cette vérification en un signal continu et prédictif. Le KYA vérifie l'agent à qui l'humain a délégué. Le KYA continu — vérifier l'agent à chaque action à conséquences, pas une seule fois — boucle la boucle.

C'est la forme de l'infrastructure d'identité pour le reste de la décennie : un humain vérifié en continu, des agents vérifiés par action, des mandats signés et révocables, et une provenance attestée jusqu'aux poids du modèle. Les fournisseurs construits autour du KYC selfie-document de l'ère 2010 devront se rétro-adapter. Les plateformes qui livrent du KYA en natif recevront le trafic agentique par défaut, parce qu'elles seront celles par lesquelles les Visa et Mastercard de ce monde pourront router du commerce agentique à conséquences sans hériter de la responsabilité.

C'est le pari de Joinble. Notre architecture de KYC agentique fonctionne déjà sur l'hypothèse que l'acteur peut être un agent ; le KYA est la couche qui rend cette hypothèse opérationnelle. Nous ne sommes pas en train de rétro-adapter des fournisseurs selfie pour l'ère des agents — nous l'avons construite pour ça.

Foire aux questions

Le KYA remplace-t-il le KYC ? Non. Le KYA repose sur le KYC. L'humain est toujours vérifié à la base du stack — le KYC 3.0 rend cette vérification continue. Le KYA vérifie l'agent à qui l'humain a délégué. L'un ne supprime pas le besoin de l'autre.

En quoi le KYA diffère-t-il de l'authentification par API ? Une clé d'API authentifie un client. Le KYA vérifie l'identité cryptographique de l'agent, le titulaire pour qui il agit, le mandat sous lequel il opère et la provenance de son modèle et de ses outils. Une clé d'API fuitée est pleinement utilisable par un attaquant ; un credential KYA volé sans le mandat avec lequel il a été signé n'accorde rien d'actionnable.

Pourquoi les W3C DIDs et Verifiable Credentials ? Parce qu'ils existent déjà comme standards, qu'ils sont déployés sous eIDAS 2.0 pour les portefeuilles humains, et qu'ils sont les seules primitives cryptographiques d'identité matures et interopérables. Construire le KYA sur le même substrat maintient l'humain et l'agent dans le même graphe d'identité au lieu de silos parallèles.

Le KYA m'oblige-t-il à changer chaque flux de connexion de ma plateforme ? Non. Le KYA est invoqué quand un agent se présente à votre plateforme — typiquement via un échange standardisé de credentials à la passerelle d'API ou à la couche d'autorisation de paiement. Les flux exclusivement humains existants restent inchangés. Le travail se fait au périmètre, pas sur chaque surface produit.

Et l'injection de prompt sur un agent vérifié ? Le KYA n'empêche pas l'agent d'être confus. Il empêche un agent confus de causer des dégâts. Si un agent victime d'injection de prompt tente d'agir hors de son mandat, la vérification échoue côté plateforme et l'action ne s'exécute pas. Le credential dit « l'agent peut dépenser dans la catégorie X jusqu'au montant Y », pas « l'agent peut faire n'importe quoi ».

Si du trafic non humain atteint votre plateforme — et c'est le cas — votre stack KYC n'est plus la réponse entière. Parlez à notre équipe du câblage du KYA dans vos couches d'authentification et de paiement avant que les régulateurs ne vous demandent pourquoi vous ne l'avez pas fait.