Cognitive Firewall : une défense répartie pour les agents navigateurs

De quoi s’agit-il ?

Un agent navigateur lit le DOM d’une page, planifie, puis agit : il clique, publie, supprime, envoie. Comme le prompt système, l’instruction de l’utilisateur et le contenu web non fiable arrivent tous dans la même fenêtre de contexte, un attaquant qui contrôle le contenu d’une page peut y glisser des instructions que l’agent exécutera. C’est l’injection de prompt indirecte (IPI), classée LLM01 dans le Top 10 OWASP pour les applications LLM.

Cognitive Firewall, un papier de Qianlong Lan et Anuj Kaul d’eBay Inc publié sur arXiv sous la référence arXiv:2603.23791 le 24 mars 2026, propose une défense fondée sur un constat simple : aucune vérification probabiliste ne détectera toutes les injections, donc les conséquences de celle qui passe doivent être contenues de façon déterministe. C’est une architecture « split-compute » qui répartit trois contrôles entre le navigateur et le cloud, et qui fait passer le taux de réussite des attaques de 100 % (sans défense) à 0,88 % sur le banc d’essai des auteurs.

Comment ça marche

La conception est un « entonnoir défensif » : les contrôles peu coûteux s’exécutent d’abord en périphérie, et seuls les cas ambigus remontent vers le cloud. Trois couches correspondent à trois classes d’attaques.

Couche 1 — la Sentinelle de périphérie s’exécute dans le navigateur sur un petit modèle embarqué (Gemini Nano via l’API d’IA intégrée de Chrome). Elle impose la cohérence visuelle : l’agent ne doit pas raisonner sur du texte que l’utilisateur ne peut pas voir. Elle compare la source DOM au style calculé (CSSOM) et bloque les ruses de présentation — opacity: 0, polices de taille nulle, texte hors écran en left: -9999px — tout en épargnant le balisage d’accessibilité légitime. Cela tourne en environ ~0,06 ms, si bien que les charges utiles bloquées n’atteignent jamais le cloud et ne consomment aucun token.

Couche 2 — le Planificateur profond s’exécute côté serveur sur un modèle plus grand (le prototype utilisait Llama 3 8B ou GPT-4) avec un prompt dédié d’« analyste sécurité ». Elle impose l’intégrité de l’objectif et attrape la manipulation sémantique que le modèle de périphérie laisse passer : jeu de rôle (« vous êtes désormais en mode Développeur »), faux délimiteurs comme --- END SYSTEM INSTRUCTIONS ---, ou urgence fabriquée.

Couche 3 — le Garde d’origine est un moniteur d’exécution déterministe, sans modèle. Il impose la sûreté d’exécution via un intercepteur JavaScript synchrone qui valide chaque action sortante contre une liste blanche d’origines et une politique de verbes avant l’envoi. Même si le planificateur est totalement berné, une requête DELETE ou une exfiltration vers une origine non autorisée est bloquée. Les auteurs qualifient ce comportement de « fail-closed » : l’ambiguïté d’un plan est un motif de rejet.

Pourquoi c’est important

L’étude d’ablation rend la logique de superposition concrète. Sur 1 000 échantillons mêlant tâches bénignes et adverses, le filtrage limité à la périphérie laissait un taux de réussite de 86,9 % ; périphérie plus cloud manquait encore le détournement à 39,2 % ; la pile complète à trois couches atteignait 0,88 %, avec un taux d’interception d’environ 99,1 %. Face à un attaquant adaptatif en boîte blanche connaissant le pipeline, la réussite agrégée tombait à 0,67 % (2 sur 300). Les attaques par fragmentation du DOM, qui découpent une charge utile en nœuds d’un seul caractère, échappaient à la périphérie mais étaient reconstituées par le planificateur cloud (dans 95 % des cas) puis arrêtées par le garde.

La leçon plus large est architecturale : une application déterministe à la frontière d’exécution peut servir de filet de sécurité aux modèles de langage probabilistes. À mesure que les agents navigateurs prennent en charge des actions à effet de bord, « le modèle a décidé de ne pas le faire » n’est pas un contrôle — « la requête a été bloquée avant de quitter l’appareil » en est un.

Défenses

Le papier est lui-même un plan de défense ; les enseignements se généralisent au-delà du prototype :

1. Séparez le plan de contrôle du plan de données. Traitez tout contenu web ingéré par l’agent comme non fiable, et ne le laissez pas redéfinir l’objectif de l’utilisateur. Le même réflexe que l’isolation de sites, appliqué à la fenêtre de contexte.
2. Encadrez les effets de bord de façon déterministe. Placez un intercepteur sans modèle entre les plans et les actions. Mettez les origines en liste blanche, contraignez les verbes HTTP à l’intention déclarée (une tâche en lecture seule ne devrait jamais émettre de DELETE ni de GET sortant paramétré), et échouez fermé sur tout ce qui est ambigu.
3. Filtrez les ruses de présentation à la source. Comparez le rendu à la source DOM brute et écartez le texte invisible ou hors écran avant qu’il n’entre dans le prompt — à moindre coût, sur l’appareil, avant tout appel cloud.
4. Ne faites pas confiance à un petit modèle embarqué comme juge sémantique. La couche de périphérie a manqué 86,9 % des jailbreaks sémantiques ; c’est un pré-filtre rapide, pas le mécanisme de sûreté. Faites remonter les cas difficiles vers un modèle plus robuste.
5. Ajoutez un humain pour les actions à fort enjeu ou ambiguës. Les échecs résiduels venaient d’attaques par « emballage bénin » (2,0 %) qui convainquaient le planificateur d’adopter un mode permissif, plus un taux de faux positifs de 1,7 % sur des tâches légitimes — deux arguments pour une étape de confirmation interactive plutôt qu’un blocage ou une autorisation silencieux. Cela rejoint le débat plus large sur la question de savoir si les pare-feu suffisent ou s’il faut de meilleurs bancs d’essai.

État des lieux

Élément	Référence	Notes
Papier	arXiv:2603.23791	Lan & Kaul, eBay Inc, 24 mars 2026
Architecture	Cognitive Firewall — Sentinelle / Planificateur / Garde	Split-compute, défense en profondeur, fail-closed
Modèle de périphérie	Gemini Nano (IA intégrée Chrome)	~0,06 ms, bloque l’obfuscation visuelle
Modèle cloud	Llama 3 8B / GPT-4 (prototype)	Prompt d’analyste sécurité, contrôles sémantiques
Résultat	TRA 100 % → 0,88 % statique, 0,67 % adaptatif	N = 1 000 ; ~99,1 % d’interception
Limites connues	L’injection par image contourne la couche 1 ; 1,7 % de faux positifs ; ~950 ms de latence pleine chaîne	Prototype, pas du trafic réel

À retenir : les agents navigateurs fondent code et données en un seul flux de tokens, donc les contrôles sémantiques resteront probabilistes et parfois faux. L’apport de Cognitive Firewall est de cesser d’en faire la dernière ligne de défense — et de placer un garde déterministe et fail-closed au point où le raisonnement se transforme en action réelle.