Injection de prompt HTTP : protéger les agents IA

Une injection indirecte, pas une instruction de l'utilisateur

Une injection indirecte de prompt arrive quand un agent "tombe" sur des instructions malveillantes via un contenu qu'il consulte pour faire autre chose : une page web, un courriel, un document, ou encore le résultat d'un outil. L'utilisateur, lui, demande un résumé ou une analyse, sans forcément savoir qu'un texte injecté se cache quelque part dans la matière récupérée.

Le nœud du problème, c'est la façon dont un modèle de langage traite le contexte. La demande de l'utilisateur et le contenu récupéré se retrouvent dans le même flux d'information. Le modèle peut parfois distinguer l'origine de certains éléments (selon l'architecture), mais rien n'impose au texte qu'il "signe" lui-même en tant que donnée externe plutôt qu'instruction.

Concrètement, le scénario se déroule en quatre temps : l'utilisateur demande une action, l'agent récupère du contenu contrôlé par un tiers, ce contenu entre dans le contexte du modèle, puis le modèle répond - ou déclenche un outil. La gravité dépend surtout de la dernière étape. Un agent cantonné à la rédaction peut produire une réponse biaisée. Un agent qui peut lancer des commandes, modifier des fichiers ou envoyer des courriels peut, lui, transformer du texte en action.

Le rôle des en-têtes dans une réponse HTTP

Une réponse HTTP contient une ligne de statut, des en-têtes et un corps. Le corps, c'est la page HTML, le JSON, ou le fichier demandé. Les en-têtes décrivent la réponse : type de contenu, règles de cache, cookies, ou informations de redirection. Un serveur peut aussi ajouter ses propres champs, par exemple X-AI ou X-LLM.

En pratique, un navigateur masque la plupart de ces éléments. Un outil utilisé par un agent, lui, peut les transmettre au modèle. Et là, on touche un point important : un en-tête n'est pas "une vulnérabilité" en soi ; c'est un canal possible d'injection si son contenu arrive au modèle et est traité comme une consigne.

Pour inspecter les en-têtes, une commande du type curl -sS -L -D - -o /dev/null https://exemple.fr affiche les réponses, y compris celles liées aux redirections. En revanche, évitez de coller des valeurs sensibles dans des outils tiers ou des journaux partagés : certaines réponses contiennent des cookies.

Ce que transmet réellement l'outil de récupération

Les détails varient selon l'outil et sa configuration. Un récupérateur qui renvoie seulement le corps de la page coupe souvent le problème. À l'inverse, un outil qui retourne "tout" (ou un agent capable d'exécuter curl -i) peut exposer les en-têtes au modèle.

L'analyse décrit plusieurs cas observés ou documentés :

• Outils qui ne remontent que le corps : ils transmettent le texte de la page, mais pas les en-têtes.
• Outils de synthèse web : ils peuvent transmettre un extrait reformulé, une URL de redirection, ou d'autres métadonnées.
• Outils de terminal : curl -i peut afficher l'ensemble des en-têtes.
• Outils de navigateur ou de protocole MCP : certains exposent les en-têtes sur demande, ou dans des situations particulières, comme une erreur.

Et au fond, le nom du produit ne dit pas tout : la configuration compte autant. Un outil "sage" par défaut peut devenir dangereux si l'agent reçoit l'autorisation d'utiliser un mécanisme de récupération différent. Le bon réflexe, c'est donc de tester la chaîne telle qu'elle est réellement déployée, pas seulement de lire la documentation.

Des milliers de sites envoient déjà des signaux aux IA

L'étude se base sur 217 097 223 réponses de pages (environ 10 % d'une collecte annoncée à 2,17 milliards de pages Common Crawl). Les réponses proviennent du crawl CC-MAIN-2026-39. Les chercheurs identifient 7 959 sites dont les en-têtes semblaient destinés à des systèmes d'IA.

Le cas le plus fréquent : des pointeurs vers d'autres ressources, présents sur 7 271 sites. Parmi eux, 6 989 utilisaient x-llms-txt. D'autres renvoyaient vers des fichiers d'instructions, des serveurs MCP, ou des "compétences" pour agents. Dans beaucoup de situations, c'est une manière plutôt légitime de rendre des informations structurées accessibles aux systèmes automatisés.

Mais un pointeur reste un pointeur : il dit à l'agent où aller ensuite, parfois vers une ressource ou un service contrôlé par le site. Et si l'agent peut se connecter à un serveur MCP supplémentaire ou installer une compétence trouvée en ligne, la discussion ne se limite plus au texte qu'il lit - elle porte aussi sur les outils qu'il accepte d'ajouter à son environnement.

Des en-têtes de politique, de détection et d'injection

L'étude repère aussi des en-têtes décrivant des préférences ou des informations sur la manière dont un site "voit" le client (par exemple, s'il pense avoir affaire à un robot d'IA). Au total, 139 sites indiquaient dans un en-tête qu'ils avaient classé le client comme agent ou robot IA ; 136 répondaient positivement sur ce point.

Cette détection ouvre un autre risque : le site peut servir une version du contenu différente à l'agent et à l'humain. Un système qui évalue des CV, des fournisseurs ou des sources d'information pourrait alors recevoir une version "optimisée" pour lui, invisible lors d'une vérification manuelle de la même URL. L'étude cite notamment des travaux montrant qu'un contenu de CV modifié selon l'agent pouvait influencer fortement le classement de candidats.

Enfin, 30 sites contenaient des tentatives d'injection, dont 24 dans un en-tête nommé X-AI. La plupart demandaient des actions absurdes (répondre par un nombre, un mot ou un texte précis). D'autres essayaient de déclencher une commande, de faire contacter un service externe, ou d'influencer une décision automatisée.

Les noms d'en-têtes ne suffisent pas

Les 7 959 sites ont utilisé 283 noms d'en-têtes distincts "destinés à l'IA". Pourtant, le simple fait qu'un nom contienne ai, llm ou gpt ne prouve pas qu'il s'agit d'une consigne pour un agent. Parmi les sites analysés, 1 709 répondaient à des critères basés sur les mots-clés, mais leurs en-têtes n'étaient pas liés à l'IA. Résultat : une détection fondée uniquement sur les noms aurait produit 910 faux positifs selon la méthode de l'étude.

Et à l'inverse, des signaux légitimes peuvent contenir aussi des termes associés à l'IA : préférences d'usage, métadonnées de contenu, etc. Un nom d'en-tête est un indice de triage, pas une preuve d'attaque. La vraie question reste : qu'est-ce que l'agent reçoit, et qu'en fait-il ensuite.

Dernier point : ces chiffres doivent être lus avec prudence. Common Crawl collecte les pages comme le ferait un robot d'archivage, pas comme chaque agent du marché. Des sites qui ne livrent des en-têtes qu'à certains agents peuvent ne pas apparaître dans l'échantillon. Bref, l'étude décrit le corpus analysé - pas un inventaire complet du web.

Le contenu n'est qu'une partie du problème

Une tentative dans un en-tête ne peut agir que si plusieurs conditions s'additionnent : l'outil transmet le texte au modèle, le modèle le "prend au sérieux", et l'agent dispose des droits pour exécuter l'action demandée. Une consigne du type "supprime cette base" ne fait rien si l'agent n'a ni accès à cette base, ni la capacité d'effectuer une requête dangereuse.

Et à l'inverse, une action qui paraît anodine peut quand même avoir un impact métier. Un agent de recrutement qui reçoit un score "présenté comme fiable" peut modifier une sélection sans justification visible. Un assistant chargé d'évaluer des fournisseurs peut privilégier une source décrite comme "vérifiée". Dans ces cas, le risque porte autant sur la qualité et l'équité de la décision que sur une compromission au sens classique.

Pour une entreprise française ou européenne, ces scénarios méritent une attention particulière dès qu'un agent intervient dans des processus RH, financiers, juridiques, ou liés aux données personnelles. Les exigences de contrôle, de traçabilité et de protection prévues par le RGPD ne s'évaporent pas parce qu'une décision est préparée par un modèle. Le niveau de contrôle doit être proportionné aux conséquences et aux données traitées.

Ce que montrent les tests sur des agents réels

Les auteurs ont mis en place un serveur de test : le corps de page était neutre, mais les en-têtes contenaient des marqueurs distincts et une instruction inoffensive. Dans leurs essais d'octobre 2026 avec Claude Opus, Sonnet et Haiku sous Claude Code, des demandes du type "résumer cette page" ne conduisaient pas toujours à exposer les en-têtes. En revanche, une demande portant sur la réponse du serveur pouvait inciter l'agent à lancer curl -i, et donc à rendre ces en-têtes visibles au modèle.

Dans les essais rapportés, les modèles ont repéré les instructions et ne les ont pas suivies par défaut. Le comportement change quand la demande de l'utilisateur insistait explicitement pour respecter les consignes du serveur : sept essais sur neuf ont alors affiché le code demandé. Attention toutefois : ce sont des résultats limités à une configuration précise, à des versions précises, et à un petit nombre de tests. On ne peut pas en déduire le comportement de tous les agents.

Cela dit, il y a une leçon opérationnelle assez claire : la résistance du modèle dépend aussi de l'autorité que la configuration lui donne. Un prompt système, ou une consigne utilisateur demandant de suivre les instructions d'un site, peut neutraliser une partie des garde-fous. Donc non : il ne faut pas faire reposer la sécurité uniquement sur la capacité du modèle à "reconnaître" une attaque.

Et certains risques n'ont même pas besoin que le modèle obéisse à une phrase agressive. Un agent qui suit automatiquement un pointeur vers une ressource ou un serveur tiers étend déjà sa surface d'exposition. La défense doit donc couvrir tout le parcours : depuis la récupération du contenu jusqu'à l'autorisation des actions.

Réduire les données transmises au modèle

Par défaut, transmettez le corps de la page et uniquement les métadonnées strictement nécessaires à la tâche. Un statut HTTP ou un type de média "nettoyé" peut suffire ; injecter tous les en-têtes bruts dans le contexte du modèle est rarement utile.

Bien sûr, ce n'est pas une règle universelle. Un outil de diagnostic réseau peut avoir besoin d'examiner les en-têtes. Dans ce cas, limitez l'accès à ce qui est nécessaire, gardez une séparation claire entre données externes et consignes, et filtrez les secrets (par exemple Set-Cookie). L'objectif n'est pas d'interdire toute métadonnée : c'est d'éviter l'exposition gratuite.

Traiter redirections et pointeurs comme de nouvelles requêtes

Une redirection, un lien x-llms-txt ou une adresse de serveur MCP est choisie par le serveur distant. Traitez donc chaque destination comme une source non fiable - et appliquez les mêmes contrôles que pour la requête initiale.

En pratique :

• vérifiez le domaine et la politique réseau avant de suivre une destination externe ;
• exigez une validation humaine avant d'ajouter un serveur MCP ou d'installer une compétence découverte en ligne ;
• empêchez un contenu récupéré de modifier les règles d'accès de l'agent ;
• conservez la provenance du texte, pour savoir quel site a fourni chaque donnée.

Séparer les données des instructions et contrôler les actions

Présentez clairement les contenus externes comme des données non fiables. Ça aide le modèle à les interpréter correctement, mais ce n'est pas une barrière suffisante à lui seul. Les prompts système et la configuration doivent éviter de donner aux sites visités le pouvoir de définir les objectifs ou les règles de l'agent.

Le contrôle le plus robuste se fait hors du modèle. Avant d'exécuter un appel d'outil, vérifiez que l'action correspond à la tâche demandée, que la destination est autorisée, et que les données concernées peuvent être utilisées. Une commande shell, une écriture en base, un nouvel hôte réseau ou une connexion MCP doivent passer par des règles explicites - et, selon le niveau de risque, une approbation humaine.

L'idée est simple : le modèle propose, la politique décide, puis l'outil exécute. Si un contenu malveillant atteint le contexte, il ne doit pas pouvoir "s'auto-autoriser".

Journaliser les séquences, pas seulement les mots-clés

Pour détecter un incident, il est plus utile de relier une réponse HTTP à l'action qui suit, plutôt que de surveiller un nom d'en-tête isolé. Les journaux doivent permettre de remonter à : l'outil de récupération utilisé, l'URL demandée, la destination finale après redirection, le statut, les champs transmis au modèle, et le prochain appel d'outil.

Évitez néanmoins de stocker sans filtre toutes les valeurs de réponse : les en-têtes peuvent contenir des cookies ou d'autres données sensibles. Une journalisation ciblée, avec des règles de conservation et d'accès adaptées, donne plus de visibilité sans transformer les logs en dépôt de secrets.

Une alerte utile ressemble à ceci : une réponse externe expose un champ inattendu, puis l'agent lance une commande, contacte un nouvel hôte, ou modifie une donnée sans lien clair avec la tâche.

Conclusion : contrôler l'autorisation, pas seulement le modèle

L'analyse met en lumière un canal encore peu visible : des en-têtes HTTP destinés aux agents. La plupart des cas observés sont des pointeurs ou des signaux de politique ; les tentatives d'injection repérées sont rares dans l'échantillon et souvent rudimentaires. Mais ça ne justifie ni l'alarme automatique, ni l'inaction.

Commencez par inventorier les outils de récupération utilisés par vos agents, puis vérifiez précisément quels champs sont transmis au modèle. Réduisez les permissions, encadrez les destinations externes et placez une validation indépendante avant toute action sensible. Pour les équipes produit et sécurité, c'est un bon point de départ pour évaluer le risque réel, plutôt que de compter sur des "signaux" isolés.

Pour aller plus loin, consultez les recommandations de l'OWASP sur les risques des applications LLM et mettez en place un test de bout en bout sur les outils réellement déployés dans votre organisation.