Les agents navigateurs d’Amazon et Google font face à un problème d’injection de prompt sans solution parfaite

Les agents navigateurs d’Amazon et Google sont désormais confrontés au même dilemme : une plus grande autonomie offre aux attaques par injection de prompt davantage de possibilités de causer des dommages. Malgré de nouvelles protections, les chercheurs continuent de trouver des moyens d’orienter les agents via des pages web, e-mails, formulaires et publications sociales ordinaires. Cette faiblesse devient une contrainte durable de la conception des navigateurs IA, et non un nouveau bug de navigateur qui attendrait un correctif unique et définitif.

La préoccupation immédiate concerne l’injection indirecte de prompt, où des instructions hostiles se cachent dans du contenu lu par un agent IA. Ces instructions peuvent entrer en concurrence avec la demande de l’utilisateur et influencer l’action suivante de l’agent. Un navigateur classique affiche le contenu hostile. Un navigateur agentique peut l’interpréter, passer à un autre service et agir avec l’autorité de l’utilisateur.

Cette distinction place Amazon et Google au cœur d’une compétition plus large en matière de sécurité, impliquant Microsoft, OpenAI, Anthropic, Perplexity et des fournisseurs de navigateurs spécialisés. Chaque entreprise veut des agents capables d’accomplir des tâches utiles sur l’ensemble du web. Pourtant, chaque autorisation supplémentaire élargit les conséquences lorsqu’un agent comprend mal à qui il doit obéir.

La conclusion inquiétante n’est pas que les agents navigateurs sont inutilisables. C’est que les fournisseurs ne peuvent pas considérer la détection des injections de prompt comme une frontière de sécurité complète. Les entreprises doivent partir du principe que certaines instructions malveillantes passeront au travers et limiter ce qu’un agent compromis peut atteindre, modifier ou divulguer.

Ce qui a changé dans la course à la sécurité des navigateurs d’Amazon et Google

L’injection de prompt est passée d’une faiblesse théorique des modèles à un problème opérationnel de sécurité des navigateurs.

Des chercheurs en sécurité ont montré à plusieurs reprises qu’un contenu malveillant peut rediriger un agent sans exploiter le chemin traditionnel d’exécution de code du navigateur. L’attaquant vise plutôt l’interprétation du contenu par le modèle. Une instruction cachée peut apparaître dans une page web, un e-mail, un document ou même un élément d’interface utilisateur.

L’attaque devient sérieuse lorsque l’agent peut utiliser des sessions de navigateur authentifiées. Il peut lire une boîte de réception, ouvrir un autre onglet, soumettre un formulaire ou récupérer des informations auprès d’un service connecté. Des actions qui paraissent pratiques pendant une tâche normale deviennent des composants utiles dans une chaîne d’attaque.

Les chercheurs de Zenity ont décrit cette catégorie plus large de faiblesses des navigateurs agentiques sous le nom de PleaseFix. Leurs tests visaient la manière dont les agents suivent des objectifs exprimés en langage naturel tout en se déplaçant entre des sites web et des ressources locales. Selon des résultats de recherche sur la sécurité des navigateurs, les chercheurs ont constaté des conceptions et protections différentes, tout en identifiant des chemins d’attaque dans des navigateurs agentiques commerciaux.

Le changement important concerne la voie empruntée par l’attaquant. Les attaques traditionnelles contre les navigateurs reposent souvent sur une vulnérabilité logicielle, une extension malveillante, un identifiant volé ou un clic trompeur. Une injection de prompt peut commencer par du contenu que l’agent devait traiter dans le cadre d’une demande ordinaire.

Un utilisateur peut demander à un assistant de résumer une page produit. La page pourrait contenir des instructions cachées visuellement, mais toujours accessibles au modèle. Un attaquant pourrait aussi placer des instructions dans une publication publique, un formulaire d’inscription à une newsletter ou du contenu récupéré via un outil de navigation.

Cela ne garantit pas que chaque instruction injectée réussisse. Les modèles, classificateurs, systèmes d’autorisation et contrôles d’action peuvent bloquer de nombreuses tentatives. Le problème est que ces contrôles opèrent face à un adversaire adaptatif, capable de modifier la formulation, la présentation, le moment et le contexte.

Les propres mesures de Google confirment ce changement. Ses équipes de sécurité ont analysé du contenu web public à la recherche de schémas connus d’injection indirecte de prompt et ont signalé une hausse relative de 32 % des détections malveillantes entre novembre 2025 et février 2026. L’entreprise a également trouvé une quantité importante de texte bénin ressemblant à des attaques, ce qui complique une classification fiable.

Cette recherche sur les menaces web est importante, car une défense de navigateur doit gérer deux erreurs concurrentes. Si elle manque du contenu hostile, un agent peut être manipulé. Si elle bloque trop agressivement, les pages courantes et les instructions légitimes deviennent inutilisables.

Amazon aborde le problème par sa plateforme cloud d’agents plutôt que par un navigateur grand public. Bedrock AgentCore Browser offre aux développeurs un environnement isolé pour des agents qui naviguent sur des sites, remplissent des formulaires et extraient des informations. Ces capacités exposent toujours les agents à du contenu non fiable, même lorsque la session de navigateur sous-jacente est isolée.

La comparaison entre Amazon et Google reflète donc deux modèles de distribution différents. Google ajoute des fonctions agentiques à un navigateur utilisé directement par les personnes. Amazon fournit l’infrastructure dont les entreprises se servent pour créer leur propre automatisation de navigation. Tous deux doivent gérer la même collision entre le contenu du web ouvert et les actions privilégiées des agents.

Pourquoi les agents navigateurs affaiblissent une ancienne frontière de sécurité

La faiblesse fondamentale apparaît lorsqu’un même modèle reçoit des instructions fiables et des données non fiables dans un processus de raisonnement partagé.

Les navigateurs web ont passé des décennies à séparer les sites web les uns des autres. La politique de même origine empêche généralement une origine de lire librement des informations sensibles provenant d’une autre. Les sandbox, les invites d’autorisation, l’isolation des processus et les politiques de sécurité de contenu ajoutent d’autres barrières.

Un agent IA peut franchir ces frontières parce que l’utilisateur l’autorise à accomplir une tâche. Il peut lire une page, consulter un autre service et combiner les résultats. Cette capacité constitue le principal avantage du produit, mais elle crée aussi un pont que du contenu hostile peut tenter de contrôler.

Le modèle n’a pas besoin de contourner directement la politique de même origine. Il peut utiliser des fonctions légitimes du navigateur accessibles à l’utilisateur. Si une page malveillante persuade l’agent d’ouvrir une boîte de réception, de lire un message et de transmettre des informations, chaque étape individuelle peut sembler autorisée.

On appelle parfois cela le problème de l’adjoint confus. Un composant de confiance dispose d’une autorité légitime, mais un attaquant le manipule pour qu’il utilise cette autorité à mauvais escient. Les agents navigateurs rendent cet adjoint conversationnel, probabiliste et capable de planifier plusieurs étapes.

Des recherches sur des agents navigateurs open source ont montré comment ce schéma peut entraîner l’exposition d’identifiants et des actions non autorisées. Une étude universitaire a signalé une injection de prompt, un contournement de validation de domaine et une exfiltration d’identifiants dans un framework d’automatisation de navigateur. Son analyse d’agent navigateur incluait également une vulnérabilité divulguée et une preuve de concept fonctionnelle.

Le problème s’aggrave lorsqu’un agent conserve une mémoire d’une tâche à l’autre. Une instruction hostile ne doit pas toujours causer des dommages immédiats. Elle peut tenter de modifier le contexte stocké, créer une préférence trompeuse ou influencer une décision ultérieure lorsque des ressources sensibles deviennent disponibles.

La compréhension visuelle ouvre une autre voie. Un agent qui interprète des captures d’écran peut rencontrer des instructions intégrées dans des images ou des éléments d’interface. Filtrer uniquement le texte brut de la page ne détectera pas tous les messages qu’un modèle multimodal peut percevoir.

Les attaquants peuvent aussi éviter des expressions évidentes telles que « ignorez les instructions précédentes ». Ils peuvent présenter des étapes malveillantes comme des éléments nécessaires de l’objectif initial de l’utilisateur. Une demande d’inscription à une newsletter, par exemple, peut devenir un prétexte pour récupérer des données ou ouvrir un autre outil.

Cette technique est importante, car de nombreuses défenses recherchent un conflit entre l’objectif de l’utilisateur et l’instruction hostile. Un attaquant peut plutôt faire apparaître l’action malveillante comme cohérente avec cet objectif. La formulation devient moins suspecte, tandis que la capacité demandée reste dangereuse.

L’injection de prompt diffère de l’injection SQL sur un point essentiel. Les logiciels peuvent séparer les commandes SQL des données grâce à une syntaxe stricte et à des requêtes paramétrées. Les agents en langage naturel reposent sur une interprétation contextuelle, de sorte que les instructions et les informations n’ont pas toujours de frontière technique nette.

Les messages structurés et les étiquettes de provenance peuvent améliorer cette séparation. Les développeurs peuvent indiquer quel contenu provient de l’utilisateur, d’une page web, d’un outil ou de l’application. Toutefois, le modèle doit toujours interpréter du contenu externe lorsque la tâche dépend de sa signification.

La recherche publiée sous le titre BrowseSafe a évalué les risques d’injection de prompt dans les agents navigateurs et examiné les défenses dans des environnements réalistes. Ce travail reflète un consensus émergent : la détection aide, mais l’architecture du navigateur et la conception des autorisations déterminent l’impact final.

C’est pourquoi un classificateur parfait ne réglerait pas l’ensemble du problème. Les classificateurs traitent eux aussi un langage ambigu, et les attaquants peuvent tester de nouvelles variations. Les défenseurs ont besoin de plusieurs contrôles indépendants afin qu’une erreur de jugement ne déverrouille pas toute la session de navigateur de l’utilisateur.

Les défenses d’Amazon et Google privilégient le contrôle à la détection parfaite

Amazon et Google mettent en place des défenses à plusieurs couches, car aucune des deux entreprises ne peut s’appuyer sur un seul filtre d’injection de prompt.

Google a décrit une architecture qui vérifie les actions des agents avant qu’elles n’atteignent le navigateur. Son User Alignment Critic est un composant distinct conçu pour évaluer si une action proposée correspond à l’objectif déclaré de l’utilisateur. Cette séparation contribue à empêcher l’agent principal d’approuver sa propre interprétation risquée.

Google utilise également des informations sur l’origine, des confirmations d’action, l’entraînement des modèles et des systèmes de détection. Les opérations sensibles peuvent exiger l’approbation explicite de l’utilisateur. Le navigateur peut limiter les informations qui parviennent à l’agent et préserver les frontières de sécurité autour des identifiants.

Dans sa conception de Chrome agentique, Google reconnaît que l’exposition à du contenu web non fiable crée un risque inhérent d’injection indirecte de prompt. Cette formulation est significative. L’entreprise présente le problème comme une menace architecturale nécessitant une atténuation continue.

La confirmation d’action est utile, car elle rétablit le jugement humain avant une étape importante. Un utilisateur peut refuser un achat, un message, une connexion ou un transfert de données inattendu. Pourtant, des invites fréquentes peuvent aussi devenir routinières, créant la même fatigue que celle observée avec les avis sur les cookies et les fenêtres d’autorisation.

Les confirmations doivent donc se concentrer sur les transitions significatives. Envoyer des données vers un nouveau domaine mérite davantage d’attention que faire défiler une page. Ouvrir un gestionnaire de mots de passe présente un risque plus élevé qu’extraire un titre public. Un modèle d’approbation uniforme traite des actions inégales comme si elles étaient équivalentes.

Amazon met l’accent sur l’application de politiques autour de son environnement de navigateur géré. Les développeurs qui utilisent Bedrock AgentCore peuvent appliquer des politiques Chrome Enterprise limitant les sites sur lesquels un agent navigue. Ces règles fonctionnent au niveau du navigateur, indépendamment du prompt ou du raisonnement de l’agent.

Cette distinction est importante. Un modèle peut être manipulé, mais une politique déterministe de réseau ou de navigateur bloque toujours une destination interdite. Les contrôles de politiques de navigation d’Amazon permettent aux créateurs de définir les emplacements autorisés et bloqués avant que l’agent ne commence son travail.

Une liste d’autorisation peut réduire fortement l’exposition pour des flux de travail d’entreprise ciblés. Un agent d’approvisionnement peut avoir besoin d’accéder à un petit ensemble de portails fournisseurs approuvés. Un agent de service client peut n’exiger que la plateforme d’assistance et un système interne de connaissances.

Ces limites deviennent plus difficiles à maintenir pour la recherche générale. Un agent chargé de comparer des produits ou de suivre l’actualité a besoin d’un large accès au web. Plus la tâche est ouverte, moins une liste blanche stricte de destinations est utile.

L’isolation apporte une autre couche de protection. Une session de navigateur gérée peut séparer l’activité de l’agent du profil de navigation quotidien de l’employé. Si l’agent est compromis, il ne devrait pas automatiquement hériter de tous les cookies, onglets ouverts, identifiants enregistrés et extensions accessibles à l’utilisateur.

L’isolation ne détermine pas si une instruction est malveillante. Elle limite les ressources disponibles après une mauvaise décision. C’est la même logique pratique qui sous-tend les conteneurs, les machines virtuelles et les comptes de service à privilèges restreints.

Le principe du moindre privilège étend cette approche aux outils et aux données. Un agent qui doit uniquement lire des pages publiques ne devrait pas être autorisé à envoyer des e-mails. Un agent qui prépare une transaction ne devrait pas pouvoir l’approuver. Un agent qui lit des documents ne devrait pas automatiquement accéder à tous les dossiers connectés.

Les approches de défense d’Amazon et Google convergent donc vers un principe commun. Les modèles resteront faillibles, la sécurité doit donc exister en dehors du modèle. Les politiques de navigateur, les frontières d’identité, les étapes d’approbation, la journalisation et les sessions isolées peuvent contenir une erreur que la détection n’a pas réussi à arrêter.

Le véritable compromis oppose capacités et confinement

Toute défense qui réduit de manière fiable l’impact des injections de prompt limite également une partie de l’autonomie de l’agent.

Un agent de navigation devient plus utile lorsqu’il peut se déplacer librement entre les services, mémoriser le contexte et accomplir des tâches en plusieurs étapes. Ces mêmes capacités augmentent le nombre de décisions qu’un attaquant peut influencer. Le compromis de sécurité est inhérent à la proposition de valeur du produit.

Prenons un agent chargé d’organiser un voyage. Il peut rechercher des vols, comparer des hôtels, consulter un calendrier, récupérer des informations de fidélité et préparer une réservation. Si un contenu externe détourne le plan, l’agent pourrait exposer des données personnelles ou sélectionner une destination contrôlée par un attaquant.

Un système fortement confiné pourrait empêcher ce résultat en limitant l’agent à une recherche en lecture seule. Toutefois, il ne finaliserait plus la réservation. L’ajout d’une autorisation d’achat rétablit la commodité tout en augmentant l’impact d’une action erronée.

Le même schéma s’applique au sein des entreprises. Un agent commercial pourrait étudier un compte et rédiger une prise de contact avec peu de risques. Lui donner l’autorisation d’envoyer des messages, de mettre à jour des dossiers clients et de joindre des documents internes crée une automatisation plus précieuse, mais aussi un périmètre de défaillance plus étendu.

C’est pourquoi les injections de prompt doivent être évaluées comme un problème de sécurité des capacités. Les équipes doivent se demander ce que l’agent peut faire après avoir accepté une instruction malveillante. Le taux de réussite d’une attaque contre le modèle compte, mais la conséquence autorisée compte davantage.

Un générateur de résumés en lecture seule présente un risque différent de celui d’un agent connecté à des systèmes de paiement. Les deux peuvent produire des résultats trompeurs. Un seul peut transformer une mauvaise interprétation en transaction externe sans contrôle supplémentaire.

Les fournisseurs mettent parfois en avant des taux de détection plus élevés comme preuve d’une sécurité accrue. Ces résultats peuvent être utiles, mais ils dépendent de l’ensemble de tests, des connaissances de l’attaquant, de la version du modèle et des outils autorisés. Une attaque adaptative peut cibler des cas qu’un benchmark n’a pas inclus.

Les faux positifs engendrent également des coûts opérationnels. Un modèle défensif peut refuser un contenu légitime qui ressemble à une tentative d’injection. Les équipes de sécurité peuvent réduire les omissions en augmentant la sensibilité, mais les utilisateurs rencontrent alors davantage de tâches bloquées et de confirmations inutiles.

Le problème de conception n’a pas de point d’arrivée fixe, car les capacités des agents continuent d’évoluer. Une protection testée contre le résumé de pages ne couvre pas automatiquement la navigation visuelle, les téléchargements de fichiers, les boîtes de dialogue du système d’exploitation ou les interactions avec un nouveau protocole d’outils.

Les mises à jour du navigateur peuvent introduire des comportements supplémentaires. Les mises à niveau du modèle peuvent modifier la manière dont l’agent interprète des instructions ambiguës. Un service connecté peut exposer de nouvelles actions sans que le fournisseur du navigateur contrôle son interface. Les tests de sécurité doivent suivre le système complet, et non un seul instantané du modèle.

Les extensions et intégrations tierces compliquent encore la situation. Elles peuvent étendre le contenu visible par l’agent ou fournir de nouveaux chemins d’exécution. Une entreprise peut configurer avec soin le navigateur principal tout en négligeant une extension disposant d’un large accès aux pages.

Une vision sceptique est donc nécessaire. Les défenses en couches réduisent le risque, mais les déclarations publiques sur des « agents sécurisés » ne doivent pas être interprétées comme une immunité. Les entreprises devraient divulguer l’environnement testé, les actions bloquées, les règles de confirmation par l’utilisateur et la surface d’attaque résiduelle.

Dans le même temps, déclarer que chaque navigateur IA est intrinsèquement dangereux simplifie excessivement la décision. Le risque dépend des autorisations de l’agent, des données accessibles, de l’isolation et de la tâche. Un assistant de recherche contraint peut convenir à un environnement à faible risque, même lorsqu’un agent d’achat ne le peut pas.

Les équipes de sécurité ont besoin de catégories de déploiement plutôt que d’une approbation globale. Les agents à faible risque peuvent fonctionner dans des sessions isolées en lecture seule. Les systèmes à risque intermédiaire peuvent préparer des actions pour examen humain. Les flux de travail à haut risque devraient exiger une autorisation déterministe en dehors du modèle.

Cette structure accepte le compromis fondamental plutôt que de prétendre qu’il a disparu. Les utilisateurs bénéficient toujours de l’automatisation, mais l’autonomie n’augmente que lorsque les contrôles environnants peuvent absorber une défaillance du modèle.

Qui subit la pression du problème des injections de prompt

Les fournisseurs de navigateurs font les gros titres, mais les équipes d’identité et d’applications en entreprise supportent une grande partie de la charge pratique.

Google doit protéger les utilisateurs dont les profils de navigateur contiennent déjà des sessions précieuses. Chrome peut connecter un agent aux e-mails, calendriers, documents, comptes d’achat et outils professionnels. Une seule interface peut donc exposer de nombreux domaines de confiance différents.

Les clients d’Amazon font face à une responsabilité différente. Bedrock AgentCore fournit des composants et des contrôles gérés, mais les développeurs décident toujours des destinations, identités, outils et données auxquels un agent peut accéder. Un service sécurisé peut prendre en charge une configuration d’application dangereuse.

Microsoft, OpenAI, Anthropic et Perplexity font face à la même pression concurrentielle. Les utilisateurs attendent des agents de navigation qu’ils accomplissent davantage de travail, tandis que les chercheurs en sécurité testent chaque nouvelle capacité. Une conception restrictive peut paraître moins utile face à un concurrent qui autorise une automatisation plus large.

Ce cycle concurrentiel peut encourager les fournisseurs à étendre les autorisations plus rapidement que les entreprises ne mettent à jour leur gouvernance. De nouvelles fonctionnalités d’agent peuvent arriver via des navigateurs et outils de productivité familiers, en évitant l’examen des achats requis pour une application distincte.

Les équipes de sécurité devraient inventorier les fonctionnalités agentiques comme des capacités, et non comme des noms de produits. Les questions pertinentes portent sur l’accès aux sessions authentifiées, aux fichiers locaux, aux applications connectées, à la mémoire, à la messagerie, aux téléchargements et à l’exécution de code.

Les responsables d’applications doivent également reconsidérer le contenu des pages web. Un tableau de bord interne était autrefois conçu principalement pour des lecteurs humains. Si les agents consomment son texte à la fois comme information et comme instruction potentielle, la provenance du contenu devient une composante de la sécurité applicative.

Les équipes d’identité doivent décider si les agents partagent des identifiants humains ou reçoivent des identités de service distinctes. Les sessions partagées sont pratiques, mais affaiblissent la responsabilité. Des identités séparées favorisent des autorisations plus strictes, des journaux plus clairs et une révocation plus rapide.

Les développeurs ont besoin de journaux d’événements expliquant ce que l’agent a vu et pourquoi il a agi. L’historique de navigation classique montre les pages visitées, mais il peut ne pas capturer le contenu exact, la décision du modèle, l’appel d’outil et l’autorisation ayant conduit à l’action de l’agent.

Les intervenants chargés de la réponse aux incidents rencontrent une autre difficulté. Une injection de prompt réussie peut ressembler à une activité utilisateur normale, car l’agent utilise des identifiants valides et des fonctions légitimes du navigateur. La détection doit examiner l’intention, la séquence, la destination et les mouvements de données.

Les employés ont également besoin de signaux plus clairs. Ils devraient savoir quand un agent lit une page, passe dans un autre service, accède à des informations privées ou prépare une action irréversible. Une petite icône animée ne communique pas l’intégralité de cette transition de confiance.

Les acheteurs en entreprise devraient demander aux fournisseurs comment les défenses fonctionnent lorsque le contenu est visuel, obscurci, multilingue ou réparti sur plusieurs étapes. Ils devraient également demander si les contrôles de sécurité fonctionnent indépendamment de l’agent principal et si les politiques restent applicables après des changements de modèle.

L’évaluation la plus solide inclut des tests adversariaux sur les flux de travail réels de l’organisation. Un benchmark générique ne peut pas reproduire chaque application interne, source de données et combinaison d’autorisations. Les équipes de red team devraient tester des objectifs réalistes tout en faisant varier le contenu malveillant.

Les contrats d’approvisionnement doivent également inclure des conditions claires concernant les incidents. Les acheteurs devraient comprendre la conservation des journaux, la divulgation des vulnérabilités, les pratiques de mise à jour des modèles et la responsabilité liée aux configurations dangereuses. Les injections de prompt franchissent les frontières entre le comportement du fournisseur et la conception du client.

Aucune entreprise ne peut résoudre ce problème de responsabilité partagée par une seule mise à jour du modèle. Les fournisseurs doivent proposer des contrôles applicables, tandis que les clients doivent les configurer en fonction de tâches spécifiques. Les deux parties ont besoin de preuves que ces contrôles fonctionnent ensemble.

Ce qu’il faut surveiller ensuite chez Amazon, Google et les fournisseurs de navigateurs IA

La prochaine phase sera jugée sur les preuves de confinement, et non sur des promesses selon lesquelles les injections de prompt ont été éliminées.

Le premier signal sera de savoir si les fournisseurs publient des évaluations reproductibles couvrant des flux de travail complets dans le navigateur. Les tests devraient inclure du texte caché dans les pages, des images, des actions entre onglets, la mémoire stockée, les comptes connectés et la manipulation d’intentions en plusieurs étapes. Un seul benchmark de refus offre une vision trop étroite.

Les résultats devraient distinguer la détection de l’impact. Une attaque qui influence un résumé diffère d’une attaque qui envoie des données ou finalise un achat. Les acheteurs doivent savoir à la fois à quelle fréquence un agent suit un contenu hostile et quels contrôles arrêtent l’action qui en résulte.

Le deuxième signal sera l’utilisation plus large de restrictions déterministes. Les politiques de navigateur d’Amazon offrent un exemple, car elles peuvent bloquer des destinations indépendamment du raisonnement du modèle. Les vérifications d’action et les barrières d’autorisation de Google jouent un rôle similaire en matière d’alignement avec l’utilisateur.

Il faudra observer si ces contrôles deviennent plus faciles à configurer de manière granulaire. Les entreprises ont besoin de politiques fondées sur la destination, la sensibilité des données, le type d’action, l’identité et la tâche. Un unique interrupteur global pour le navigateur ne peut pas représenter ces différences.

Le troisième signal concernera la manière dont les fournisseurs traitent les chaînes d’attaque nouvellement divulguées. Des correctifs rapides restent importants, même lorsque la catégorie de vulnérabilité persiste. Les notes de version devraient préciser si un correctif modifie la détection, la portée des autorisations, l’isolation ou l’architecture sous-jacente de l’agent.

Les chercheurs continueront de trouver des variantes parce que le comportement des agents est non déterministe. Un correctif qui bloque une expression ou un modèle de page web ne traite pas la collision d’intentions dans différents contextes. Les améliorations durables devraient retirer des capacités des chemins non fiables ou ajouter une autorisation indépendante.

La hausse signalée par Google des schémas web malveillants rend ce travail urgent. La sophistication des attaques restait limitée dans l’analyse de l’entreprise, mais l’augmentation de l’activité offre aux attaquants davantage d’occasions de tester des produits déployés. L’adoption plus large des agents de navigation accroît la valeur des techniques réussies.

La concurrence entre Amazon et Google révélera également quels compromis de sécurité les utilisateurs acceptent. Google peut placer des confirmations directement dans Chrome, où les utilisateurs les voient. Amazon peut fournir aux développeurs des politiques d’infrastructure, mais chaque client doit décider du niveau de restriction de ces politiques.

Pour les déploiements en entreprise, la norme à court terme devrait être simple. Isolez l’agent, donnez-lui une identité distincte, restreignez les destinations, réduisez au minimum les outils et exigez une approbation avant toute action importante. Journalisez chaque transition entre contenu non fiable et comportement privilégié.

Les travailleurs du savoir devraient, lorsque cela est possible, conserver leurs comptes sensibles en dehors des sessions expérimentales d’agents. Ils devraient également examiner les messages, transactions, téléchargements et transferts de données proposés. Mettre à jour le navigateur est important, mais cela ne peut pas résoudre le problème d’interprétation sous-jacent.

Les développeurs devraient considérer chaque page web, e-mail, document téléversé et note récupérée comme une entrée non fiable. Ils devraient partir du principe que le modèle principal finira par mal classifier une partie de ces contenus. Des contrôles externes à ce modèle doivent déterminer ce qui se produit ensuite.

La conclusion selon laquelle il n’existe pas de correctif parfait est inconfortable, car elle modifie la question du déploiement. Les équipes devraient cesser de se demander si un agent de navigateur est immunisé contre l’injection de prompts. Elles devraient se demander si une seule injection réussie peut atteindre quoi que ce soit d’important.

Avant d’activer la prochaine fonctionnalité autonome, cartographiez sa pire action autorisée et déterminez si le bénéfice justifie cette exposition. Si la réponse n’est pas claire, maintenez l’agent en lecture seule ou exigez une approbation humaine. La course entre Amazon et Google produira de meilleures défenses, mais une adoption responsable dépend toujours du confinement.