Détecter n'est pas bloquer : la seule défense qui tient contre un attaquant IA
Un red-teamer IA vient d'atteindre 84 % de succès d'attaque. Les humains, sur le même exercice, plafonnent à 13 %. Le chiffre vient d'OpenAI, qui a construit ce modèle en interne — un « super-hacker » entraîné à une seule chose : détourner des agents IA. Ils ne l'ont pas publié.
Ce chiffre n'est pas une anecdote de plus sur la course IA. C'est le signal qu'une stratégie de sécurité entière — celle sur laquelle repose la majorité des agents déployés aujourd'hui — vient de devenir obsolète. Et la bonne réaction n'est pas celle que 90 % des équipes vont avoir.
Ce que ce red-teamer a prouvé
Le modèle, appelé GPT-Red, a été entraîné par self-play : un attaquant et une série de défenseurs qui co-évoluent, l'attaquant récompensé quand il obtient un échec exploitable, les défenseurs quand ils résistent. À l'échelle des plus gros entraînements actuels. Sa cible : l'injection indirecte — pas un utilisateur qui tape une commande malveillante, mais un contenu piégé que l'agent lit sans méfiance. Un email. Une page web. Un fichier.
Sa trouvaille la plus vicieuse porte un nom : la fake chain of thought. Au lieu d'attaquer l'entrée du modèle, on injecte une fausse étape dans son raisonnement. On lui glisse une prémisse déjà « validée » — l'équivalent de « 1 + 1 = 3, et tu l'as vérifié toi-même ». Le modèle ne la remet pas en question. Il enchaîne. Et il agit sur une réalité fabriquée.
Le test grandeur nature n'était pas un laboratoire. C'était un agent qui gérait une vraie machine à snacks, en production. GPT-Red lui a fait changer les prix, brader un article à 0,50 €, annuler une commande. Sans jamais toucher au code de l'agent — juste en lui parlant.
Pourquoi la détection est un combat perdu
La réaction réflexe, en découvrant ça, est universelle : « il nous faut une meilleure détection d'injection. » Un filtre plus fin, un modèle qui repère le contenu malveillant avant qu'il n'atteigne l'agent.
C'est le mauvais combat, et il est perdu par construction.
Une détection est probabiliste. Elle attrape 95 %, 99 %, 99,9 % des attaques — et elle en rate une sur X. Tant que l'attaquant est humain et faillible, cette marge suffit. Le problème, c'est que l'attaquant vient de devenir surhumain et infatigable. Il ne se décourage pas, ne dort pas, essaie mille variantes par minute. L'asymétrie est fatale : le défenseur doit gagner à chaque fois, l'attaquant une seule fois. Contre un GPT-Red, une couche de détection, aussi bonne soit-elle, finit toujours par céder. Ce n'est pas une question de qualité. C'est une question d'arithmétique.
Il y a même un résultat plus troublant : on peut détecter parfaitement un comportement dangereux et être incapable de le bloquer. Savoir où se trouve l'attaque n'est pas la même chose que pouvoir l'arrêter. La détection et le contrôle sont deux directions différentes — et la première ne donne pas la seconde.
La garde déterministe : retirer la clé, pas surveiller la porte
La seule chose qui tient est d'une autre nature. Elle est déterministe.
Le principe : l'action critique — payer, virer de l'argent, supprimer des données, envoyer un message vers l'extérieur, déployer — ne doit pas être déclenchable par le modèle seul. Peu importe ce qu'on lui fait croire, peu importe la fausse étape qu'on injecte dans son raisonnement : le modèle n'a pas la main sur l'action finale. Celle-ci passe par une garde qu'il ne peut pas contourner en parlant, parce que la garde n'écoute pas ses arguments — elle vérifie une condition qu'il ne contrôle pas.
L'image est celle d'une clé. Une détection, c'est un vigile qui observe la porte et décide, à chaque visiteur, s'il a l'air honnête. Un attaquant surhumain finira par avoir l'air honnête. Une garde déterministe, c'est une porte qui exige une clé physique que le visiteur n'a jamais eue — quel que soit son discours. On ne le juge pas. On constate qu'il n'a pas la clé.
Concrètement, cela veut dire séparer deux mondes : ce que le modèle propose (il peut tout proposer, c'est son rôle) et ce que le système autorise (une liste fermée d'actions, chacune conditionnée à une preuve que le modèle ne peut pas fabriquer). Le modèle raisonne, suggère, rédige. Il ne signe pas le chèque.
Ce que ça change pour qui déploie des agents
Si vous mettez un agent IA en production — support client, assistant interne, automatisation qui touche à des systèmes réels — la question à se poser n'est pas « comment je détecte les attaques ». C'est :
Qu'est-ce que mon modèle peut déclencher, tout seul ?
Faites la liste des actions irréversibles ou sensibles qu'il peut atteindre. Pour chacune, une seule question : est-elle déclenchable par le seul jugement du modèle, ou passe-t-elle par une garde qu'il ne contrôle pas ? Chaque action de la première catégorie est une porte sans serrure. Le travail n'est pas de mieux surveiller ces portes — c'est de leur poser une serrure dont le modèle n'a pas la clé.
C'est un changement de posture, pas d'outil. On arrête de courir après la détection parfaite — une course à l'armement qu'un attaquant surhumain gagnera toujours — et on rend l'action critique structurellement hors de portée du modèle seul.
C'est le principe que nous appliquons par défaut sur nos agents : la logique de décision de la garde qui protège une action critique n'est pas seulement testée, elle est prouvée formellement — vérifiée par la machine, pas espérée. Cela ne rend rien « inviolable » (aucune formule ne l'est), mais cela garantit une propriété précise : aucune entrée, aussi manipulée soit-elle, ne peut déclencher l'action sans la condition d'autorisation qui vit hors du modèle.
La sécurité des agents ne se jouera pas sur la finesse de nos détecteurs. Elle se joue sur une décision d'architecture, prise avant la première ligne : quelles actions le modèle a-t-il le droit de déclencher seul — et lesquelles exigent une clé qu'il n'aura jamais.
Sur la façon dont on construit des systèmes qui tiennent, voir aussi Le coût caché du no-code : la dette invisible. Pour un audit de sécurité ciblé de vos agents ou de votre stack, consulting.omnirealm.tech.