Écrit par : Vaidik Mandloi
Compilé par : Chopper, Foresight News
Aujourd'hui, les reçus faux générés par l'IA représentent déjà 71 % de tous les cas de fraude aux dépenses signalés, alors qu'il y a un an, ce chiffre était de 0. De plus, ce type de fraude est encore majoritairement perpétré par des humains.
Désormais, nous disposons d'agents IA capables de découvrir des services et d'effectuer des paiements via x402, le tout sans aucune validation humaine. Cela soulève une question épineuse : comment vérifier ce que ces agents intelligents ont réellement acheté. OpenAI a récemment publié un guide pratique proposant une solution pour intégrer la vérification des reçus et la réconciliation tierce dans le processus de paiement.
C'est actuellement la solution de vérification de la fraude la plus proche de l'opérationnel que nous ayons vue pour les paiements par agent. Cet article décompose la logique complète de ce mécanisme de vérification : un enregistrement de règlement sur la blockchain peut-il prouver que l'agent a acheté le bon produit, au bon prix, auprès d'un fournisseur légitime ? Ou ne fait-il que prouver qu'un transfert de fonds a eu lieu ?
Mécanisme de vérification de la fraude
Les agents IA exécutent déjà de manière autonome des actions d'achat. Un agent chargé des achats peut payer pour accéder à une API de données, utiliser la puissance de calcul d'un autre grand modèle pour traiter des données qu'il ne peut pas traiter lui-même, ou acheter des renseignements de marché derrière un paywall. Alors que ce type de transaction se multiplie, une question cruciale émerge : comment vérifier ce que l'agent a réellement obtenu.
Aujourd'hui, toutes les entreprises traitant les remboursements de frais disposent d'un processus de vérification des reçus. Lorsqu'un employé effectue un achat, il soumet un reçu ; le service des comptes créditeurs recoupe ensuite le reçu, le bon de commande et le relevé bancaire avant d'effectuer le paiement.
Ce processus, utilisé depuis des décennies, fonctionne parce qu'il repose sur un principe clé : les trois documents de vérification proviennent d'entités distinctes et indépendantes. L'acheteur émet le bon de commande, une autre partie est responsable de la réception, et le fournisseur émet la facture. Pour falsifier, il faudrait soudoyer les trois parties pour forger les documents ensemble, un coût prohibitif qui dissuade largement la fraude.
Aujourd'hui, les paiements par agent construisent un processus de vérification similaire. Lorsqu'un agent souhaite acheter auprès d'une API payante, il ne peut pas exécuter la transaction directement. La requête est d'abord envoyée à la couche applicative, qui la vérifie selon des règles de dépenses préconfigurées : liste de commerçants autorisés, plafonds budgétaires, catégories de biens autorisées. Si la requête ne respecte pas ces règles, l'achat est directement bloqué.
Une fois le paiement sur la blockchain exécuté et le service obtenu par l'agent, la couche applicative effectue une seconde vérification, en comparant trois sources d'information :
- Le contenu de l'achat auto-déclaré par l'agent
- Le reçu généré indépendamment par l'application pendant le processus d'achat
- L'enregistrement du règlement généré par la blockchain
Les reçus falsifiés sont identifiés à cette étape. Même si l'agent prétend que la transaction n'a pas eu lieu, la couche applicative conserve un enregistrement indépendant qui peut la corroborer.
Pour la détection des fraudes par agent, c'est un progrès significatif, car auparavant, aucun moyen de vérification viable n'existait. Cependant, comparé au modèle traditionnel de vérification des reçus, cette solution présente une faiblesse : dans le modèle traditionnel, les trois justificatifs proviennent de tiers sans lien entre eux ; dans le système de paiement par agent, deux justificatifs – les déclarations de l'agent et le reçu généré par l'application – proviennent du logiciel du développeur du système lui-même. Le seul justificatif externe vraiment indépendant est l'enregistrement sur la blockchain.
De plus, l'enregistrement sur la blockchain lui-même contient très peu d'informations : une signature de paiement ne mentionne que l'expéditeur, le destinataire et le montant du transfert, sans inclure d'informations sur l'objet réel de l'achat. Les métadonnées de la ressource, l'adresse d'accès, la description du contenu sont transmises avec la signature, mais ne font pas partie du champ couvert par la vérification cryptographique.
Cela signifie que cette vérification ne peut que confirmer que le contenu déclaré par l'agent correspond à l'enregistrement du transfert, mais ne peut pas vérifier ce que l'agent a réellement obtenu après avoir payé. Par exemple : un agent dépense 2 dollars pour acheter un rapport sur les risques fournisseurs ; la blockchain peut confirmer que l'USDT a été transféré ; mais le rapport livré à l'agent pourrait n'être que quelques paragraphes de texte insignifiant généré par une IA en quelques secondes. Le système complet validera tout de même la vérification, car l'autorisation est liée à l'action de transfert, et non à l'objet de l'achat lui-même.
Cela pose également un problème à l'échelle du marché. L'acheteur est un programme logiciel qui, après avoir reçu un résultat, continue à fonctionner sans évaluer activement sa qualité. L'agent n'interroge pas les systèmes de réputation et ne compare pas les offres. À moins que le développeur n'intervienne manuellement, l'agent continuera à commander auprès du même commerçant, quelle que soit la qualité de la livraison. Les vendeurs offrant des services de haute qualité perdent des clients prêts à payer une prime pour un produit supérieur ; tout le marché tendra à s'orienter vers « l'offre la moins chère capable de répondre à la requête ».
Tout système de paiement ne peut tolérer qu'un certain taux de fraude. Vouloir éradiquer complètement la fraude coûterait plus cher que les pertes dues à la fraude elle-même. Par exemple, le taux de fraude dans l'industrie des cartes de crédit est d'environ 7 points de base, un niveau considéré comme acceptable par le secteur ; si l'on tentait de réduire davantage la fraude, les pertes causées par les transactions légitimes incorrectement bloquées dépasseraient les gains obtenus en évitant la fraude.
Les paiements par agent pourraient évoluer vers une situation similaire : tolérer un certain niveau de défauts de qualité de service, en absorbant le risque grâce au volume massif des transactions autonomes. Cette logique peut être acceptable pour des scénarios de faible valeur comme les appels API, mais lorsque ce système est utilisé pour gérer des contrats d'achat à l'échelle de dizaines de milliers, et que l'agent reste incapable de déterminer s'il a reçu un service de valeur, le risque devient difficile à accepter.
Les vulnérabilités qui se révèlent
Les outils de falsification de reçus évoluent plus vite que les outils de détection des fraudes. Ramp a récemment lancé un système de comptes créditeurs basé sur l'IA, qui a signalé un grand nombre de cas de faux reçus générés par l'IA dans les 90 premiers jours. Emburse a reconnu dans une étude que des cas de génération en masse de justificatifs de fraude à l'aide de l'IA sont déjà apparus.
Dans le contexte des agents, le risque est encore amplifié. Après le règlement de la transaction, personne ne vérifie manuellement l'acte d'achat. Un article de recherche académique a étudié 15 infrastructures de paiement majeures déjà en production, et toutes présentaient des vulnérabilités de sécurité. Ces systèmes traitent des fonds pour des dizaines de milliers de commerçants, et les vulnérabilités divulguées dans l'article étaient toutes reproductibles.
La racine de ces attaques réside dans le découplage entre l'action de paiement et la livraison effective du produit. Dans un cas d'attaque au niveau de la découverte de services, les chercheurs ont simplement falsifié la liste des serveurs retournée par une requête de service, réussissant ainsi à rediriger l'agent vers un point de service malveillant. Du point de vue de l'agent, ce service ne diffère en rien d'une liste normale, et il est totalement incapable de détecter qu'il a été détourné.
Déjà, plusieurs startups tentent de résoudre ce type de problème. shturl.cc/P a levé 9,5 millions de dollars pour lancer le protocole KYA (Know Your Agent, Connaître votre Agent). Ce protocole équivaut à un KYC pour les programmes logiciels : avant tout flux de fonds, un score de confiance est établi pour les agents autonomes, et les agents malveillants non vérifiés ou à risque sont directement empêchés d'accéder à l'étape de paiement.
Mais la seule vérification d'identité ne peut pas empêcher le cas d'un commerçant légitime qui livre un contenu de mauvaise qualité. Sardine.ai se concentre sur le risque comportemental et a levé 70 millions de dollars en série C ; leur produit repose sur le profil de transaction de plus de 2 milliards d'appareils pour identifier les fraudes ; ils déploient désormais des agents IA dans leur pile de gestion des risques pour détecter les comportements anormaux difficiles à repérer par des systèmes de règles statiques.
Dans le secteur de l'infrastructure de base, Nekuda.ai a levé 5 millions de dollars. Ce projet avance que les interactions commerciales entre agents ne peuvent pas réutiliser l'ancienne architecture des transactions humaines ; il faut construire un SDK commercial spécifiquement conçu pour les transactions entre logiciels, et le modèle de confiance doit être conçu de manière native, et non ajouté après coup comme un correctif.
Aujourd'hui, la quasi-totalité des systèmes de détection de fraude existants se concentrent sur l'agent lui-même : a-t-il falsifié un reçu ? a-t-il dépassé le budget ? a-t-il déclaré un mauvais fournisseur ? Mais l'agent lui-même n'a en réalité pas de motif économique pour falsifier et en tirer profit. Les véritables acteurs ayant un motif de mal agir sont les commerçants. Les commerçants sont face à des acheteurs qui sont des programmes logiciels n'évaluant pas la qualité du service, ne comparant pas les prix et ne changeant pas de partenaire commercial de leur propre initiative.
