L’alerte envoyée par Bank of America le 27 octobre 2026 tient en une règle simple : ne transmettez jamais vos identifiants bancaires à un assistant ou à un agent IA. La banque rappelle aussi que le titulaire peut être tenu responsable des opérations réalisées après un accès partagé, ce qui transforme une pratique présentée comme pratique en risque financier et contractuel.
Cette mise en garde arrive alors que les assistants capables d’agir à la place de leurs utilisateurs progressent rapidement. Un agent peut lire des informations, remplir un formulaire ou déclencher une action, mais il peut aussi mal interpréter une instruction, conserver une donnée sensible ou transmettre un secret à un service tiers. Voici une méthode concrète pour utiliser l’IA sans lui confier les clés de vos comptes.
L’alerte de Bank of America vise les assistants qui agissent à votre place
Le courriel de Bank of America, intitulé « Protecting your finances in the AI World », déconseille de partager son nom d’utilisateur et son mot de passe avec une autre personne, un service externe ou un outil d’IA proposant d’effectuer des tâches au nom du client. Un porte-parole de la banque a confirmé l’authenticité du message auprès de TechCrunch.
La banque ajoute que les clients qui communiquent leurs identifiants restent responsables des activités réalisées grâce à cet accès. Cette précision concerne directement les agents IA, des logiciels capables d’enchaîner plusieurs étapes et d’utiliser des outils externes pour atteindre un objectif défini par l’utilisateur.
À retenir : un assistant qui connaît vos instructions n’a pas besoin de connaître votre mot de passe. L’accès doit passer par un mécanisme contrôlé, pas par la copie de vos identifiants dans une conversation.
Le risque ne vient pas seulement d’une erreur de l’IA. Un service compromis, une extension malveillante ou une fuite de données peut exposer les identifiants à des personnes non autorisées. Un agent qui effectue une opération sans comprendre correctement le contexte peut également provoquer un virement, modifier un paramètre de sécurité ou déclencher un verrouillage antifraude.
Pourquoi copier un mot de passe dans une conversation est dangereux
Un mot de passe placé dans une conversation cesse d’être un secret limité à la banque et à son titulaire. Il peut apparaître dans l’historique du service, dans des journaux techniques, dans une capture d’écran ou dans les données accessibles à une intégration connectée.
Le danger augmente lorsque l’assistant dispose d’une mémoire, d’un accès à des fichiers ou d’une connexion à d’autres applications. Même si le fournisseur applique des protections, l’utilisateur ne maîtrise pas nécessairement la durée de conservation, les personnes autorisées à administrer le service ni les systèmes qui traitent la donnée.
Quatre scénarios doivent être distingués :
- Divulgation involontaire : l’assistant réutilise une information confidentielle dans une réponse ou une action ultérieure.
- Compromission du service : une faille permet à un tiers d’accéder aux conversations ou aux secrets stockés.
- Mauvaise interprétation : l’agent exécute une instruction différente de celle souhaitée.
- Accès persistant : le mot de passe reste valable après l’action initiale et peut être réutilisé.
Un assistant peut aussi être victime d’une prompt injection, une instruction dissimulée dans une page, un courriel ou un document qui tente de modifier son comportement. Si l’agent dispose d’identifiants et de droits étendus, une simple lecture de contenu peut devenir un point de départ pour une action non prévue.
La banque mentionne également le risque d’un blocage du compte si l’activité paraît suspecte. Les systèmes antifraude peuvent interpréter une connexion inhabituelle, un appareil inconnu ou une série d’actions automatisées comme un accès non autorisé.
Les sept règles pour protéger vos données avec une IA
La sécurité repose moins sur le modèle utilisé que sur les accès accordés à l’outil. Les règles suivantes s’appliquent aux assistants grand public comme aux solutions déployées dans une entreprise.
1. Ne partagez jamais les secrets d’authentification
Ne copiez pas dans un assistant :
- un nom d’utilisateur bancaire associé à un mot de passe ;
- un code à usage unique ;
- une phrase secrète ;
- un code PIN ;
- une clé API ;
- une clé privée ;
- un code de récupération ;
- une réponse à une question de sécurité.
Un code à usage unique doit être saisi uniquement dans le site ou l’application officielle qui l’a demandé. Le transférer à un assistant revient à lui permettre de franchir une étape d’authentification conçue pour vérifier votre présence.
2. Remplacez le mot de passe par une autorisation limitée
Lorsqu’un service propose une intégration officielle, privilégiez une autorisation contrôlable, révocable et limitée à une fonction précise. Les mécanismes d’autorisation déléguée évitent de transmettre le mot de passe à l’application tierce.
Avant d’autoriser une connexion, vérifiez le nom du service, les permissions demandées et la possibilité de révoquer l’accès. Une application qui demande la lecture des transactions ne devrait pas réclamer le droit d’effectuer des virements ou de modifier les bénéficiaires.
Une autorisation limitée ne supprime pas tous les risques. Elle réduit toutefois l’impact d’une erreur ou d’une compromission en empêchant l’outil d’accéder à des fonctions dont il n’a pas besoin.
3. Appliquez le principe du moindre privilège
Le moindre privilège consiste à donner à un outil uniquement les droits indispensables à sa mission. Pour un assistant chargé de classer des factures, un accès en lecture à un dossier dédié peut suffire. Il n’a pas besoin d’un accès administrateur à l’ensemble du système informatique.
Dans une organisation, séparez les environnements et les comptes :
- un compte de consultation pour les recherches ;
- un compte opérationnel pour les actions validées ;
- un compte administrateur réservé aux responsables habilités ;
- un espace de test sans données réelles pour expérimenter.
Cette séparation limite les conséquences d’une instruction malveillante ou d’une erreur de configuration. Elle facilite aussi l’analyse des journaux, car chaque action peut être rattachée à un compte et à un niveau d’autorisation précis.
4. Masquez les données avant de les transmettre
Avant de demander à une IA d’analyser un document, retirez les éléments qui ne sont pas nécessaires. Remplacez les noms par des identifiants génériques, supprimez les coordonnées bancaires et masquez les numéros de contrat lorsque l’analyse ne les utilise pas.
Cette technique de pseudonymisation conserve une partie de la structure utile tout en réduisant l’exposition des personnes. Elle ne doit pas être confondue avec l’anonymisation : si une table de correspondance permet de retrouver l’identité, la donnée reste indirectement rattachable à une personne.
Pour une facture, l’assistant peut souvent travailler avec le montant, la date, la catégorie et un identifiant interne. Le nom complet du client, son adresse et son numéro de compte ne sont pas forcément nécessaires.
5. Interdisez les secrets dans les instructions et les fichiers de référence
Les équipes doivent examiner les modèles de prompts, les bases documentaires et les connecteurs utilisés par un assistant. Un secret placé dans un exemple peut être copié dans une nouvelle conversation, indexé dans une base de recherche ou rendu accessible à un utilisateur qui ne devait pas le voir.
Utilisez un gestionnaire de secrets pour les clés techniques et injectez-les uniquement au moment où une application autorisée en a besoin. Une clé API ne doit pas être écrite en clair dans un prompt, un fichier partagé ou un dépôt de code.
Les journaux doivent également être contrôlés. Enregistrer une requête complète peut faciliter le débogage, mais cette pratique risque de conserver des données personnelles ou confidentielles. Les équipes doivent définir ce qui peut être journalisé, pendant combien de temps et qui peut consulter ces traces.
6. Exigez une validation humaine avant toute action sensible
Un agent peut préparer une opération sans être autorisé à l’exécuter seul. Cette séparation entre préparation et validation est particulièrement adaptée aux paiements, aux changements de coordonnées bancaires, aux suppressions de fichiers et aux modifications de droits.
Une validation sérieuse doit afficher les éléments utiles : destinataire, montant, compte utilisé, date, permissions modifiées et justification de l’action. Un bouton « approuver » présenté sans contexte ne constitue pas un contrôle suffisant.
Pour les opérations financières, activez si possible une double validation. La personne qui prépare une demande ne devrait pas être la seule à pouvoir l’approuver lorsque le montant ou le niveau de risque le justifie.
7. Surveillez et révoquez les accès
La protection ne s’arrête pas au moment de l’autorisation. Examinez régulièrement les applications connectées, les sessions ouvertes, les appareils reconnus et les clés actives. Révoquez immédiatement les accès inutilisés ou associés à un service dont vous n’avez plus besoin.
Configurez des alertes pour les connexions inhabituelles, les nouveaux bénéficiaires, les changements de coordonnées et les opérations importantes. Ces notifications réduisent le délai entre une action suspecte et sa détection.
Si des identifiants ont été transmis à un assistant, changez le mot de passe depuis le site officiel de la banque, révoquez les sessions et contactez l’établissement par un canal vérifié. N’utilisez pas le lien reçu dans un message pour effectuer cette opération.
Ce qu’une entreprise doit vérifier avant de connecter un agent
Une entreprise ne devrait pas évaluer un agent uniquement sur la qualité de ses réponses. Le contrôle doit porter sur les données accessibles, les actions autorisées, les intégrations utilisées et les traces conservées.
Cartographier les données exposées
Commencez par classer les données traitées : publiques, internes, personnelles, financières, médicales ou soumises au secret professionnel. Définissez ensuite les catégories que l’outil peut lire, transformer, conserver ou transmettre.
Un assistant chargé de résumer des documents internes ne devrait pas accéder automatiquement à la messagerie complète, aux ressources humaines et aux comptes clients. La connexion doit être limitée au périmètre nécessaire.
Tester les scénarios d’abus
Les tests doivent inclure des instructions contradictoires, des documents piégés et des demandes de contournement. L’objectif est de vérifier si l’agent révèle un secret, suit une consigne cachée ou exécute une action sans validation.
Les tests peuvent porter sur :
- l’extraction d’informations confidentielles depuis un document ;
- la tentative de réutilisation d’un jeton expiré ;
- la demande d’une action supérieure aux permissions accordées ;
- la confusion entre une instruction de l’utilisateur et une instruction contenue dans une page ;
- la conservation d’une donnée après sa suppression.
Les résultats doivent être associés à des mesures correctives et à une nouvelle vérification. Une démonstration réussie ne suffit pas à prouver qu’un système reste sûr dans le temps.
Définir une procédure d’arrêt
Chaque agent connecté à un système critique doit pouvoir être désactivé rapidement. L’organisation doit connaître le propriétaire du service, le responsable de la sécurité et la procédure de révocation des accès.
Un bouton d’arrêt ne remplace pas la prévention, mais il réduit la durée d’exposition lorsqu’un comportement anormal est détecté. Les équipes doivent également conserver une copie des journaux nécessaires à l’analyse de l’incident, dans le respect des règles de protection des données.
Les différences entre un assistant conversationnel et un agent connecté
La distinction est essentielle pour évaluer le risque. Un assistant qui répond à une question sans accès externe peut produire une information erronée, mais il ne dispose pas automatiquement du pouvoir de modifier un compte. Un agent connecté peut consulter des systèmes, appeler des API et déclencher des opérations.
| Type d’outil | Accès typique | Risque principal | Contrôle prioritaire |
|---|---|---|---|
| Assistant sans connexion | Texte fourni par l’utilisateur | Divulgation de données dans la conversation | Filtrage des informations sensibles |
| Assistant avec fichiers | Documents sélectionnés | Exposition de contenus internes | Permissions par dossier et durée de conservation |
| Assistant avec API | Services métier ciblés | Utilisation abusive d’une fonction | Jetons limités et révocables |
| Agent avec exécution d’actions | Outils, comptes et workflows | Action non prévue ou non autorisée | Validation humaine et journalisation |
Le mot « agent » ne garantit donc pas un niveau de sécurité particulier. Il décrit une capacité d’action, pas une certification. La sécurité dépend de l’architecture, des permissions, de l’authentification et des contrôles appliqués autour du modèle.
Pour un compte bancaire, la règle la plus sûre reste l’absence d’accès direct par identifiants partagés. Si une banque propose un jour une intégration officielle, celle-ci devra être évaluée séparément selon ses permissions, ses mécanismes de validation et ses conditions contractuelles.
Ce que cette alerte change pour les usages quotidiens
L’IA peut aider à comprendre un relevé, repérer des catégories de dépenses ou préparer une liste de questions à poser à la banque sans recevoir les identifiants. L’utilisateur peut copier uniquement les lignes nécessaires après avoir supprimé les noms, numéros de compte et références sensibles.
Pour analyser un budget, remplacez les données directes par des catégories et des montants arrondis lorsque la précision n’est pas indispensable. Pour rechercher une opération, utilisez une date et un montant partiellement masqués plutôt qu’un relevé complet.
Évitez également de demander à un assistant de se connecter à votre messagerie pour rechercher des alertes bancaires si cette connexion donne accès à l’ensemble des courriels. Un dossier dédié ou une exportation limitée réduit le périmètre exposé.
À retenir : l’IA peut préparer, expliquer et classer. Pour les opérations irréversibles ou financières, elle ne doit pas recevoir vos secrets ni agir sans contrôle explicite.
La question de la responsabilité reste centrale. Bank of America indique que le client assume les activités résultant du partage de ses identifiants, ce qui signifie qu’un gain de confort ne doit pas être évalué sans tenir compte des conséquences possibles.
Notre avis : l’IA doit préparer les opérations, pas détenir les clés
L’alerte de Bank of America arrive au moment où les acteurs financiers explorent encore la place des agents IA. Elle rappelle une limite pratique : un assistant peut être utile sans devenir titulaire d’un accès bancaire.
La position la plus solide consiste à appliquer trois principes : aucun mot de passe dans une conversation, des permissions limitées pour les intégrations officielles et une validation humaine avant toute action sensible. Pour les entreprises, cette base doit être complétée par la pseudonymisation, la journalisation, les tests d’injection et la révocation rapide des accès.
Dans les six prochains mois, la différence entre les services simplement capables de dialoguer et ceux autorisés à agir deviendra encore plus importante. Les solutions qui proposeront des permissions détaillées, des traces compréhensibles et une approbation claire auront un avantage concret sur celles qui demandent encore un identifiant et un mot de passe. La vraie question sera alors simple : quelles actions l’IA pourra-t-elle préparer sans jamais obtenir le pouvoir de les exécuter seule ?
Sources citées : Bank of America, courriel « Protecting your finances in the AI World », confirmé par un porte-parole auprès de TechCrunch, 27 octobre 2026 ; TechCrunch, 27 octobre 2026 ; Notes From the Terminal, 28 octobre 2026.