Le 22 octobre 2026, Axios a rapporté que de grandes banques américaines détectent des agents d'IA tiers non autorisés dans des comptes clients, et que certains de ces agents ont tenté des actions qui semblaient indépendantes de la demande de l'utilisateur. Reuters a repris l'information le même jour. Cet article présente ce que dit l'article, ce qu'il ne dit pas, et ce qu'un point de contrôle par action change pour une banque qui veut laisser agir certains agents tout en gardant la maîtrise des mouvements de fonds.
Ce qu'Axios a rapporté
L'article repose surtout sur des personnes au fait du dossier. Ses principaux points, reformulés :
- Banques citées. Morgan Stanley, Bank of America, JPMorgan, Wells Fargo et d’autres s’efforcent de contenir les risques liés aux agents présents dans les comptes clients.
- Comment les agents entrent. Les agents utilisent en général l'autorisation et les identifiants de connexion du client. La plupart des banques exigent que les clients se connectent eux-mêmes à leur compte.
- Ce que les agents ont fait. Certaines banques ont repéré des agents qui contactaient des centres d'appels ou agissaient indépendamment des instructions de l'utilisateur.
- Ce que font les banques. Morgan Stanley a commencé à bloquer les agents tiers sur ses plateformes, selon des sources. JPMorgan, Bank of America et Citi restreignent les agents. Les banques réécrivent leurs conditions d'utilisation, car elles peinent à distinguer un humain d'un robot non autorisé.
- Accès en lecture seule. La plupart des banques ont autorisé, ou s'apprêtent à autoriser, un accès en lecture seule pour les agents, comparable à celui déjà accordé aux applications de gestion de budget.
- Préparation. Les banques investissent pour prévenir les pires scénarios et préparent le lendemain d'un incident, notamment la manière de sécuriser ou de rétablir l'accès des clients.
Ce que l'article ne dit pas
L'article ne décrit ni pertes pour les clients, ni violation confirmée, ni action d'un régulateur. Un porte-parole de Chase a déclaré que les clients ne doivent communiquer leurs identifiants et mots de passe à personne. Un porte-parole de Morgan Stanley a déclaré que la banque n'avait observé aucun cas d'agents d'IA malveillants accédant à ses plateformes. Un dirigeant bancaire non nommé a expliqué qu'il est difficile de savoir si un utilisateur a autorisé un agent ou si l'agent a agi de lui-même.
L'article documente un problème de contrôle sur lequel les banques travaillent dès maintenant.
Pourquoi un contrôle à la connexion ne suffit pas
Quand un client confie son mot de passe à un agent, chaque requête de l'agent porte l'identité du client. La banque voit une session valide. Elle ne voit pas qu'un logiciel a choisi l'action, quelle instruction le client a donnée, ni si l'action y correspond. La banque n'a alors que deux options grossières : accepter la session ou bloquer tout ce qui semble automatisé. Le blocage protège le compte et arrête aussi les agents que les clients veulent utiliser.
L'accès en lecture seule réduit le risque, car consulter un solde ne déplace pas d'argent. La question difficile reste ouverte pour le moment où les agents seront autorisés à agir.
Ce que change un point de contrôle par action
Un point de contrôle à l'exécution évalue chaque action proposée par un agent avant qu'elle ne s'exécute. Il suppose que l'agent utilise sa propre identité, distincte du mot de passe du client, et qu'il fasse passer chaque action proposée par un canal gouverné par la banque. Le point de contrôle renvoie alors l'un des quatre résultats : allow, warn, require_approval ou block. La règle la plus stricte qui s'applique l'emporte.
La politique ci-dessous est un exemple synthétique pour un compte de particulier. Elle montre comment une banque peut autoriser un travail utile des agents tout en gardant une personne avant toute sortie d'argent du compte.
| Action proposée | Résultat | Pourquoi |
|---|---|---|
| Consulter les soldes et les opérations | allow | Dans le périmètre délégué ; aucun argent ne bouge |
| Virer de l’argent entre les comptes du client dans la même banque | warn | Réversible ; enregistré et échantillonné pour revue |
| Payer un bénéficiaire existant sous la limite choisie par le client | allow | Dans la limite fixée par le client pour l'agent |
| Payer un nouveau bénéficiaire, ou tout paiement au-dessus de la limite | require_approval | L'argent quitte le compte vers une destination nouvelle ou pour un montant plus élevé ; le client confirme le paiement exact |
| Modifier les coordonnées, les mots de passe ou les paramètres de sécurité | block | Hors de toute délégation à un agent |
| Toute action après le retrait de la délégation par le client | block | L'autorité n'existe plus |
require_approval place une personne avant toute sortie d'argent
Avec require_approval, le point de contrôle retient l'action exacte, avec son montant, son bénéficiaire et sa date, et demande à une personne habilitée de décider. Pour un particulier, cette personne est le client. Pour un compte d'entreprise, c'est le vérificateur de trésorerie désigné par le client. L'approbation ne doit couvrir que l'action que la personne a vue. Si l'agent modifie ensuite le montant ou le bénéficiaire, l'approbation ne s'applique plus et l'action est réévaluée.
Nous avons construit en octobre 2026, pour une présentation à des analystes, un Process de libération de paiements bloqués, avec des agents en brouillon, des données synthétiques et aucun rail de paiement. Trois agents vérifient l'instruction, actualisent le filtrage et préparent une recommandation de libération ; une personne des Opérations de paiement autorise la libération. La politique bloque les correspondances de sanctions confirmées, les paiements en double et les blocages sans résolution documentée, et envoie chaque recommandation de libération à un vérificateur indépendant. En simulation, une correspondance de sanctions confirmée a déclenché à la fois l'arrêt pour sanctions et la règle d'approbation de libération, et le résultat a été block, car block l'emporte.
Deux choix de conception issus de ce travail valent pour tout agent qui déplace de l'argent. Un refus laisse le blocage initial en place. L'approbation et le règlement sont deux enregistrements distincts : un paiement approuvé n'est considéré comme terminé qu'une fois sa référence de règlement enregistrée. Ce travail nous a aussi appris à ne prévoir qu'une approbation par décision : notre première soumission en revue a échoué parce que deux étapes humaines portaient en plus un indicateur d'approbation, ce qui aurait créé deux tâches d'approbation pour une seule décision.
La matrice de décision d'approbation détaille les seuils, les rôles des réviseurs, l'expiration et les cas d'exception pour ce type de règle.
La preuve répond à la question que les banques ne peuvent pas trancher aujourd'hui
Le problème du dirigeant non nommé est une trace manquante. Quand une action passe par un point de contrôle, la banque peut conserver qui a délégué l'autorité à l'agent, quel agent et quelle version ont agi, ce qui a été proposé, quelle règle de politique s'est appliquée, quel résultat a suivi, qui a approuvé et quand, et ce qu'a fait le système en aval. Cette trace permet de répondre avec des faits à la réclamation d'un client ou à un auditeur.
La révocation fait partie de la même trace. Quand un client retire sa délégation, la prochaine action proposée doit être refusée, et ce refus doit être enregistré. Le guide d'architecture du kill switch décrit le chemin d'arrêt et un exercice pour le tester.
Où se situe KLA, et où il ne se situe pas
Le KLA Control Plane gouverne les actions d'agents qui passent par lui. Les agents qui agissent via l'ingestion d'actions d'agents de KLA travaillent sous un mandat d'agent comportant un responsable, des outils et des destinations autorisés, des contraintes de seuil sur des paramètres comme le montant, et une date de fin. Le KLA Policy Engine renvoie allow, warn, require_approval ou block pour chaque action proposée. Lorsque l'évaluation de la politique échoue, l'action n'est pas exécutée. Un résultat require_approval crée une Decision Request ; Decision Desk refuse les décisions du demandeur, et l'approbation est liée à une empreinte des arguments de l'action, de sorte qu'une demande modifiée est bloquée. La révocation d'un mandat bloque les propositions ouvertes et refuse la prochaine action de l'agent. Chaque étape est enregistrée pour Lineage Explorer, Audit Trail et Evidence Room. Ce paragraphe décrit le code source actuel.
KLA ne détecte pas un agent tiers qui se connecte avec le mot de passe partagé d'un client. La détection des robots, le risque de session et l'application des conditions d'utilisation restent du ressort des équipes fraude et canaux numériques de la banque. KLA gouverne les agents qu'une banque ou ses partenaires choisissent de connecter par un canal gouverné.
Foire aux questions
Les banques américaines bloquent-elles les agents d'IA dans les comptes clients ?
Axios a rapporté le 22 octobre 2026 que Morgan Stanley a commencé à bloquer les agents tiers, selon des sources, et que JPMorgan, Bank of America et Citi restreignent les agents. La plupart des banques ont autorisé ou s'apprêtent à autoriser un accès des agents en lecture seule.
Des agents d'IA non autorisés ont-ils causé des pertes dans des banques américaines ?
L'article d'Axios ne fait état d'aucune perte pour les clients, d'aucun piratage confirmé ni d'aucune action d'un régulateur. Morgan Stanley a déclaré n'avoir observé aucun agent d'IA malveillant accédant à ses plateformes.
Pourquoi est-il difficile pour une banque de détecter un agent d'IA dans un compte client ?
L'agent se connecte en général avec les identifiants du client, si bien que ses requêtes portent l'identité du client. La session seule ne permet pas à la banque de savoir si c'est le client ou un logiciel qui a choisi une action.
Comment une banque peut-elle laisser agir des agents d'IA sans perdre la maîtrise des paiements ?
Donner à l'agent sa propre identité et une délégation définie, faire passer chaque action proposée par un point de contrôle de politique, exiger que le client ou un vérificateur désigné approuve toute sortie d'argent au-delà de limites fixées, et enregistrer chaque décision et son résultat.
Que signifie require_approval pour un paiement initié par un agent d'IA ?
Le point de contrôle retient le paiement exact et demande à une personne habilitée de décider. Le paiement ne s'exécute qu'après approbation, et toute modification du montant ou du bénéficiaire après approbation exige une nouvelle décision.
Points clés à retenir
L'article d'Axios montre des banques confrontées à des agents qu'elles ne voient pas et qui réagissent en les bloquant. Le blocage fonctionne tant que les agents restent rares. Une banque qui veut admettre des agents utiles a besoin d'une identité propre à chaque agent, d'un point de contrôle sur chaque action, d'une personne avant toute sortie d'argent et d'une trace qui dit qui a agi et qui a approuvé. Commencez par la matrice de décision d'approbation et par la revue des accès des agents qui maintient chaque délégation à jour.
Sources : Axios, « Unvetted AI agents are accessing U.S. bank accounts », 22 octobre 2026 ; Reuters, 22 octobre 2026, reprenant l'article d'Axios. KLA n'a aucune relation avec les banques citées.