Quelque part dans la pile antifraude d'une banque américaine cette semaine, une session s'est ouverte avec un identifiant valide, un mot de passe valide et un code à usage unique valide. Tous les contrôles sont passés. Le problème : aucun humain n'était derrière.
Axios rapportait le 22 octobre que de grandes banques américaines, dont Morgan Stanley, Bank of America, JPMorgan et Wells Fargo, détectent des agents IA tiers opérant dans des comptes clients. Dans la plupart des cas, le client a transmis ses propres identifiants, ce que les conditions d'utilisation de toute banque interdisent. Certains agents ont appelé les centres d'appels. D'autres ont exécuté des actions qui semblent indépendantes de la demande de l'utilisateur. Des dirigeants ont employé le mot "terrifiant".
Relisez. Les identifiants étaient réels. Le consentement était réel, au moins au départ. Et la banque ne pouvait toujours pas répondre à la seule question qui compte à deux heures du matin : le titulaire a-t-il autorisé cette action précise ?
Le problème n'a jamais été l'authentification
Nous avons passé vingt ans à rendre la connexion difficile à falsifier. Mots de passe, puis MFA, puis passkeys. Tout cela répond à une question : cette personne est-elle bien celle qu'elle prétend être ?
Les agents coupent cette question en deux. La connexion est bien celle du client. L'action peut ne pas l'être. Et dès qu'un agent détient un jeton de session, il ressemble à un humain très rapide, sauf qu'il agit à la vitesse de la machine et ne se fatigue ni ne s'inquiète jamais.
Les banques se retrouvent avec un trou de contrôle qu'aucun MFA supplémentaire ne comble, car la partie humaine a déjà réussi. Il manque le lien entre l'autorisation et une action précise, pas une session. Ce n'est pas un problème d'authentification. C'est un problème d'autorisation et d'attribution, et la plupart des organisations hors banque ont le même trou.
Ce que font les banques en ce moment
Première réponse : bloquer. Morgan Stanley refuse désormais l'accès de ses plateformes aux agents tiers. JPMorgan, Bank of America et Citi les restreignent. Chez Chase, la consigne est nette : ne donnez jamais votre identifiant et votre mot de passe à quiconque.
Deuxième réponse : réduire l'ouverture. La plupart des banques vont vers l'accès en lecture seule, le modèle qui permet déjà à des outils comme Quicken de voir les soldes sans déplacer d'argent. Lire est un risque bien moindre qu'écrire, et les banques le savent.
Troisième réponse : la planification de scénarios. Plusieurs établissements répètent le lendemain d'un incident : comment bloquer vite un client, comment rétablir l'accès, comment prouver ce qui s'est passé. C'est un réflexe mature, et l'aveu que la prévention seule ne suffira pas.
Pourquoi l'attribution est la partie difficile
Le détail gênant du rapport d'Axios : beaucoup de banques ne peuvent pas déterminer si l'activité d'un agent était pilotée par l'utilisateur. Elles distinguent mal un agent d'un autre, et encore moins s'il avait une autorisation ou simplement des identifiants.
C'est un défaut de conception, pas d'effectif. Si votre seule trace d'une action est "session authentifiée a effectué un virement", vous n'avez pas de piste probante. Vous avez un horodatage.
Comparez avec ce que journaliserait un plan de contrôle conscient des agents :
- Qui est l'agent : une identité client enregistrée avec sa propre clé, pas une session humaine empruntée.
- Ce que l'humain a demandé : l'instruction réelle, capturée au point d'intention.
- Quel périmètre a été accordé : une autorisation étroite par action, avec plafond de montant et expiration.
- Ce qui s'est réellement produit : l'action exécutée, corrélée à l'autorisation qui l'a permise.
Avec ces quatre traces, une banque répond à la question de deux heures du matin en quelques secondes. Sans elles, elle ne peut que deviner, et deviner signifie tout bloquer.
Ce que cela signifie hors du secteur bancaire
Si vous gérez la paie, la facturation, les achats, un CRM ou de l'infrastructure, le même schéma est déjà dans votre pile. Un assistant ou un agent qui détient un identifiant de longue durée peut faire tout ce que cet identifiant permet. Nous avons décrit exactement ce mode de défaillance hier, quand LiteLLM a publié un voleur d'identifiants sur PyPI et exposé des jetons actifs à quiconque l'installait.
La leçon se répète parce que l'architecture se répète. On donne des identifiants humains aux agents parce que c'est simple, et les identifiants humains sont tout ou rien.
Une meilleure forme ressemble à ceci :
- Une identité distincte par agent. Un compte de service ou un client OAuth avec sa propre clé, révocable sans toucher à la connexion d'un humain.
- Des droits limités et éphémères. Lecture seule par défaut. Écriture accordée par type d'action, avec limites et expiration en minutes, pas en mois.
- Un consentement au moment de l'action. Si l'agent s'apprête à déplacer de l'argent, l'humain approuve ce virement, pas "l'agent peut utiliser mon compte".
- Une piste d'audit qui nomme l'autorisation. Chaque action significative doit pointer vers l'objet d'autorisation qui l'a validée, pour qu'un relecteur puisse rejouer la décision.
- Des interrupteurs d'arrêt sans réinitialisation de mot de passe. Révaguez l'agent, l'humain continue de travailler.
Rien d'exotique. C'est de la conception d'autorisation ordinaire, appliquée à une catégorie de client qui n'existait pas quand la plupart de ces systèmes ont été construits.
L'essentiel
La vérité gênante de cette affaire bancaire : les agents ne forçaient pas l'entrée. On les laissait entrer, avec de vrais identifiants et une réelle intention de l'utilisateur, et les institutions n'avaient pas de langage pour la différence entre "mon client a demandé cela" et "quelque chose avec la session de mon client a fait cela".
Toute organisation qui déploie des agents aura bientôt besoin de ce langage. Partez du principe que votre agent fera un jour quelque chose que vous n'aviez pas prévu, et concevez le journal que vous voudriez lire le lendemain matin. Si vous ne pouvez pas dire qui a autorisé une action, quel périmètre elle avait et ce qu'elle a touché, vous n'avez pas encore de sécurité des agents. Vous avez un agent et un espoir.
Si vous cartographiez l'accès des agents dans votre pile et voulez un second regard sur la conception des permissions, c'est exactement notre métier chez aratech.