# 3. Étude de cas : une extension de navigateur pilotée par IA

Pour illustrer concrètement le risque décrit à la section précédente, voici
un cas **publiquement documenté** dans la communauté de la recherche en
sécurité (nom volontairement anonymisé ici — ce guide ne vise ni à
identifier ni à discréditer un produit précis, seulement à expliquer le
mécanisme).

## Le scénario

Une extension de navigateur permettait à un assistant IA de **piloter le
navigateur** de l'utilisateur : cliquer, remplir des formulaires, lire le
contenu des pages visitées. Des chercheurs ont montré qu'en enchaînant
plusieurs faiblesses (une liste d'autorisation trop permissive combinée à
une faille de type XSS sur un composant tiers de la page), il était possible
qu'une page web piégée influence l'agent **sans clic et sans invite de
permission visible** — l'utilisateur n'avait rien fait d'inhabituel, la page
elle-même contenait le piège.

> ATTENTION : le point le plus inquiétant de ce cas n'est pas la technique
elle-même, mais l'ABSENCE totale de signal côté utilisateur — pas de
fenêtre de permission, pas de clic suspect, pas de comportement visible
différent d'une navigation normale. C'est ce qui rend ce type d'attaque
particulièrement difficile à détecter a posteriori par la victime elle-même.

## Pourquoi ce cas est instructif

Il ne s'agit pas d'un défaut du modèle de langage lui-même, mais de la
**surface d'attaque introduite par l'outil** qu'on lui donne : piloter un
navigateur généraliste, c'est exposer l'agent à n'importe quel contenu de
n'importe quelle page, avec toute la richesse (et donc tous les risques)
du rendu HTML, CSS et JavaScript modernes.

## Ce que ce cas enseigne pour la conception d'un agent

- Plus un outil donné à l'agent a une **surface d'action large et
  généraliste** (naviguer partout, exécuter du JavaScript arbitraire), plus
  la surface d'attaque potentielle est grande.
- Un outil à **routes fixes et connues d'avance** (appeler une API précise,
  toujours de la même façon) réduit structurellement ce risque : il n'y a
  pas de boucle « lire une page -> décider -> agir » qu'un contenu piégé
  pourrait détourner, car il n'y a rien à décider à partir du contenu lu.
- C'est exactement le principe appliqué à la section 5 de ce guide.

> ASTUCE : face à un outil qui promet de faire « n'importe quoi » sur un
navigateur généraliste en votre nom, la question à se poser n'est pas
seulement « est-ce pratique ? » mais « quelle est la surface de contenu
externe que cet outil va lire avant d'agir, et qui la contrôle ? ».

*(Schéma disponible : `schema.svg`, dans ce dossier.)*