# 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.

## 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.

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