L'injection de prompt n'est pas résolue — contenez-la à la vitesse machine

De quoi s’agit-il ?

Le 8 juin 2026, Infosecurity Magazine a rapporté les propos tenus à l’Infosecurity Europe 2026 par Ariel Fogel, chercheur en sécurité de l’IA au bureau du CTO de Pillar Security et contributeur au projet GenAI Security d’OWASP. Son message était sans détour : l’injection de prompt « reste un problème non résolu » au niveau architectural, et l’écart se creuse à mesure que les agents gagnent des outils et la capacité d’agir.

Il ne s’agit pas d’une nouvelle divulgation de vulnérabilité, mais d’un état des lieux émanant de l’organisme qui rédige le Top 10 OWASP pour les applications LLM et agentiques — la même semaine où OWASP dévoilait son Agentic Research Council (annoncé le 4 juin) pour rapprocher recherche et mitigations déployables. Nous le couvrons parce que l’enseignement pratique a changé : il faut cesser d’attendre un correctif et concevoir pour le confinement.

Comment ça marche

La cause profonde est structurelle, pas un bug à corriger. Un LLM traite son entrée comme une seule séquence de tokens, et il n’existe aucun mécanisme fiable, à l’intérieur du modèle, pour faire respecter une frontière de privilège entre le prompt système, la requête de l’utilisateur et le contenu qu’un agent récupère du monde extérieur. Instructions de confiance et données non fiables arrivent par le même canal : tout texte lu par le modèle peut rivaliser pour devenir une instruction. C’est le fait architectural derrière le Lethal Trifecta de Simon Willison — données privées, exposition à du contenu non fiable, et voie d’exfiltration — et derrière l’idée plus large que la sécurité des agents est un problème de systèmes, pas de modèle.

Ce qui change avec les agents, c’est la conséquence. Le point de Fogel : une injection réussie ne produit plus seulement une mauvaise réponse ; quand l’exécutant est un agent doté d’accès à des outils, elle peut déclencher une chaîne d’actions réelles — une escalade de la mauvaise sortie vers la compromission active.

Le point qui mérite qu’on s’y attarde : la façon dont les contrôles « ère humaine » échouent dans ce contexte. Fogel a décrit deux schémas observés dans des attaques réelles :

Contrôle (ère humaine)  Comment il échoue face à un agent
----------------------  ----------------------------------------------------
Allow-list de commandes Les commandes dont l'agent a besoin sont déjà
                        approuvées : l'allow-list *facilite* l'exploit
                        au lieu de le bloquer.
Frontière de sandbox    La sortie de l'agent redéfinit la frontière —
                        réécrivant de fait le confinement censé l'arrêter.
Revue manuelle          Les attaques se déroulent en minutes ; les cycles
                        de revue humaine sont trop lents pour chaque action.

Des heuristiques comme le Lethal Trifecta et la Rule of Two de Meta (un agent ne devrait satisfaire qu’au plus deux des trois propriétés du trifecta sans validation humaine) aident à réduire le rayon d’impact, mais Fogel a prévenu qu’elles ne constituent pas des défenses complètes — des travaux publiés montrent déjà des attaques réussissant avec seulement deux des propriétés présentes.

Pourquoi c’est important

La plupart des organisations, note Fogel, déploient des agents plus vite qu’elles ne savent les gouverner. Cet écart compte car le mode de défaillance n’est plus cosmétique. La vitesse et l’échelle qui rendent les agents utiles réduisent aussi le délai d’impact d’une injection, et les contrôles sur lesquels beaucoup d’équipes s’appuient — allow-lists, sandboxes, revues périodiques — ont été pensés pour des opérateurs humains et peuvent se transformer en accélérateurs. Traiter l’injection de prompt comme un simple problème de validation d’entrée conduit à surestimer la confiance accordée à des agents qui devraient être étroitement contraints.

Défenses

La posture recommandée passe d’une logique de prévention pure à la limitation de ce qu’un agent compromis peut faire, avec des contrôles fonctionnant à la vitesse de l’agent :

• Supposez que l’injection réussira. Concevez d’abord le rayon d’impact : limitez outils, données et accès réseau sortant de chaque agent au strict nécessaire pour la tâche.
• Budgétez le trifecta. Appliquez la Rule of Two — exigez un point de contrôle humain avant qu’une session combine données privées, contenu non fiable et canal d’exfiltration — tout en sachant que des attaques à deux propriétés existent.
• Surveillez à la vitesse machine. Utilisez une surveillance comportementale en direct des appels d’outils, avec confinement en temps réel et mécanismes d’arrêt forcé, plutôt qu’une analyse de logs a posteriori.
• Resserrez identité et sessions. Émettez des identifiants éphémères et étroitement délimités, et ajoutez de l’attestation cryptographique pour que chaque action d’agent soit traçable et limitée dans le temps.
• Unifiez réponse sécurité et safety. Construisez des playbooks d’incident couvrant les scénarios multi-agents à la vitesse machine, avec une supervision human-on-the-loop plutôt qu’une validation human-in-the-loop par action, incapable de suivre le rythme.

Statut

Élément	Détail
Source	Ariel Fogel (Pillar Security / OWASP), Infosecurity Europe 2026
Rapporté	8 juin 2026 (Infosecurity Magazine)
Nature	Limitation architecturale — pas de correctif ; la mitigation est le confinement
Lié	Agentic Research Council d’OWASP lancé le 4 juin 2026

C’est une analyse, pas un exploit : aucun payload à publier, aucun éditeur unique à patcher. La leçon durable : tant que modèles et runtimes ne sauront pas imposer une séparation ferme des privilèges entre instructions et données, l’injection de prompt est une propriété de l’environnement que les défenseurs doivent contenir — pas un bug qu’ils peuvent attendre de voir disparaître.