L’injection indirecte est le caillou dans la chaussure des agents navigateur. Tu peux leur coller une liste blanche de domaines, des consignes propres et un joli bouton « valider » : si une page web contient une instruction piégée, l’agent peut quand même la prendre pour un ordre. Une étude publiée sur arXiv propose un pare-feu cognitif en trois étages pour limiter le problème sans envoyer chaque octet lu dans le nuage. L’idée est bonne, mais les chiffres demandent le même réflexe que le système : vérifier avant d’exécuter.
Le navigateur devient une surface d’attaque
Un agent navigateur ne se contente pas d’afficher une page. Il lit le DOM, interprète le texte, planifie une suite d’actions et appelle des outils : remplir un formulaire, consulter une boîte de réception, créer un ticket ou déclencher une requête. Le modèle reçoit donc, dans un même contexte, les instructions de l’utilisateur et du contenu provenant de sites qu’il ne contrôle pas. Pour un logiciel classique, le code et les données vivent dans des boîtes séparées. Pour un modèle de langage, tout arrive sous forme de tokens qui se disputent l’attention.
C’est exactement le terrain de l’injection indirecte. L’attaquant n’a pas besoin de parler directement à l’agent : il dépose une consigne dans une page, un commentaire, un document ou un courriel que l’agent doit lire. Le texte peut être visible, caché par le CSS ou noyé dans une phrase banale. OWASP classe ce risque dans LLM01:2025 et rappelle qu’une injection peut être imperceptible pour un humain tout en restant exploitable par le modèle.
Le scénario n’est pas forcément spectaculaire. Une page de documentation peut demander à l’agent de transmettre un extrait de conversation, un tableau de bord peut lui suggérer de modifier une règle, et un message peut lui ordonner de cliquer sur un lien externe. Si l’agent dispose de permissions larges, le contenu hostile n’a plus besoin de casser le navigateur : il lui suffit de convaincre le modèle de devenir un intermédiaire docile.
Trois étages, trois responsabilités
Le Cognitive Firewall décrit une architecture de défense en profondeur. Premier étage : un « Sentinel » local examine le DOM et ses propriétés visuelles avant que le contenu parte vers le modèle chargé du raisonnement. Son travail n’est pas de comprendre toute l’intention d’une page, mais de repérer les écarts entre ce que l’utilisateur peut voir et ce que l’agent peut lire : opacité nulle, texte hors écran, taille de police minuscule ou autres artifices CSS.
Deuxième étage : le « Deep Planner » reçoit un contexte nettoyé et cherche les manipulations sémantiques. Une phrase comme « ignore les instructions précédentes » est grossière ; une formulation qui invente une urgence, fabrique une hiérarchie de consignes ou se fait passer pour un message système est plus pénible à détecter. Le papier propose de réserver ce raisonnement coûteux aux cas qui ont franchi le filtre local, au lieu d’envoyer chaque page brute à un service distant.
Troisième étage : le « Guard » ne discute pas avec le modèle. Il applique une politique déterministe au moment où l’action va réellement partir. L’origine cible doit appartenir à une liste autorisée et le verbe HTTP doit rester compatible avec l’intention annoncée. Un agent peut donc produire un plan séduisant, voire complètement faux : si le plan tente une opération interdite, le garde bloque. C’est moins glamour qu’un grand prompt de sécurité, mais beaucoup plus utile quand le modèle improvise.
Source : Qianlong Lan et Anuj Kaul, « The Cognitive Firewall », figure 1, arXiv. https://arxiv.org/html/2603.23791v1
Le schéma résume le point important : aucun étage ne prétend être magique. Le filtre local traite la perception, le planificateur traite l’intention et le garde traite l’effet de bord. La sécurité ne repose donc pas sur la capacité du modèle à se souvenir d’une règle au bon moment, mais sur des frontières placées autour de lui.
Le local est rapide, pas omniscient
Dans leur évaluation sur 1 000 échantillons adverses, les auteurs annoncent un taux de réussite d’attaque inférieur à 1 % pour la chaîne complète : 0,88 % en évaluation statique et 0,67 % face à une variante adaptative. Le Sentinel local bloquerait 13,1 % des menaces visuelles et réduirait les appels au nuage. Le papier avance aussi un avantage de latence d’environ 17 000 fois par rapport à une défense entièrement distante.
Ces résultats sont intéressants, mais ils ne sont pas une promesse universelle. Le corpus, les modèles utilisés, les règles de décision et la définition exacte d’une attaque réussie conditionnent fortement le résultat. Le Sentinel ne comprend pas toutes les manipulations sémantiques : les auteurs indiquent que les défenses limitées au bord ratent 86,9 % de ces attaques. Le local est donc un filtre de premier passage, pas un remplaçant du raisonnement ni une preuve de sécurité.
Autre nuance : la disponibilité de modèles intégrés au navigateur ne signifie pas que chaque machine peut les utiliser. La documentation Chrome indique que les API d’IA intégrées sont à des niveaux de maturité différents — stable, essai d’origine ou programme d’accès anticipé — et que les modèles sont téléchargés à la demande. Les contraintes matérielles, la version du navigateur et la politique de l’entreprise font partie du déploiement. Un schéma de recherche ne devient pas une fonctionnalité prête à cocher dans un menu parce qu’il cite Gemini Nano.
Le vrai verrou reste l’autorité
Le garde d’exécution est la pièce la plus facile à expliquer et probablement la plus importante à conserver. Un modèle peut classer correctement une page et se tromper ensuite dans son plan. Il peut aussi être manipulé par une instruction qui ressemble à une note interne. Dans les deux cas, une liste blanche d’origines et une politique sur les verbes limitent la casse avant l’appel réseau.
Cela ne suffit pas à tout régler. Une action parfaitement autorisée peut être dangereuse si elle n’était pas voulue : envoyer un message au bon domaine reste une mauvaise idée si le modèle a mal compris la demande. Il faut donc ajouter des confirmations humaines pour les opérations irréversibles, des permissions minimales, des journaux lisibles et une séparation nette entre données récupérées et consignes de contrôle. Le pare-feu cognitif renforce ces principes ; il ne les remplace pas.
L’outil open source IPI-proxy, présenté dans un autre travail récent, attaque le même problème par la voie du test. Son proxy modifie en transit les réponses HTML de domaines pourtant autorisés, puis injecte des charges issues de six jeux de données. L’intérêt est concret : tester l’agent sur la surface de récupération qu’il utilisera vraiment, plutôt que sur une page factice que sa liste blanche refuserait. Pour une équipe qui déploie des agents, ce genre de test devrait devenir un contrôle de régression, pas une démonstration de salon.
Ce que les équipes peuvent reprendre dès maintenant
Tu n’as pas besoin d’attendre un navigateur équipé d’un modèle local pour appliquer la logique. Commence par considérer toute page, tout fichier et tout résultat d’outil comme une donnée non fiable. Étiquette cette donnée dans les entrées du modèle, interdits-lui de modifier la hiérarchie des instructions et garde les appels sensibles derrière une politique indépendante. Si l’agent peut supprimer, envoyer, publier ou modifier, la confirmation doit porter sur l’action finale, pas seulement sur la demande initiale.
Ensuite, teste les trois familles d’attaque séparément : contenu invisible ou incohérent avec le rendu, manipulation du raisonnement et détournement d’objectif avec effet de bord. Mesure les faux positifs, le temps de réponse, les appels au nuage et les actions effectivement bloquées. Enfin, vérifie le comportement quand une dépendance manque, quand le modèle local est indisponible ou quand le service distant répond mal. Un mécanisme de sécurité qui disparaît silencieusement au premier problème réseau est juste une décoration avec un nom sérieux.
Un pare-feu autour du modèle, pas dans sa tête
Le Cognitive Firewall propose une direction raisonnable : filtrer tôt ce qui est visuellement suspect, analyser en profondeur ce qui est ambigu et imposer une barrière déterministe avant l’action. La recherche reste une évaluation publiée, pas une garantie de production, et ses métriques doivent être reproduites sur les agents et les pages réellement utilisés. Mais le principe tient debout : la confiance ne doit jamais être accordée au modèle seul.
Sources
— Qianlong Lan et Anuj Kaul, « The Cognitive Firewall: Securing Browser-Based AI Agents against Indirect Prompt Injection via Hybrid Edge-Cloud Defense », arXiv, 2026 : https://arxiv.org/html/2603.23791v1
— OWASP GenAI Security Project, « LLM01:2025 Prompt Injection » : https://genai.owasp.org/llmrisk/llm01-prompt-injection/
— Chrome for Developers, « Built-in AI APIs » : https://developer.chrome.com/docs/ai/built-in-apis
— Kentaroh Chia-Pei, Anita Chen et Alex Toyoda, « IPI-proxy », arXiv, 2026 : https://arxiv.org/html/2605.11868
— Dépôt open source IPI-proxy : https://github.com/VulcanLab/IPI-Proxy/
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet