Un agent IA a dépensé l'argent et personne ne sait qui l'a autorisé. Connaître son agent est la réponse.

Imaginez une tendance, pas un cas précis. Un client que vous avez vérifié l'année dernière connecte un assistant IA à son compte. Trois semaines plus tard, l'assistant effectue un achat coûteux, ouvre un deuxième compte ou paie un nouveau bénéficiaire. Toutes les vérifications sont concluantes : l'identifiant, le jeton et la carte étaient tous valides.

Le client répond alors : Je n'ai jamais demandé ça.

Vous consultez les journaux pour savoir qui a autorisé l'opération, et ils indiquent que c'est le client. L'agent agissait en son nom. Aucune trace des instructions du client, de la limite qu'il a fixée, ni du logiciel qui a déclenché l'opération. Aucune erreur n'a été détectée, et pourtant vous ne pouvez toujours pas répondre.

Cet écart a désormais un nom. On l'appelle « Connaître son agent », ou KYA .

Pourquoi KYC et KYB Ne répondez pas.

KYC répond à une question : cette personne est-elle bien celle qu'elle prétend être ? KYB Les deux réponses à la même question concernant une entreprise partent du principe que la partie vérifiée est bien celle qui agit.

Un agent remet en cause cette hypothèse. Cela laisse quatre questions en suspens.

1. Quel agent agit ? Pas quel client. Quel logiciel, exploité par quelle entreprise, sur quelle plateforme ?

2. De qui s'agit-il ? Quelle personne ou entreprise vérifiée se porte garante ?

3. Avec quelle autorisation ? Ce qu'on lui a dit pouvoir faire : dans quelle mesure, avec qui, et jusqu'à quand.

4. Qui en est responsable ? En cas d’achat erroné, qui supporte la perte et quels éléments de preuve permettent de trancher le litige ?

Nous n'avons pas inventé ce terme. Trulioo et PayOS ont décrit un cadre de connaissance de l'agent (KYA) avec Worldpay en août 2025. (s’ouvre dans un nouvel onglet) Le document de la Fondation OpenID sur l'identité des agents décrit le protocole KYAPay comme une extension de ce cadre. KYC et KYB La vérification « auprès de l’agent lui-même » (s’ouvre dans un nouvel onglet)fait l’objet d’une définition publiée (s’ouvre dans un nouvel onglet) par Experian en juin 2026. En octobre 2026, aucune norme unique et consensuelle ne définissait cette expression. Il s’agit d’une orientation, et non d’une spécification.

Ce que l'industrie a réellement construit

De nombreuses livraisons ont été effectuées depuis début 2025. Chaque pièce prouve quelque chose de réel et laisse une part d'incertitude.

• Mastercard Agent Pay (29 avril 2025) introduit les jetons Agentic et précise que le programme exigera que les agents IA de confiance soient enregistrés et vérifiés (s’ouvre dans un nouvel onglet) avant de pouvoir effectuer des paiements pour leurs utilisateurs. Cela prouve que l'agent est connu du réseau et garantit aux consommateurs le contrôle des achats effectués par l'agent. L'annonce ne décrit pas les modalités de cette autorisation ni les personnes autorisées à la consulter ultérieurement.

• Cloudflare a signé des agents et Web Bot Auth (28 août 2025). Une plateforme d'agents signe ses HTTP des demandes (s’ouvre dans un nouvel onglet) permettant à un site web de vérifier quel agent appelle. IETF Le groupe de travail chargé de normaliser ce point est explicite quant à sa limite : « l’authentification de l’utilisateur final n’est pas concernée » (s’ouvre dans un nouvel onglet) . Il répond à la première question et s’arrête délibérément là.

• Protocole de paiement des agents de Google, AP2 (16 septembre 2025). Réponse la plus directe aux questions trois et quatre. Un utilisateur signe un Mandat, que Google décrit comme une « preuve vérifiable des instructions d'un utilisateur » (s’ouvre dans un nouvel onglet) : un Mandat d'intention avec des limites pour les tâches déléguées, et un Mandat de panier précisant les articles et leur prix exacts. Il s'agit d'une preuve d'autorisation. L'annonce ne précise pas qui vérifie l'identité de l'utilisateur signataire.

• Protocole de commerce agentique d'OpenAI et Stripe (29 septembre 2025). Stripe émet un jeton de paiement partagé « lié à un marchand et au montant total de son panier » (s’ouvre dans un nouvel onglet) . L'autorisation est restreinte et difficilement détournable. Elle ne couvre que l'achat que l'acheteur vient de confirmer, et non une délégation permanente.

• Protocole Visa Trusted Agent (14 octobre 2025). Développé avec Cloudflare, il permet aux agents agréés de transmettre au commerçant leurs intentions, l'identification du client et les informations de paiement (s’ouvre dans un nouvel onglet) . Cela permet au commerçant de distinguer un véritable agent d'un robot et de vérifier si le client est déjà connu. Les informations communiquées par le client à l'agent ne font pas partie des trois éléments requis.

• x402. Une norme de paiement pour HTTP dont le site promet « Aucun compte ni information personnelle requis » (s’ouvre dans un nouvel onglet) . C'est un choix de conception diamétralement opposé : un paiement sans aucune identification. Difficile de concilier cela avec l'obligation de connaître son client.

En coulisses, la communauté identitaire travaille plus lentement.

• Le livre blanc de la Fondation OpenID (s’ouvre dans un nouvel onglet) (7 octobre 2025) indique que les normes actuelles sécurisent déjà de nombreuses utilisations d'agents, puis énumère leurs lacunes. Son principal argument : « L'usurpation d'identité par des agents doit être remplacée par une délégation d'autorité. » (s’ouvre dans un nouvel onglet) Il met également en garde contre le risque que les utilisateurs soient confrontés à des milliers de demandes d'approbation et commencent à approuver par réflexe, que les agents qui sous-traitent des tâches à d'autres agents créent des chaînes d'exécution non contrôlées, et que les agents qui pilotent un contournement du navigateur API contrôle entièrement.

• Un individu IETF Le projet (s’ouvre dans un nouvel onglet) de paramètres OAuth proposant d'indiquer l'agent dans la requête de consentement et dans le jeton est désormais caduc : il s'agit d'une idée, et non d'une norme.

• La spécification d'autorisation du protocole MCP (s’ouvre dans un nouvel onglet) (la révision de juin 2025 que nous avons consultée) s'appuie sur OAuth 2.1 et limite la validité des jetons à un seul serveur. Elle précise également que l'autorisation est facultative pour les implémentations.

En résumé : le secteur est de plus en plus capable de prouver quel agent appelle et commence à prouver ce qu’un utilisateur a approuvé. Cependant, personne n’a encore établi de lien entre ces éléments et un responsable vérifié, ni de réponse consensuelle quant à la responsabilité.

Ce qu'ont déclaré les autorités de réglementation : pas grand-chose pour l'instant

Nous avons cherché des règles et nous avons surtout trouvé des intentions.

• Le Royaume-Uni FCA Dans son rapport « Priorités réglementaires en matière de paiements » (s’ouvre dans un nouvel onglet) de mars 2026, l'agence a indiqué que sa collaboration avec le Trésor « consistera notamment à examiner la nécessité de modifier ou d'élaborer une réglementation pour soutenir les paiements par IA automatisée » . Elle examine cette question, sans toutefois prendre de décision.

• À Singapour, un groupe industriel travaillant sous l'égide d'un MAS L'initiative a publié le 3 juillet 2026 le document « Garanties pour la finance agentique en temps réel ». (s’ouvre dans un nouvel onglet) Ce document propose de vérifier chaque action d'un agent avant son exécution, depuis l'identification de l'agent jusqu'à la création d'un journal d'audit en mode ajout uniquement. Il précise (s’ouvre dans un nouvel onglet) que ce document « ne constitue ni une orientation réglementaire ni une exigence de supervision ».

• Le FSB consultés en juin 2026 sur les bonnes pratiques pour une adoption responsable de l'IA, ils précisent qu'elles « ne visent pas à établir une norme internationale » (s’ouvre dans un nouvel onglet) .

Nous avons cité le Royaume-Uni, Singapour et un organisme mondial, mais pas votre régulateur. Nous n’avons pas pu consulter le document du FATF sur l’IA et n’en décrivons donc pas le contenu. Dans les documents consultés, en octobre 2026, aucune règle n’indique comment vérifier un agent. Les obligations existantes de connaître son client et de prouver le consentement restent applicables.

Ce qui reste inchangé

Abstraction faite des protocoles, un fait demeure : un agent n'a ni argent, ni statut légal, ni rien à perdre. Chaque agent agit pour le compte d'une personne ou d'une entreprise, et c'est ce mandant que vous recrutez, que vous sélectionnez et vers qui vous vous tournez en cas de problème.

Ainsi, les fondements de KYA est ordinaire KYC et KYB Ce qui est nouveau se trouve au-dessus :

• Liaison contraignante. Un lien durable et vérifiable entre cet agent et ce mandant vérifié.

• Étendue du document. Un compte rendu de ce que le mandant a autorisé, suffisamment précis pour permettre une comparaison avec les actions du mandataire.

• Présence. Un moyen de remettre l'humain au centre lorsque les enjeux s'intensifient, car une autorisation permanente ne saurait tout couvrir.

• Document. Preuve de qui ou de quoi a décidé, conservée à l'époque, et qui reste parfaitement lisible un an plus tard.

Que faire maintenant

L'achat ou la possession de biens comporte des risques. Prenez ces décisions avant que vos clients ne les prennent à votre place.

• Autoriserez-vous les agents à intervenir sur les comptes clients, et pour quelles actions ?

• Pouvez-vous aujourd'hui faire la différence entre une session avec un agent et une session avec un humain ? Si ce n'est pas le cas, c'est là le premier problème.

• Quel est le montant ou l'action au-delà duquel une confirmation humaine en personne est requise ?

• Lorsqu'un client conteste l'action d'un agent, quelles preuves détenez-vous et qui supporte la perte selon vos conditions générales ?

• Demandez à chaque fournisseur ce que son protocole d'agent prouve et ce qu'il vous laisse à disposition.

Si vous construisez, rien ici n'a besoin d'une nouvelle norme pour exister.

1. Vérifiez d'abord l'identité du mandant. Aucun agent ne peut accéder à un client ou une entreprise non vérifié(e).

2. Fournissez à l'agent ses propres identifiants. N'utilisez jamais le mot de passe ni la session du client. Émettez un jeton distinct et révocable afin que ses actions soient facilement identifiables dans vos journaux.

3. Indiquez la référence client pour chaque action. Chaque paiement, connexion ou modification effectuée par l'agent doit mentionner le client pour lequel il agit et préciser que l'opération provient d'un agent.

4. Chaque action doit être notée, et pas seulement la session. Un agent disposant d'un jeton valide peut toujours effectuer une action que le client n'entreprendrait jamais.

5. Au-delà d'un certain seuil, une intervention humaine est nécessaire. Nouveau bénéficiaire, montant important, changement de coordonnées : adressez-vous directement à la personne concernée, et non à un intermédiaire.

6. Consignez la décision dès qu'elle est prise. Indiquez la demande formulée, la permission accordée et l'autorité décisionnaire.

Que regarder ?AP2 les mandats et les jetons d'agents des réseaux de cartes convergent, IETF Les documents Web Bot Auth, les travaux du Trésor britannique sur les règles de paiement et les versions finales de MAS et FSB papiers.

Ce qui existe aujourd'hui à Toden

Pour être clair : Toden n'a pas de vérification par agent ou KYA Nous proposons ce produit aujourd'hui. Nous ne vérifions pas les agents, ne délivrons pas d'agréments d'agent et ne validons pas les mandats. Notre activité actuelle concerne le mandant et l'action.

• Vérifiez le principal. Vérification d'identité pour les personnes physiques et vérification d'entreprise pour les sociétés, chaque information étant stockée en regard de la vôtre.externalUserId, donc le client que vous avez vérifié est bien le même enregistrement que celui que vous examinez et surveillez.

• Veuillez reconfirmer la présence de la personne. Un processus de réauthentification faciale compare un selfie pris en direct avec le visage enregistré par le client. Une étape supplémentaire consiste à envoyer un défi hébergé ; vous ne pouvez poursuivre que lorsque celui-ci est réussi. Nous avons abordé ce sujet dans les sections « Prise de contrôle de compte » et « Étape supplémentaire » .

• Décidez de chaque action. Envoyez une transaction ou une activité (connexion, ajout d'un bénéficiaire, versement, etc.) et recevez une réponse : autorisation, examen ou blocage. Consultez la section « Envoi d'événements » pour un score en temps réel .

• Conservez une trace de la personne ayant pris la décision. Chaque modification de statut d'une vérification est enregistrée avec sa source : un réviseur, votre système d'administration. API Une clé ou un flux de travail. Les décisions antérieures sont conservées. Les graphes de décision expliquent comment les règles sont enregistrées.

• Documentation conçue pour les agents de développement. Chaque page est au format Markdown, unllms.txtindex, contrats OpenAPI, invite d'intégration et documentation MCP serveur (s’ouvre dans un nouvel onglet) . Ce serveur recherche la documentation et n'exécute aucune commande. API Appels. Une solution compatible avec votre compte est en cours de développement mais n'est pas encore disponible.

Les limites sont importantes. Toden Il est impossible de déterminer si une action provient d'un agent, sauf si vous nous communiquez cette information. Device Intelligence signale les émulateurs, les défaillances d'intégrité des applications et les réseaux d'hébergement, ce qui peut indiquer une automatisation, mais ne permet pas d'identifier un agent. La réussite d'une authentification confirme la présence d'un agent, mais pas ce qu'il a compris.

Ce que nous pensons devoir être construit

Cette section reflète notre point de vue. Il ne s'agit ni d'une annonce de produit, ni d'une feuille de route, ni d'un engagement.

Nous pensons que l'infrastructure de confiance a besoin d'un quatrième pilier à côté KYC , KYB et les décisions relatives aux risques.

• L'identité du mandant est toujours vérifiée et le lien est contrôlable. Un titre d'agent qui ne peut être rattaché à une personne ou une entreprise vérifiée a très peu de valeur.

• L'autorisation est une donnée, pas une case à cocher. Il s'agit d'un accord signé précisant le montant, la contrepartie et la date d'expiration, que le destinataire de la demande peut consulter et comparer avec l'action effectuée.

• La présence se mesure à l'enjeu. Les actions courantes sont menées avec l'autorisation habituelle. Les actions inhabituelles, quant à elles, redonnent une dimension humaine, avec une vérification réelle de leur identité.

• Le compte rendu est établi avant l'action, et non après. Quel agent, pour qui, avec quelle autorisation, et par qui ?

• L'identité de l'agent et l'identité du client se rencontrent. Aujourd'hui, les protocoles des agents et les KYC L'enregistrement en direct se fait sur différents systèmes. Le partenaire qui détient déjà le client vérifié est l'endroit idéal pour les rejoindre.

Rien de tout cela ne rend un mauvais achat impossible. Cela permet simplement de répondre à la question posée en tête de cet article.

Ceci ne constitue pas un avis juridique. Le domaine évolue rapidement, les documents réglementaires cités ici sont des consultations ou des propositions, et certains détails peuvent avoir changé depuis octobre 2026.

Vous voulez commencer par la partie existante ? Ouvrez un Toden espace de travail (s’ouvre dans un nouvel onglet) ou dirigez votre agent de codage vers la documentation (s’ouvre dans un nouvel onglet) .