20 000 attaques contre des garde-fous d'IA : une seule défense a tenu

La seule défense qui a tenu est celle que le modèle ne pouvait pas amadouer

Imaginez un assaillant qui ne renonce jamais après un premier échec. Il sonde le système d'IA, tire parti de chaque refus et affine sa méthode au fil de centaines de tentatives. Des chercheurs ont dirigé un tel attaquant contre neuf dispositifs censés bloquer l'injection d'invite, puis ont lancé plus de 20 000 attaques. Le verdict est sans appel : chaque défense qui demandait au modèle de se protéger lui-même a fini par tomber. Une seule approche a encaissé les 15 000 attaques qui la visaient sans rien laisser fuiter, et c'était précisément celle qui n'accordait aucune confiance au modèle.

Publié fin avril 2026 puis révisé en mai, ce travail ne raconte pas une intrusion spectaculaire. Il apporte quelque chose de plus utile, et de plus dérangeant : la démonstration nette de la catégorie de défense qui fonctionne vraiment, et de celle sur laquelle bien des entreprises s'appuient sans le savoir.

Ce que les chercheurs ont mesuré

Un détour par le vocabulaire s'impose, car tout se joue là. Un grand modèle de langage, ou LLM (la technologie derrière ChatGPT ou Claude), est piloté par un « system prompt » : un bloc d'instructions cachées que l'application transmet au modèle avant la moindre saisie de l'utilisateur. Ce bloc renferme souvent des secrets, des règles internes, parfois des clés d'API. L'injection d'invite, ou prompt injection, consiste à glisser un texte hostile qui prend le pas sur ces consignes et pousse le modèle à faire ce qu'on lui avait interdit, par exemple livrer le secret. Quand ce texte malveillant arrive par un contenu que le modèle doit lire, une page web, un document, un courriel, on parle d'injection indirecte.

Le point décisif tient en une phrase : la plupart des défenses commercialisées chargent le modèle lui-même de repérer et de refuser l'attaque. Or le gardien et la cible ne font qu'un. Un texte assez patient finit donc par convaincre le gardien de baisser sa garde. Les chercheurs ont éprouvé neuf configurations défensives avec un attaquant dit adaptatif, qui traite chaque refus comme une information et fait évoluer sa tactique, à la manière d'un crocheteur qui sent chaque goupille de la serrure plutôt que de la forcer d'un bloc. Toutes les défenses reposant sur le modèle ont cédé. L'unique exception, le filtrage de sortie, obéit à un principe différent : un morceau de code applicatif ordinaire, extérieur au modèle, inspecte la réponse produite selon des règles fixes et bloque le secret avant qu'il n'atteigne l'utilisateur. Ce contrôle vivant hors du modèle, l'attaquant n'a personne à amadouer. Bilan : 15 000 attaques, aucune fuite.

• Des défenses qui affichaient un taux de réussite des attaques proche de zéro dans leurs propres publications se sont effondrées dès qu'un attaquant adaptatif et obstiné a remplacé l'adversaire trop faible retenu lors de l'évaluation d'origine.
• Le constat rejoint une étude plus large menée en 2025 par des chercheurs d'OpenAI, d'Anthropic et de Google DeepMind, qui avaient contourné les douze défenses examinées, avec des taux de réussite compris entre 95 et 100 %.
• L'injection d'invite figure en tête de la liste OWASP des risques propres aux grands modèles de langage, et OpenAI elle-même la décrivait début 2026 comme un problème de recherche encore non résolu.

Ce que cela change pour vous

La conséquence concrète est rude : toute une catégorie de produits de sécurité pourrait n'être qu'un décor. Si vos équipes ont greffé un « garde-fou IA » ou un « pare-feu d'invite » sur un agent conversationnel ouvert aux clients, en comptant sur le modèle pour refuser les instructions malveillantes, cette recherche laisse penser que la protection cède devant quiconque s'acharne. Le test du fournisseur, flatteur, mesurait la résistance face à un attaquant faible, jamais face à un vrai. Pour votre organisation, la question utile est plus tranchante qu'il n'y paraît : que peut réellement atteindre votre agent d'IA ? S'il peut consulter une fiche client, déclencher un outil interne, déplacer de l'argent ou exposer les clés inscrites dans son propre system prompt, alors l'injection n'est plus un incident d'image, c'est une porte d'entrée vers ces systèmes. Le glissement de fond, et la raison d'inscrire le sujet à votre prochaine revue d'architecture, tient à une règle que le secteur a refusé d'admettre pendant deux ans : on ne peut pas confier à un modèle sa propre surveillance de façon fiable. La sécurité doit s'imposer dans un code déterministe placé autour du modèle, et l'ampleur des dégâts qu'une injection peut provoquer doit être bornée dès la conception.

Les bons réflexes

1. Placez la frontière de sécurité dans le code applicatif, pas dans l'invite. Intercalez un contrôle déterministe entre le modèle et l'utilisateur, ou l'outil qu'il actionne : une règle écrite en code ne se laisse pas dissuader de s'exécuter, contrairement à une consigne glissée dans l'invite.
2. Cessez d'inscrire de vrais secrets dans les system prompts. Tenez tout ce qui figure dans l'invite pour lisible par un attaquant tenace, et conservez clés d'API et identifiants dans un coffre distinct que le modèle peut utiliser sans jamais le réciter.
3. Bornez le rayon d'impact par le moindre privilège. N'accordez à l'agent que le strict minimum d'outils et de données, et exigez une validation humaine pour les actions sensibles, paiements ou exports : l'objectif n'est plus de bloquer chaque injection, mais de rendre inoffensive celle qui réussira.

À retenir

L'essentiel n'est pas que les défenses d'IA peuvent être brisées, mais lesquelles cèdent et laquelle a résisté. Tout ce qui demande au modèle de se défendre seul s'incline devant un attaquant obstiné, alors qu'un simple contrôle appliqué dans un code extérieur a tenu sur 15 000 tentatives. Si votre stratégie de sécurité repose sur la bonne conduite du modèle, vous n'avez pas encore de stratégie de sécurité. Déplacez la frontière hors de l'invite, vers un code que vous maîtrisez, et partez du principe qu'une injection finira tôt ou tard par passer.