Les agents qui contrôlent un navigateur — Claude Computer Use, OpenAI Operator, Anthropic Skills, browser-use, Steel — sont devenus en quelques mois l'un des cas d'usage les plus visibles des agents autonomes. Réserver un restaurant, remplir un formulaire, faire des achats, naviguer dans une interface admin. Cas utile, surface d'attaque massive : le navigateur est l'un des environnements les plus complexes et les plus exposés à du contenu hostile qui existe.
Voici la posture défensive minimale pour déployer un agent browser sans transformer la fonction en porte ouverte.
Pourquoi le browser est un cas particulier
Trois caractéristiques rendent l'agent browser plus risqué que l'agent "outil HTTP" classique :
1. Tout le web est attacker-controlled
Une page web peut contenir du HTML, du JavaScript, du contenu invisible, des frames imbriquées, des popups, du contenu modifié à la volée. L'agent doit interpréter visuellement (via screenshot pour les modèles vision) ou structurellement (via DOM). Les deux sont manipulables.
2. Le navigateur agrège des contextes
Un navigateur typique a des cookies, des sessions actives, un history, des mots de passe stockés, parfois des extensions avec leurs propres permissions. Un agent qui prend le contrôle hérite de tout ça.
3. Les actions sont à fort impact par défaut
Cliquer "envoyer", "valider", "supprimer", "payer" sur un site web sont des actions à fort impact, sans confirmation supplémentaire après le clic. Une hallucination ou une prompt injection se traduit en action externe immédiate.
La posture défensive en 6 points
1. Browser isolé par session
L'agent browser ne tourne jamais dans le navigateur personnel de l'utilisateur. Il tourne dans :
- Un container avec un Chromium / Chrome dédié.
- État vide à chaque session (pas de cookies persistants, pas d'history, pas d'extension).
- Profile temporaire, supprimé à la fin.
- Idéalement un container Docker éphémère avec un user dédié et un home jetable.
C'est le réflexe que Anthropic Computer Use matérialise par défaut (container Docker). Beaucoup d'implémentations custom ne le font pas.
2. Identités fédérées et éphémères pour les sites
Pour les sites où l'agent doit se connecter :
- Pas de mot de passe utilisateur stocké.
- OAuth / SAML / OIDC avec scope minimal.
- Token éphémère récupéré au début de la session, supprimé à la fin.
- Pas de "remember me" coché.
Pour un site sans OAuth, utiliser un gestionnaire de credentials externe (1Password CLI, Bitwarden) qui ne stocke pas le mot de passe dans le browser de l'agent.
3. Allowlist d'URL
L'agent ne peut visiter que les URL d'une allowlist explicite. Pas de navigation libre sur le web. Si l'utilisateur dit "cherche moi X sur Google et clique sur le résultat le plus pertinent", l'agent doit :
- Soit refuser (mode strict).
- Soit demander confirmation utilisateur avant de quitter le domaine de départ.
- Soit naviguer dans un sous-mode "exploration" où aucune capability sensible n'est active.
Sans allowlist, n'importe quelle page web devient potentiellement un canal de prompt injection avec accès aux capabilities de l'agent.
4. Confirmation humaine sur les actions à effet irréversible
Avant de cliquer sur :
- Un bouton "envoyer" / "publier" / "confirmer".
- Un bouton de paiement.
- Un bouton "supprimer" / "fermer le compte".
…l'agent doit prendre un screenshot, le montrer à l'utilisateur, et attendre une confirmation. C'est friction, c'est nécessaire. Sans ça, le moindre détournement de l'agent (par un popup malicieux, par un contenu injecté dans le DOM) se traduit immédiatement en action.
5. Logging du parcours complet
- Toutes les URL visitées.
- Tous les screenshots pris.
- Toutes les actions effectuées (click, scroll, type, navigate).
- Tous les éléments cibles (sélecteur CSS, position, contenu).
Logs immuables, conservés au moins 90 jours. Indispensable pour reconstituer un incident.
6. Kill-switch visuel
L'utilisateur doit pouvoir interrompre l'agent à tout moment, idéalement avec un raccourci clavier ou un bouton visible en permanence dans l'UI. Le kill-switch doit :
- Arrêter immédiatement le browser.
- Geler l'état pour analyse.
- Ne pas effacer les logs.
Les attaques à anticiper
Injection via popup ou notification
Un site légitime peut afficher un popup avec un texte qui ressemble à une instruction utilisateur. L'agent peut le suivre. Défense : ne jamais interpréter un texte qui apparaît après le chargement initial comme une instruction utilisateur.
Injection visuelle pour modèles vision
Un site peut contenir du texte en arrière-plan invisible (couleur fond, opacité 0), ou du texte minuscule, ou du texte caché dans une image. Un modèle vision peut les lire et les interpréter comme instructions. C'est le pendant visuel du prompt injection caché en blanc sur blanc des documents PDF.
Défense : extraction structurée du DOM via accessibility tree plutôt que via screenshots, quand c'est possible. Et entraînement / fine-tuning des modèles vision pour ignorer ce qui n'est pas visible humainement.
Phishing inverse
Un attaquant fait visiter à l'agent un faux site qui ressemble au vrai (ex: faux PayPal). L'agent y saisit les credentials. Défense : vérification stricte du certificat TLS, allowlist de domaines, refus de toute URL non-allowliste pour les credentials sensibles.
Cross-site session hijacking via cookies persistants
Si l'agent garde des cookies persistants entre sessions, un site malicieux peut tenter de les lire. Défense : profile vide à chaque session (cf. point 1).
Le minimum livrable avant prod
Pour un agent browser qui agit sur le SI :
- Architecture documentée (container, isolation, identité).
- Liste des sites autorisés.
- Liste des actions à fort impact qui requièrent confirmation.
- Procédure de kill-switch testée.
- Audit log opérationnel et accessible.
- Tests adversariaux passés (au moins les 5 du red team agent).
Sans ces livrables, l'agent browser ne devrait pas être en prod sur des cas d'usage à enjeu.
Pour le confinement runtime général, Confinement d'un agent. Pour les inputs non fiables, Prompt injection indirecte via tool output.