Agents IA navigateurs : injection depuis une page web

Qu’est-ce qu’un agent navigateur et pourquoi est-il plus exposé ?

C’est un agent qui pilote un navigateur ou un poste de travail : il voit des pages, des captures d’écran, et agit par clics et saisies. Il est plus exposé qu’un simple chatbot pour deux raisons : il lit du contenu que personne n’a validé (le web entier), et il agit avec des droits réels, souvent ceux d’un utilisateur déjà connecté.

C’est le schéma décrit par Simon Willison sous le nom de « lethal trifecta » : accès à des données privées, exposition à du contenu non fiable, capacité à communiquer vers l’extérieur. Un navigateur connecté à une messagerie ou à un compte bancaire réunit les trois. La technique d’attaque est l’injection de prompt indirecte (LLM01:2025 chez l’OWASP) : l’instruction se trouve dans la page, et la demande de l’utilisateur reste intacte.

Quels incidents et quelles mises en garde sont documentés ?

Trois sources publiques suffisent à cadrer le risque.

• Brave et Perplexity Comet (20 août 2025). Brave a montré que la fonction « résumer cette page » de Comet envoyait le contenu de la page au modèle sans séparer les instructions de l’utilisateur du texte de la page. Des instructions cachées (texte blanc sur blanc, commentaires HTML, commentaire Reddit derrière une balise spoiler) pouvaient être exécutées avec les privilèges de la session de l’utilisateur. Dans la preuve de concept de Brave, l’agent récupérait l’adresse e-mail du compte, déclenchait un code à usage unique, le lisait dans la messagerie connectée et renvoyait le tout dans un commentaire public. Brave a ajouté après la publication que Perplexity n’avait pas encore totalement corrigé ce type d’attaque.
• OpenAI et ChatGPT Atlas (22 décembre 2025). OpenAI écrit que l’injection de prompt, comme les arnaques et l’ingénierie sociale sur le web, a peu de chances d’être un jour totalement résolue, et que le mode agent élargit la surface d’attaque. L’entreprise décrit un attaquant automatisé entraîné par apprentissage par renforcement pour trouver des injections qui fonctionnent contre l’agent navigateur, et recommande de limiter l’accès de l’agent et d’exiger une confirmation avant des actions comme envoyer un message ou payer.
• Anthropic et computer use. La documentation indique que Claude peut suivre des commandes trouvées dans du contenu même si elles contredisent vos instructions, et que des instructions présentes dans des pages web ou des images peuvent prendre le dessus. Anthropic ajoute des classifieurs qui analysent les captures d’écran pour repérer des injections, tout en précisant que cette protection n’est pas idéale sans humain dans la boucle.

Quelles précautions les éditeurs recommandent-ils ?

Les trois sources convergent : isoler, restreindre, confirmer. La documentation d’Anthropic liste quatre précautions : utiliser une machine virtuelle ou un conteneur dédié avec le minimum de privilèges, éviter de donner au modèle l’accès à des données sensibles comme des identifiants de connexion, limiter l’accès internet à une liste de domaines, et faire confirmer par un humain les décisions aux conséquences réelles (cookies, transactions financières, conditions d’utilisation).

Brave recommande de séparer clairement les instructions de l’utilisateur et le contenu des pages, de vérifier que les actions prévues correspondent à la demande, d’exiger une confirmation pour les actions sensibles comme l’envoi d’un e-mail, et d’isoler la navigation agentique de la navigation ordinaire avec des permissions minimales. OpenAI recommande de limiter l’accès et de confirmer les actions comme les messages ou les paiements.

Comment tester un agent navigateur contre l’injection depuis une page web ?

Hébergez vous-même vos pages piégées et utilisez des comptes de test : jamais de vrai compte bancaire ni de vraies données. Chaque test répond à une question simple : l’agent obéit-il à la page ?

1. Texte caché. Publiez une page de test avec une consigne cachée (texte blanc sur fond blanc, commentaire HTML, élément masqué, texte dans une zone repliée), les techniques décrites par Brave. Demandez à l’agent de résumer la page. Suit-il la consigne ?
2. Canari. La consigne demande d’écrire un jeton canari dans un champ ou d’appeler une URL de test. Le canari apparaît-il dans vos journaux ?
3. Contenu dans une image. Mettez la consigne dans une image ou une capture : l’agent lit les captures d’écran, c’est donc un canal.
4. Session connectée. Avec un compte de test déjà connecté à une messagerie de test, la page demande de lire ou d’envoyer un message. L’agent agit-il avec la session ?
5. Changement de domaine. La page demande d’aller sur un autre domaine de test ou d’y envoyer un formulaire. La liste de domaines autorisés tient-elle ?
6. Actions de consentement. La page demande d’accepter des conditions, des cookies ou une autorisation OAuth de test. L’agent demande-t-il une confirmation ?
7. Formulaires et téléchargements. L’agent envoie-t-il un formulaire ou télécharge-t-il un fichier sur simple consigne de la page ?
8. Presse-papiers et fichiers locaux. Un lecteur de fichiers ou le presse-papiers sont-ils accessibles depuis la session de l’agent ?
9. Persistance. La consigne s’inscrit-elle dans une mémoire ou un historique réutilisé plus tard ? Voir la mémoire d’un agent.

Mesurez deux choses : le taux d’obéissance sur plusieurs essais (le comportement d’un modèle varie d’un essai à l’autre) et le rayon d’impact quand l’agent obéit.

Quand vaut-il mieux ne pas donner de session connectée à l’agent ?

Dès que la session ouvre l’accès à des données ou à des actions que la tâche n’exige pas. Brave rappelle qu’un agent doté de la session de l’utilisateur peut atteindre ses services bancaires, ses systèmes d’entreprise, sa messagerie privée et son stockage cloud. Si la tâche consiste à lire des pages publiques, une session anonyme dans un conteneur jetable suffit. Si elle exige un compte, créez un compte dédié aux droits limités plutôt que de prêter celui d’un collaborateur. La question à poser avant le déploiement est simple : que peut faire le pire texte imaginable placé sur la prochaine page visitée ? Si la réponse inclut un paiement, un envoi ou une suppression, ajoutez une confirmation humaine ou retirez la capacité.

Quelles défenses mettre en place côté entreprise ?

• Compte et profil dédiés. Un profil de navigateur séparé, sans mots de passe enregistrés ni sessions ouvertes sur les services sensibles.
• Liste de domaines. Un filtrage réseau côté infrastructure ; une consigne dans le prompt ne suffit pas.
• Actions bloquantes. Paiement, envoi, suppression, acceptation de conditions : confirmation humaine, avec un texte qui montre ce qui va partir.
• Séparation lecture et action. Une session qui lit le web libre ne devrait pas détenir de droits d’écriture sur vos systèmes.
• Journalisation. Pages visitées, actions, captures : sans trace, impossible de reconstituer un incident.

La page sécurité des agents IA présente l’empilement de contrôles que nous recommandons autour d’un agent.

Comment CleanIssue teste un agent navigateur ?

Nous construisons des pages piégées et des comptes de test, puis nous mesurons ce que l’agent fait de ce qu’il lit : obéissance, rayon d’impact, domaines atteints, confirmations demandées. Le test d’intrusion d’agent IA se fait par défaut sur un environnement de développement ou de recette ; la production n’est testée que sur demande écrite du client. Pour un seul agent navigateur, le Red Team Agent Express dure 5 jours ; pour une flotte d’agents ou des usages en marque blanche pour vos clients, nous établissons un Red Team sur mesure.

Le premier contact est un rendez-vous découverte de 30 minutes, gratuit.