Un agent d’IA va-t-il prendre vos mots de passe ? À l’avenir, l’IA pourrait-elle se connecter aux sites à votre place ?

Vous craignez qu’un agent d’IA récupère le mot de passe affiché dans votre navigateur ou dans votre coffre-fort ?

Cette semaine, vérifiez comment l’agent accède au compte avant de lui confier une connexion : il ne connaît pas nécessairement votre mot de passe, mais une session ouverte ou une autorisation peut lui donner des droits équivalents pour certaines actions.

Cet article s’adresse aux particuliers qui veulent protéger leurs comptes, aux développeurs qui automatisent des sites et aux responsables qui définissent des règles d’usage pour leurs équipes.

Distinguer le mot de passe, la session et l’autorisation

« Prendre votre mot de passe » peut désigner plusieurs mécanismes, qui n’exposent pas les mêmes informations et ne donnent pas les mêmes pouvoirs. Pour évaluer un agent, cherchez d’abord ce qu’il reçoit réellement : le texte secret, l’accès à une session déjà authentifiée ou un droit limité accordé par le site.

Ces appréciations sont des repères de décision, pas une certification de sécurité. Le résultat dépend de l’implémentation, des droits accordés et de l’environnement d’exécution. Une session ne révèle pas automatiquement le secret qui a servi à l’ouvrir. En revanche, elle peut permettre à un agent d’utiliser le compte tant qu’elle reste active.

À l’inverse, un jeton d’accès n’est pas un mot de passe, mais il reste une donnée sensible : celui qui le possède peut exercer les permissions qu’il représente. L’explication officielle du flux d’autorisation OAuth distingue bien l’autorisation accordée à une application de la transmission directe du mot de passe au service tiers. Ne concluez donc pas « le secret n’a pas été vu, le compte est sans risque » : il faut aussi savoir quels droits ont été délégués.

Vérifier par quel chemin l’agent peut se connecter

L’agent peut-il voir vos mots de passe lors d’une opération sur un site ?

Cela dépend de la méthode utilisée. Si vous tapez le mot de passe vous-même dans le formulaire d’authentification et que l’agent ne reçoit pas le contenu de la saisie, il peut ne jamais connaître le secret. Mais cela ne se déduit pas du seul fait que vous êtes devant un navigateur : certains outils transmettent des captures d’écran, des commandes ou des informations de page à un service de traitement. Lisez la documentation de l’outil pour déterminer quelles données sont envoyées, enregistrées ou conservées.

Un autre cas est celui d’un gestionnaire de mots de passe auquel un agent peut accéder. Le secret peut alors être exposé à l’agent, à l’extension ou au processus qui effectue le remplissage automatique, selon la conception du système et les permissions accordées. Ne supposez pas qu’un coffre-fort protège automatiquement le mot de passe contre tout logiciel autorisé à interagir avec lui. Si l’agent peut lire le contenu du champ, inspecter l’écran ou appeler une interface de remplissage, son accès doit être traité comme un accès sensible, même si le mot de passe n’est jamais affiché en clair à l’écran.

Dans un parcours de pilotage graphique, l’agent interprète l’interface et exécute des actions dans un ordinateur contrôlé. La documentation d’intégration du contrôle informatique décrit une méthode fondée sur des observations de l’écran et des actions. Elle ne permet pas de conclure que tous les agents fonctionnent ainsi : chaque produit peut traiter les images, les entrées et les données de session différemment. Pour un compte sensible, vérifiez les détails propres à l’outil plutôt que de transposer les garanties d’un autre.

Un navigateur déjà connecté permet-il à l’agent d’accéder au compte ?

Oui, c’est possible, même si l’agent ne connaît pas le mot de passe. Un navigateur authentifié possède généralement des éléments de session qui permettent de conserver la connexion. Si l’agent peut piloter ce navigateur, il peut potentiellement consulter les pages et utiliser les fonctions accessibles à la personne connectée. Il peut donc agir avec les droits de la session, dans les limites imposées par le site et par l’outil.

Cette distinction importe notamment lorsque vous utilisez une session personnelle ouverte dans le même profil de navigateur que vos courriels, vos espaces de travail ou vos comptes de paiement. La facilité de démarrage peut masquer un périmètre d’accès large. Pour une automatisation, un profil séparé, avec des comptes de test ou de faibles privilèges, réduit les conséquences possibles d’une mauvaise action ; il ne garantit pas que l’agent n’accédera à aucune donnée inattendue.

La troisième voie est l’autorisation explicite. Au lieu de remettre le mot de passe, vous passez par le mécanisme d’accès proposé par le site. L’agent ou l’application reçoit alors un jeton correspondant à des permissions définies. La séparation est utile, mais elle n’est pas magique : un droit trop large peut donner accès à des opérations importantes. Le RFC 9700 sur les bonnes pratiques de sécurité OAuth détaille les risques et protections liés aux flux OAuth. La qualité de la protection dépend toujours du paramétrage, de la conservation du jeton et des possibilités de révocation.

Un agent qui ne connaît pas votre mot de passe peut tout de même agir sur votre compte. Évaluez séparément la visibilité du secret et le pouvoir d’action accordé par la session ou le jeton.

Repérer les risques avant de déléguer une action

Le premier risque est l’excès de pouvoir. Vous demandez à un agent de consulter une facture, mais son accès lui permet aussi de modifier les paramètres du compte ou d’effectuer d’autres opérations. L’erreur peut venir d’une permission trop large, d’un objectif formulé de façon ambiguë ou d’une action exécutée sans vérification humaine. L’analyse de l’OWASP sur l’autonomie excessive des agents explique pourquoi des permissions et des capacités d’action disproportionnées peuvent transformer une erreur en conséquence importante.

Le deuxième risque concerne le contenu malveillant rencontré pendant la navigation. Une page peut inclure des instructions destinées à influencer le modèle, même si ces instructions ne proviennent pas de vous. L’agent pourrait alors interpréter du texte de page comme une consigne, divulguer des informations ou poursuivre une action que vous ne souhaitiez pas. Ce scénario ne signifie pas que chaque page est dangereuse ni que chaque agent cédera à une telle tentative. Il s’agit d’un risque documenté qui justifie de limiter l’accès aux comptes et de demander une confirmation avant les actions sensibles. Les conseils de sécurité sur les attaques par injection d’instructions décrivent ce problème et les difficultés de défense.

Le troisième risque est la fuite ou la conservation excessive de données. Une capture d’écran peut contenir un nom, une adresse, un solde ou un message privé. Un journal d’exécution peut conserver des actions ou des extraits de page. Un jeton peut rester disponible dans un fichier, un stockage de navigateur ou un environnement partagé. La présence d’une fonction de suppression dans une interface ne prouve pas à elle seule que toutes les copies et traces techniques sont immédiatement effacées. Demandez ce qui est journalisé, où les données sont traitées et comment elles sont supprimées.

Enfin, pensez aux conséquences de l’action, pas seulement à la fuite du secret. Une commande mal comprise peut modifier un profil, envoyer un message, supprimer des données ou valider un achat. Les recommandations de la documentation de sécurité du contrôle informatique insistent sur le traitement prudent des actions à fort impact et sur la nécessité de contrôler l’environnement. Ces conseils concernent ce type de mécanisme ; ils ne constituent pas une garantie universelle applicable à tout agent.

Pour un usage en équipe, séparez les comptes de test des comptes de production. Le compte de test doit contenir le minimum de données réelles et ne pas disposer de droits administratifs s’il n’en a pas besoin. Si vous définissez des règles internes, précisez qui peut autoriser l’agent, quelles opérations exigent une validation et comment révoquer rapidement un accès. Pour préparer un environnement, vous pouvez aussi consulter les informations de présentation de VPSSpark, sans en déduire des garanties de sécurité qui ne seraient pas décrites explicitement.

Réduire l’accès sans croire qu’il devient sans risque

Commencez par choisir l’accès le moins puissant qui suffit à la tâche. Si l’agent doit uniquement lire une information, évitez de lui confier un compte capable de modifier ou de supprimer cette information. Si le service propose une autorisation distincte, vérifiez le détail des permissions avant de l’accepter. Une formulation vague comme « accéder à votre compte » ne vous apprend pas quels actes seront possibles.

Quand une session de navigateur est nécessaire, utilisez si possible un profil séparé et fermez les autres comptes avant de démarrer. Cette séparation limite le mélange accidentel entre activités personnelles et automatisation. Elle ne neutralise pas une faille de l’agent, une capture trop large ou une mauvaise configuration du profil. Ne stockez pas des identifiants de production dans un environnement partagé ou non fiable ; si l’outil a besoin d’un secret, vérifiez comment il est transmis et retiré après usage.

Réservez une confirmation humaine aux actions qui ont des conséquences difficiles à annuler : paiement, changement de mot de passe, modification des paramètres de sécurité, envoi externe ou suppression. La confirmation n’est utile que si l’écran indique clairement l’action demandée et le compte concerné. Un bouton « continuer » sans résumé exploitable ne constitue pas un contrôle réel.

Prévoyez également une sortie de secours. Si un accès repose sur OAuth, identifiez l’endroit où vous pouvez révoquer l’autorisation et vérifiez que la révocation concerne bien l’application visée. La référence officielle de l’interface de révocation décrit l’appel permettant de retirer un jeton dans ce contexte. La révocation d’un jeton ne remplace pas les autres mesures : un agent peut avoir déjà effectué une action, et des traces peuvent exister ailleurs.

Pour les équipes qui développent ou évaluent un agent, mettez en place des limites dans le processus lui-même : accès restreint, actions traçables, séparation entre lecture et modification et point d’arrêt avant les opérations importantes. La documentation technique indique comment un outil donné fonctionne ; elle ne prouve pas que votre intégration applique correctement ces limites. Faites donc un essai avec un compte sans enjeu avant toute connexion à un service réel.

Choisir entre délégation et connexion manuelle

Appliquez ces conditions avant de laisser un agent se connecter :

• Si la tâche consiste à lire une page publique, ne connectez pas de compte : une session authentifiée ajouterait des droits sans utilité.
• Si la tâche porte sur des données internes mais n’exige aucune modification, choisissez un compte de test ou une autorisation en lecture seule, si le service le permet ; sinon, effectuez vous-même l’accès.
• Si l’agent doit utiliser une session déjà ouverte, séparez-la de vos profils personnels et vérifiez les pages auxquelles il peut accéder. Si cette isolation n’est pas possible, ne lui confiez pas un compte important.
• Si l’opération touche à l’argent, à l’identité, à la sécurité ou à des données irremplaçables, gardez la validation finale pour vous. Si l’outil ne permet pas de contrôler précisément l’action avant exécution, faites-la manuellement.
• Si vous ne pouvez pas savoir quelles données sont conservées ou comment révoquer l’accès, ne saisissez pas de mot de passe et ne liez pas de compte sensible tant que ces points ne sont pas clarifiés.

Ce tri est plus utile qu’une promesse générale de sécurité. Un agent peut être approprié pour une tâche répétitive à faible enjeu et inadapté à une opération qui engage votre identité ou vos finances. La question décisive n’est donc pas seulement « l’IA voit-elle mon mot de passe ? », mais aussi « que peut-elle faire une fois connectée, et comment puis-je arrêter l’accès ? ».

Comprendre ce qui pourrait changer dans la connexion aux sites

Les agents peuvent déjà piloter une interface dans certains contextes, ou utiliser une intégration qui leur donne un accès autorisé. Cela ne signifie pas que les sites acceptent tous une connexion déléguée, ni que les agents pourront se passer de vérification d’identité. Chaque service détermine son propre parcours, ses exigences d’authentification et les permissions qu’il expose. Dans certains cas, la personne devra encore s’authentifier et confirmer l’action ; dans d’autres, une interface de programmation ou un jeton limité pourra éviter une saisie répétée du mot de passe.

Les clés d’accès et les protocoles d’authentification peuvent modifier la manière dont une personne prouve son identité sans transmettre un mot de passe classique à une application. Toutefois, ils ne constituent pas à eux seuls une autorisation générale permettant à un agent d’agir librement. La recommandation du W3C sur WebAuthn Level 3 décrit une norme liée aux justificatifs d’authentification à clé publique ; elle ne dit pas que tous les sites délégueront leurs opérations aux agents.

Une évolution possible consiste à séparer davantage l’identité, le consentement et l’action : vous vous authentifiez, vous choisissez ce que l’agent peut faire, puis le service demande une confirmation adaptée à l’enjeu. Cette architecture pourrait réduire la nécessité de partager un secret réutilisable. Elle ne supprimera pas les risques de mauvaise interprétation, de permissions trop larges ou de conservation indue des jetons. Les mécanismes devront préciser qui a autorisé l’action, quel service est responsable et comment l’utilisateur peut mettre fin à l’accès.

Pour l’instant, traitez donc la connexion autonome comme une capacité liée à un outil et à un site précis, pas comme un comportement universel du Web. Avant de compter sur une nouvelle méthode, vérifiez sa documentation officielle et le périmètre effectivement accordé. Si le site ne décrit pas clairement l’autorisation ou la responsabilité, ne déduisez pas ces garanties de la seule présence d’un agent.

Vérifier l’agent avant de lui confier un compte

Avant un premier essai, cherchez des réponses concrètes plutôt qu’une simple mention de « sécurité » :

• L’agent reçoit-il le mot de passe, le voit-il dans une capture ou agit-il uniquement dans une session déjà ouverte ?
• Quelles données de page, images, commandes et traces d’exécution sont transmises ou conservées ?
• Peut-il lire seulement, ou aussi envoyer, modifier, acheter et supprimer ?
• La session est-elle isolée des autres comptes et des fichiers personnels ?
• Existe-t-il un journal qui vous permet de comprendre les actions réellement exécutées ?
• Pouvez-vous interrompre l’opération et révoquer l’accès depuis le service concerné ?
• Une confirmation humaine est-elle exigée avant une action ayant des conséquences importantes ?

Si les réponses sont imprécises, réduisez l’enjeu du test : utilisez un compte sans données sensibles, des permissions faibles et une tâche facile à contrôler. Ne commencez pas par une boîte de réception principale, un compte financier ou un compte professionnel doté de droits élevés. Pour toute question sur un environnement envisagé, contactez l’équipe de VPSSpark afin de demander des informations vérifiables ; ne confondez pas une réponse commerciale avec une preuve technique de cloisonnement ou de protection.

Si vous comparez votre navigateur personnel à un Mac utilisé pour des essais, retenez que le changement de machine ne règle pas, à lui seul, le problème des permissions. Une session personnelle mêlée à d’autres comptes, des journaux conservés trop longtemps et l’absence de confirmation restent des faiblesses, quel que soit l’ordinateur. À l’inverse, acheter un Mac n’est pas forcément pertinent pour un essai ponctuel ; louer un Mac auprès de VPSSpark peut être une option à examiner pour disposer d’un environnement temporaire, à condition de vérifier séparément l’isolation, le stockage des identifiants et les modalités d’accès. Commencez par contrôler les autorisations et la procédure de révocation de l’agent que vous utilisez. Testez ensuite uniquement une tâche à faible risque ; gardez la connexion manuelle pour les opérations qui engagent votre argent, votre identité ou des données importantes.