Résumé technique : IPI-proxy

Énoncé du problème

La prolifération des agents d'IA naviguant sur le web dans les environnements d'entreprise a introduit une vulnérabilité de sécurité critique : l'injection de prompt indirecte (IPI). Contrairement à l'injection de prompt directe, où un adversaire interagit directement avec le modèle, l'IPI se produit lorsqu'un agent récupère du contenu tiers (par exemple, des pages web, des documents) contenant des instructions cachées que le modèle exécute comme des commandes utilisateur légitimes.

Les méthodologies et les référentiels de test actuels (red-teaming) ne parviennent pas à traiter adéquatement l'IPI dans des contextes d'entreprise réalistes en raison de trois lacunes principales :

1. Incompatibilité des listes blanches : Les référentiels existants (par exemple, BIPIA, InjecAgent) s'appuient sur des pages adverses hébergées sur des domaines contrôlés par l'attaquant. Les agents restreints à des listes blanches d'entreprise strictes (par exemple, *.clientcorp.com) ne peuvent pas accéder à ces pages sans violer la politique, rendant les tests invalides pour des scénarios proches de la production.
2. Contenu statique : Les référentiels servent généralement des pages adverses figées et préconstruites. Cela échoue à simuler la nature « en direct » des attaques réelles où les adversaires injectent du contenu dans des domaines de confiance via des commentaires, des wikis ou des widgets tiers.
3. Portée limitée au modèle : Les outils généraux de red-teaming (par exemple, PyRIT, garak) et les systèmes de détection (par exemple, Rebuff) sondent l'API du LLM directement. Ils ne testent pas la surface de récupération — le chemin par lequel du contenu non fiable atteint un agent utilisant des outils — où l'IPI se manifeste le plus fréquemment.

Méthodologie

Les auteurs proposent IPI-proxy, une boîte à outils open source conçue pour combler le fossé entre les référentiels statiques et le déploiement en direct. L'innovation centrale est une inversion architecturale : plutôt que de forcer l'agent à visiter des URL contrôlées par l'attaquant, IPI-proxy intercepte et modifie les réponses HTTP provenant de domaines que l'agent est déjà autorisé à visiter.

Architecture du système

IPI-proxy fonctionne comme un proxy de type Man-in-the-Middle (MITM) au niveau du réseau, construit sur mitmproxy. Il se compose de cinq composants clés :

1. Add-on Proxy : Enregistre un gestionnaire de réponse qui inspecte les réponses HTTP sortantes. Il valide l'URL de destination par rapport à un motif cible, s'assure que le contenu est du HTML et vérifie le budget d'injection avant de procéder.
2. Bibliothèque de charges utiles unifiée : Un fichier JSONL dédupliqué contenant 820 chaînes d'attaque extraites de six référentiels existants (BIPIA, InjecAgent, AgentDojo, Tensor Trust, WASP et LLMail-Inject). Ceux-ci sont normalisés sous un schéma unifié.
3. Modèles d'intégration : Pour échapper à l'inspection humaine tout en restant visibles pour les LLM, les charges utiles sont enveloppées en utilisant trois techniques :
   • Commentaires HTML : Placés à l'intérieur de blocs <!-- -->.
   • CSS invisible : Enveloppés dans des éléments <div> stylisés avec display: none et un positionnement hors écran.
   • Prose sémantique : Intégrées dans un texte éditorial plausible, éventuellement générées par un LLM (par exemple, Claude) pour une meilleure évasion.
4. Injecteur HTML : Insère la charge utile enveloppée dans l'une des six emplacements spécifiques au sein du document HTML (par exemple, head_meta, body_top, sidebar, script_comment). Si une ancre spécifique est manquante, le système recourt à une ancre plus large pour garantir le succès de l'injection.
5. Suivi d'exfiltration : Un service FastAPI léger qui enregistre les callbacks. Si un agent suit une instruction injectée pour envoyer des données à ce suivi, le test est marqué comme une exfiltration réussie.

Flux de travail

1. L'agent demande une URL à un domaine de la liste blanche.
2. Le proxy transmet la demande au serveur amont.
3. Après réception de la réponse HTML originale, le proxy sélectionne une charge utile basée sur des filtres configurés via YAML (type d'attaque, référentiel source, sévérité).
4. La charge utile est enveloppée et injectée dans le HTML à un point d'insertion configuré.
5. Le HTML modifié est renvoyé à l'agent.
6. Si l'agent exécute l'instruction injectée et contacte le suivi d'exfiltration, l'événement est enregistré.

Contributions clés

• Red-teaming respectant les listes blanches : IPI-proxy est le premier outil permettant de tester l'IPI contre des agents restreints à des listes blanches spécifiques en modifiant les réponses en direct de ces domaines de confiance plutôt qu'en servant des pages factices.
• Source de charges utiles unifiée : Il agrège et déduplique 820 vecteurs d'attaque provenant de six référentiels de recherche disparates, permettant une évaluation inter-référentiels et une rotation au sein d'une seule session de test.
• Évaluation par balayage de paramètres : En découplant la charge utile, la technique d'intégration et le point d'insertion HTML, l'outil permet une évaluation systématique de la susceptibilité d'un agent sur une surface d'attaque multidimensionnelle.
• Conception agnostique de l'agent : Contrairement aux outils basés sur des extensions de navigateur, IPI-proxy opère au niveau du réseau, ce qui le rend compatible avec les récupérateurs sans tête (headless), les clients HTTP personnalisés et les outils du protocole de contexte de modèle (MCP).

Résultats et évaluation

L'article présente IPI-proxy comme un substrat de test plutôt que comme un mécanisme de défense. Il ne rapporte pas de taux de réussite spécifiques contre un modèle particulier (par exemple, « le modèle X a échoué 80 % du temps ») mais démontre plutôt la faisabilité et la reproductibilité de la méthodologie de test.

• L'outil intercepte et réécrit avec succès les réponses HTTP provenant de domaines de la liste blanche sans modifier le serveur amont.
• Il prend en charge un régime d'évaluation par « balayage de paramètres » qui couvre des combinaisons de charges utiles, d'intégrations et de points d'insertion non simultanément supportés par les référentiels existants.
• Le suivi d'exfiltration fournit un signal de vérité terrain pour les attaques réussies sans nécessiter d'instrumentation de l'agent lui-même, préservant l'intégrité de l'environnement de test.

Importance

Les auteurs positionnent IPI-proxy comme une évolution nécessaire dans les tests de sécurité de l'IA. En passant des référentiels statiques de pages factices à l'interception dynamique de réponses en direct, l'outil permet aux équipes de sécurité de :

1. Mesurer la vulnérabilité des agents naviguant sur le web dans les mêmes restrictions de sortie et sources de contenu qu'ils rencontrent en production.
2. Renforcer les agents en fournissant un environnement reproductible pour tester des stratégies défensives (telles que la transformation des entrées ou l'isolation architecturale) contre des vecteurs IPI réalistes.
3. Combler le fossé entre les référentiels académiques et le déploiement d'entreprise, garantissant que les efforts de red-teaming reflètent la surface de menace réelle où l'IPI se produit.

L'article conclut que, bien qu'IPI-proxy ne résolve pas le problème de l'IPI lui-même, il fournit l'infrastructure critique nécessaire pour évaluer et atténuer avec précision le risque avant le déploiement des agents dans des environnements d'entreprise sensibles.