Le red teaming doit mesurer le mécanisme, pas la démo

Un rapport de l'OWASP GenAI Security Project publié en 2026 affirme que la plupart des exercices de red teaming d'IA mesurent la mauvaise chose — un prompt de jailbreak qui réussit — et l'appellent sécurité. La surface de risque réelle est le mécanisme : usage abusif d'outils, escalade de privilèges dans les systèmes multi-agents, fuite de données dans le RAG. Le cadre d'évaluation du rapport est, dans notre langage, Theorem 3 appliqué à la sécurité : une propriété est garantie exactement quand son mécanisme est implémenté et mesurant.

La démo de jailbreak est la surface, pas la garantie

Le rapport de l'OWASP s'ouvre sur un diagnostic que nous reconnaissons immédiatement : les organisations se croient « sécurisées » parce qu'elles ont lancé des tests basés sur des prompts, tout en ignorant les risques systémiques qu'introduisent les architectures agentives, les intégrations d'outils et l'automatisation des flux. Le rapport appelle cela du « security theater » — une démo qui mesure la surface du chat et certifie silencieusement rien sur le système en dessous.

[UNIQUE INSIGHT] C'est la même erreur que Theorem 3 nomme en forme générale : une propriété est garantie exactement quand son mécanisme est implémenté et mesurant. Un jailbreak qui réussit contre un chatbot mesure le mécanisme de refus du chatbot. Il ne mesure pas le chemin d'appel d'outils, le chemin de retrieval augmenté, le chemin de transfert multi-agents, ni le chemin d'intégration du Model Context Protocol. Chacun est un mécanisme séparé avec un mode de défaillance séparé. En certifier un en certifie un.

La contribution du rapport est qu'il cesse de laisser les fournisseurs les confondre. Il sépare les systèmes GenAI simples — chatbots, copilotes, apps RAG — des systèmes avancés : agents appelant des outils, architectures MCP, flux multi-agents. Chacun a un profil de risque distinct. Les hallucinations dominent le premier ; l'usage abusif d'outils et l'escalade de privilèges dominent le second. Un red team qui ne teste que le premier n'est pas un red team pour le second. C'est une démo.

Pourquoi le mécanisme, pas la démo, est l'unité de sécurité

Le cadre de l'OWASP organise l'évaluation autour de dix dimensions : compétence technique, méthodologie et couverture, créativité adverse, réalisme de la modélisation des menaces, rigueur d'évaluation et métriques, tooling et infrastructure, gouvernance des données, transparence et explicabilité, personnalisation et intégration, et posture juridique et de conformité. Lues attentivement, chaque dimension est un mécanisme qui doit être implémenté et mesuré — pas un adjectif qu'un fournisseur peut affirmer.

Considérez la dimension métriques. Le rapport introduit pass@k (la probabilité qu'au moins un de k tentatives indépendantes réussisse) et Average Turns to Jailbreak. Ce ne sont pas des nombres de vanité. Ce sont des mécanismes de mesure : pass@k vous dit si une défaillance est rare ou simplement pas encore observée ; Average Turns to Jailbreak vous dit si le système se dégrade avec grâce sous pression soutenue ou s'effondre au troisième tour. Un fournisseur qui rapporte « nous avons trouvé 12 vulnérabilités » sans ces mécanismes rapporte un compte, pas une garantie.

[ORIGINAL DATA] Theorem 3, tiré de the 21 papers qui fondent le moteur de forecasting d'Everythink, énonce le principe en une ligne : une propriété est garantie exactement quand son mécanisme est implémenté et mesurant. Le rapport de l'OWASP est la communauté de la sécurité qui arrive à la même ligne par l'autre direction — après que suffisamment de démos de jailbreak aient certifié des systèmes qui ont ensuite échoué en production, la seule réponse honnête est de demander quel mécanisme la démo a mesuré, et si ce mécanisme est celui qui tient la propriété en déploiement.

La frontière de routage est là où vit la véritable surface d'attaque

Le rapport distingue les systèmes simples des avancés, mais ne nomme pas ce que nous nommerions : la surface d'attaque se déplace quand la topologie route. Un chatbot a une surface — le prompt. Un agent qui appelle des outils, récupère depuis un corpus et transfère à un second agent a une surface à chaque transfert. La permission d'appeler un outil, la portée de la récupération, la confiance transférée au transfert — chacune est une décision de routage, et chaque décision de routage est un endroit où un adversaire peut tenter de rediriger le flux.

C'est pourquoi « the space is the router » n'est pas qu'un slogan produit pour nous. La topologie d'Everythink — network → community → room — route une requête avant que quoi que ce soit réponde. Un room est une portée ; une community est une frontière de confiance ; une network est une frontière de souveraineté. La permission qui laisse un agent agir dans un room est une décision de routage, et c'est la décision qu'un adversaire veut subvertir. Un red team qui teste le prompt et non la frontière de routage teste le vestibule et non le coffre-fort.

[PERSONAL EXPERIENCE] Le HAI Engine tourne en production depuis 2016, et les évaluations adversariales qui comptent pour nous ont toujours été à la frontière de routage — une requête peut-elle atteindre un room qu'elle ne devrait pas, une portée peut-elle être escaladée, un transfert peut-il fuiter une permission ? L'accent du rapport de l'OWASP sur la contamination multi-agents et l'usage abusif de MCP est le même accent, exprimé pour un public plus large. Le mécanisme est la frontière ; la démo est le prompt.

Ce que le rapport fait bien, et ce qu'il laisse à l'opérateur

Le rapport est solide sur la lentille de procurement. Il offre des green flags et des red flags qu'un acheteur peut utiliser immédiatement, une matrice de comparaison consultants contre outils, et une checklist de scoring à travers les dimensions techniques, opérationnelles et de gouvernance. Les green flags — chaînes d'attaque complètes, traçabilité des agents, rejouabilité, conception d'attaques inédites plutôt que réutilisation de bibliothèques publiques de jailbreak — sont chacun un mécanisme de mesure. Les red flags — démos de jailbreak en titre, sans pass@k, sans Average Turns, sans mapping vers NIST AI RMF ou ISO 42001 ou l'EU AI Act — sont chacun un mécanisme absent.

Il est plus faible sur trois choses que l'opérateur doit encore fournir. D'abord, il se concentre sur l'évaluation des fournisseurs, avec moins de guidance sur la construction d'une capacité interne de red teaming ou d'un modèle hybride. Ensuite, il référence des cadres réglementaires sans mapper profondément les critères aux obligations de conformité spécifiques — les évaluations de conformité sous l'EU AI Act sont laissées au lecteur. Enfin, il suppose un niveau de maturité technique relativement élevé ; une organisation au début de son parcours d'IA aura besoin de modèles que le rapport ne fournit pas.

Nous lisons ces lacunes comme le rapport étant honnête sur sa portée. C'est un cadre de procurement, pas un manuel d'exploitation. Le travail de l'opérateur — que le rapport nomme mais n'achève pas — est de prendre les mécanismes de mesure et de les exécuter en continu, pas une fois à l'achat.

La discipline à mécanisme unique que le rapport demande des métriques

La section métriques du rapport est, à notre lecture, sa contribution la plus discrète et la plus importante. Elle demande pass@k, Average Turns to Jailbreak, rejouabilité, observabilité et traçabilité des agents. Chacun est un mécanisme unique qui produit un signal mesurable. La discipline derrière eux est la même que nous tenons pour l'Oracle : les probabilités sont normalisées en exactement un endroit, le module d'ensemble, et chaque consommateur peut se fier à sum(probability) ≈ 1.0. Un mécanisme, une garantie.

Un rapport de red team qui regroupe dix métriques dans un « risk score » a le même problème qu'un forecast qui regroupe dix modèles dans un nombre sans dire où la normalisation se fait. La garantie n'est bonne que selon le mécanisme unique qui la produit. L'insistance du rapport de l'OWASP sur des métriques nommées et séparables — pass@k est pass@k, pas une composante d'un score — est l'insistance pour que le mécanisme soit identifiable, de sorte que quand la propriété échoue, vous sachiez quel mécanisme a cessé de mesurer.

C'est la conséquence opérationnelle de Theorem 3. Si la garantie est « sécurité », et le mécanisme est « pass@k sur le chemin d'appel d'outils », alors quand pass@k chute, vous savez que le chemin d'appel d'outils est l'endroit où la garantie s'est affaiblie. Un score groupé ne peut pas vous dire cela. Il peut seulement dire qu'un nombre a bougé. Le rapport, peut-être sans le vouloir, est un argument pour dégrouper.

La portée civile et défensive est la seule portée honnête

Le rapport traite de red teaming défensif — trouver des défaillances pour qu'elles puissent être corrigées. Il ne traite pas de capacité offensive. Cela correspond à une frontière que nous tenons explicitement : usage civil et défensif seulement. Le même mécanisme qui trouve un chemin d'escalade de privilèges pour que vous le fermiez pourrait, en d'autres mains, le trouver pour que quelqu'un l'exploite. Le rapport ne s'y attarde pas, mais le cadre de procurement suppose que l'acheteur veut que la défaillance soit trouvée et corrigée, pas trouvée et armée.

Nous l'affirmons parce que la voix du Honest Architect l'exige. Une capacité de red teaming est un mécanisme de mesure ; un mécanisme de mesure est neutre quant à l'intention de son opérateur. Le cadre de l'OWASP est plus utile pour un opérateur dont l'intention est défensive, et nous ne le vendrions pas autrement. La topologie d'Everythink — où les décisions de routage sont la surface d'attaque — est construite pour que l'opérateur défensif puisse voir et fermer les chemins. Elle n'est pas construite pour aider un opérateur offensif à les ouvrir.

Comment cela se relie à ce que nous livrons

Le pipeline Sisters → Oracle est un forecast calibré, pas une conjecture. Chaque Sister rédige un futur plausible ; l'Oracle les fusionne en un ensemble normalisé. La discipline est : un mécanisme de normalisation, une garantie mesurable. Le rapport de l'OWASP demande la même chose du red teaming : un mécanisme pass@k, un signal de sécurité mesurable. La forme est la même parce que le principe sous-jacent est le même — Theorem 3, que ni la communauté de la sécurité ni celle du forecasting ne possèdent, mais que toutes deux ne cessent de redécouvrir.

Capacités Production ✅ qui portent cette discipline : le HAI Engine (le moteur de routage et de matching qui tourne depuis 2016), les Sisters et l'Oracle (l'ensemble calibré), World Monitor (la passerelle de geo-signaux en direct dont les ids déterministes signifient que la réingestion met à jour, ne duplique jamais — un mécanisme de mesure pour l'intégrité des données), Social et Campaigns (où les portées de permission routent avant que le contenu ne soit servi), et la Whitelabel Network (où la souveraineté sur la network, la marque et les données est la frontière de routage que l'opérateur contrôle).

Capacités Partial ⚠️ : Matchmaking, Marketplace et Calendar — les mécanismes de mesure existent mais la couverture est incomplète, et nous ne les appellerons pas Production jusqu'à ce qu'elle le soit. Roadmap 🔵 : Wallet & Token, Super App et Community Credit — pré-revenu, soumis à l'examen Howey, et non promis comme résultats. Nous ne surclassons pas les états. Les red flags du rapport de l'OWASP sont, en effet, le mode de défaillance de la surclassement d'un état : un fournisseur qui appelle « sécurité » une démo de jailbreak surclasse un test de surface en garantie de système.

Points-clés

• Une démo de jailbreak mesure le mécanisme de refus d'un chatbot. Elle ne mesure pas les mécanismes d'appel d'outils, de retrieval ou multi-agents. En certifier un en certifie un. C'est Theorem 3 en costume de sécurité.
• Le rapport de l'OWASP GenAI Security Project (2026) sépare les systèmes d'IA simples des avancés et donne dix dimensions d'évaluation — chacune un mécanisme qui doit être implémenté et mesuré, pas affirmé.
• Les métriques qui comptent — pass@k, Average Turns to Jailbreak, rejouabilité, traçabilité des agents — sont des mécanismes uniques et séparables. Un « risk score » groupé masque quel mécanisme a cessé de mesurer quand la garantie échoue.
• La véritable surface d'attaque est la frontière de routage, pas le prompt. La topologie network → community → room d'Everythink route avant que quoi que ce soit réponde ; la permission à chaque transfert est l'endroit où un adversaire tente de rediriger le flux.
• La portée civile et défensive est la seule portée honnête pour un mécanisme de mesure. Le même mécanisme qui trouve un chemin pour le fermer pourrait le trouver pour l'exploiter.

Questions fréquentes

Qu'est-ce que le red teaming d'IA et en quoi diffère-t-il du red teaming traditionnel ? Le red teaming d'IA est un test adversarial visant à découvrir les défaillances de sécurité, d'usage abusif et d'alignement dans les systèmes d'IA — hallucinations, jailbreaks, usage abusif d'outils, escalade de privilèges, fuite de données. Le red teaming traditionnel de cybersécurité teste les réseaux et applications pour l'accès non autorisé. Le rapport de l'OWASP est explicite : les deux ne sont pas la même chose ; un red team d'IA teste le comportement du modèle et le système autour, pas seulement le périmètre.

Pourquoi une démo de jailbreak ne suffit-elle pas à certifier la sécurité ? Une démo de jailbreak mesure si un prompt spécifique contourne le mécanisme de refus d'un chatbot. Elle ne mesure pas le chemin d'appel d'outils, le chemin de retrieval ni le chemin de transfert multi-agents — chacun un mécanisme séparé avec un mode de défaillance séparé. Theorem 3 le dit directement : une propriété est garantie exactement quand son mécanisme est implémenté et mesurant. Une démo qui mesure le mauvais mécanisme ne garantit rien sur le bon.

Quelles métriques un fournisseur de red teaming devrait-il rapporter ? Le rapport de l'OWASP nomme pass@k (la probabilité qu'au moins un de k tentatives réussisse) et Average Turns to Jailbreak, plus la rejouabilité, l'observabilité et la traçabilité des agents. Chacun est un mécanisme de mesure unique et séparable. Un fournisseur qui rapporte seulement un compte de vulnérabilités trouvées, sans ces mécanismes, rapporte un nombre, pas une garantie.

Comment la topologie d'Everythink se relie-t-elle au red teaming d'IA ? La topologie network → community → room route une requête avant que quoi que ce soit réponde. La permission à chaque transfert — portée de room, frontière de confiance de community, souveraineté de network — est une décision de routage, et les décisions de routage sont la véritable surface d'attaque dans les systèmes agentifs. Un red team qui teste le prompt et non la frontière de routage teste le vestibule, pas le coffre-fort. « The space is the router » est l'affirmation que la couche de routage est l'endroit où la sécurité se gagne ou se perd.

Un cadre de red teaming peut-il être utilisé offensivement ? Un mécanisme de mesure est neutre quant à l'intention. Le cadre de l'OWASP est conçu pour l'opérateur défensif qui veut que les défaillances soient trouvées et corrigées. Everythink tient une frontière de portée civile et défensive explicitement : la topologie est construite pour que l'opérateur défensif puisse voir et fermer les chemins, pas pour qu'un opérateur offensif les ouvre.

Sources

• 2026 — OWASP GenAI Security Project, « Vendor Evaluation Criteria for AI Red Teaming Providers & Tooling », Version 1.0, public release January 13, 2026 ; summarized by aigl.blog on March 20, 2026 : https://www.aigl.blog/vendor-evaluation-criteria-for-ai-red-teaming-providers-tooling/

Créez votre network — et décidez où se situe la frontière de routage avant que quoi que ce soit réponde.