DGF-Bench est désormais cité dans AI SAFE²
AI SAFE² est le framework open source du Cyber Strategy Institute consacré à la gouvernance des systèmes d'IA agentiques. Son dépôt contient une analyse des contributions technologiques qui cite désormais DGF-Bench, le benchmark que j'ai publié sur arXiv fin septembre. L'analyse le retient comme candidat pour tester sept contrôles du framework, c'est-à-dire pour confirmer qu'ils tiennent ou pour montrer qu'ils peuvent être contournés. Ces contrôles relèvent de quatre des cinq piliers du framework [2].
Cette analyse est datée du 2 octobre 2026. Elle passe en revue neuf travaux de natures très différentes : des articles de recherche, un logiciel et un composant matériel de NVIDIA, une enquête, un rapport lié à un incident et une assignation délivrée dans le cadre d'une enquête judiciaire. Pour chacun, elle indique les contrôles qu'il pourrait renforcer et ce qu'il faudrait vérifier avant de s'y fier. Le README du dépôt y renvoie [1], tout comme le « Technology Contribution Profile », le document qui définit comment évaluer l'apport d'une technologie dans le modèle de maturité AISM [3].
AI SAFE² en bref
Le dépôt présente AI SAFE² comme un socle d'exigences d'ingénierie et de gouvernance pour l'IA agentique : il précise ce qui doit être gouverné, ce qui doit être imposé techniquement, et quelles preuves doivent exister lorsque des systèmes autonomes agissent. La version 3.1 compte 161 contrôles, répartis entre cinq piliers opérationnels et une couche de gouvernance transverse. D'après le dépôt, ces contrôles sont mis en correspondance avec 32 référentiels, dont ISO 42001, les référentiels du NIST, SOC 2 et le règlement européen sur l'IA (AI Act). La documentation est publiée sous licence CC BY-SA 4.0 et le code sous licence MIT [1].
| Pilier | Périmètre selon le dépôt |
|---|---|
| P1 · The Shield | Validation des entrées, protection contre les injections, gouvernance de la mémoire des agents |
| P2 · The Ledger | Visibilité complète, traçabilité de l'exécution, provenance des modèles |
| P3 · The Brakes | Limites de récursion, arrêt d'un essaim d'agents, retour en arrière en cas de dérive du comportement, confinement des défaillances en cascade |
| P4 · The Control Room | Détection des attaques, surveillance des usages abusifs des outils, supervision humaine |
| P5 · The Feedback Loop | Évaluation continue face aux attaques, suivi des capacités émergentes, dépôts de scénarios de red team |
À ces cinq piliers s'ajoute la couche de gouvernance transverse (Cross-Pillar Governance Layer), introduite en version 3.0. Les noms des piliers sont donnés en anglais, comme dans le framework.
Sept contrôles, sur quatre piliers
L'analyse range DGF-Bench parmi les benchmarks, c'est-à-dire les outils qui permettent de tester un contrôle, soit pour confirmer qu'il tient, soit pour montrer qu'il peut être contourné. Elle l'associe aux sept contrôles ci-dessous, dont les intitulés et les exigences sont repris de la liste officielle des contrôles du framework [4].
| Contrôle | Intitulé | Ce que le contrôle exige |
|---|---|---|
| P1.T1.2 | Malicious Prompt Filtering | Détecter et bloquer les injections de prompt, mettre en place une détection des entrées malveillantes, surveiller les tentatives de jailbreak. |
| P2.T3.3 | Behavior Verification | Définir un comportement de référence, détecter les écarts et les anomalies, signaler les comportements inhabituels. |
| P2.T3.7 | Decision Traceability | Assurer la traçabilité de l'entrée jusqu'à la sortie, documenter les sources de données, préserver la chaîne de conservation des preuves. |
| P2.T1.2_ADV | Agent Behavior Verification | Vérifier les mécanismes de vote entre agents, suivre l'état de leur mémoire d'une interaction à l'autre, avec des empreintes SHA-256. |
| P4.T7.1 | Human Approval Workflows | Soumettre à une validation humaine les décisions à haut risque, désigner les personnes habilitées à approuver. |
| P4.T1.1_ADV | Multi-Agent Approval | Faire examiner par un humain les cas où les agents ne sont pas d'accord, et exiger une validation humaine avant toute action financière ou touchant aux systèmes. |
| P5.T9.2 | Playbook Updates | Mettre à jour les plans de réponse à partir des retours d'expérience. |
L'analyse précise que ces correspondances indiquent ce qu'il faudrait évaluer, et non une couverture déjà constatée [2].
Le fonctionnement de DGF-Bench explique ces correspondances. Le benchmark soumet des dossiers de projet fictifs à un comité d'agents : des agents spécialisés, chacun chargé d'un point de validation, et un agent général qui consolide leurs décisions. Pendant ce temps, un attaquant glisse du contenu trompeur dans les pièces dont l'organisation ne garantit pas le contenu, par exemple celles fournies par des fournisseurs ou par des membres du projet [5]. Les attaques ne modifient jamais les registres qui font foi : la décision attendue reste donc la même sur le dossier attaqué et sur sa copie intacte. Une attaque n'est comptée comme réussie que si l'agent exécute, sur le dossier attaqué, l'action précise que l'attaquant a injectée, alors qu'il ne l'exécute pas sur la copie intacte.
C'est cette comparaison entre dossier intact et dossier attaqué que l'analyse propose de reproduire. Une tromperie réussie met en jeu à la fois le filtrage des contenus malveillants, la traçabilité des décisions et les circuits d'approbation, ce qui explique que les contrôles concernés se répartissent sur plusieurs piliers.
Les huit autres travaux cités
L'analyse cite DGF-Bench avec huit autres travaux. Elle les classe par nature, car un benchmark, un logiciel et une procédure judiciaire n'apportent pas le même type de preuve.
| Travail | Nature | Ce qu'en retient l'analyse |
|---|---|---|
| Rogue Agents Investigation Asymmetric Security | Enquête | Des agents qui combinent les fonctionnalités de services accessibles en ligne. L'analyse s'en sert pour imaginer des tests sur ce que permet la combinaison de plusieurs capacités. |
| ContractWarden arXiv:2609.38248 | Moniteur de référence (recherche) | Un moniteur de référence pour Linux, qui s'appuie sur eBPF LSM pour faire respecter un périmètre de dommages acceptables, défini sous l'autorité d'un humain. |
| DGF-Bench arXiv:2609.34913 | Benchmark | Évalue la résistance à la tromperie d'un comité d'agents chargé de décisions de gouvernance, en comparant chaque décision sur un dossier intact et sur sa version attaquée. |
| Rapport sur des notifications OpenAI | Rapport lié à un incident | Les chiffres avancés n'ont pas été vérifiés : l'analyse refuse de les reprendre comme des faits. |
| OpenShell et Sentry NVIDIA | Logiciel et composant matériel | Application des règles de sécurité au niveau du noyau. Sentry est présenté comme un composant hors bande, c'est-à-dire séparé du flux principal, sur BlueField-4. |
| ActionGuard arXiv:2609.39450 | Intercepteur d'autorisation (recherche) | Contrôle de chaque appel d'outil avant son exécution, lorsque les compétences (skills) de l'agent ont été piégées. |
| Self-Evolving Defense arXiv:2609.36603 | Méthode d'apprentissage de règles de défense | Des règles de défense réutilisables, apprises à partir de séquences d'actions malveillantes, sans modifier les poids du modèle. |
| Supervision aléatoire arXiv:2609.38262 | Analyse théorique | Article « When Does Randomized Oversight Align AI Agents That Can Conceal? », qui étudie la supervision par contrôles aléatoires d'agents capables de dissimuler leurs actions ou de manipuler les preuves. |
| Assignation dans le cadre d'une enquête Ministère de la Justice de Californie | Procédure judiciaire | Annoncée le 1er octobre 2026 et signifiée à OpenAI la veille. L'analyse la traite comme un acte de procédure, qui n'établit aucune faute. |
Ces descriptions sont reprises de l'analyse, qui les attribue à leurs auteurs ou éditeurs sans avoir reproduit leurs résultats [2].
Une citation ne vaut pas validation
L'analyse est explicite sur ses limites, et je les reprends telles quelles. À la date du 2 octobre, elle n'avait évalué ni mise en œuvre, ni résultats bruts, ni reproduction indépendante, ni déploiement en production. Cette mise à jour de la documentation n'installe, n'exécute ni ne certifie aucun des neuf travaux, et n'en autorise aucun en production. Les notes figurant dans le document fourni au départ restent au statut « non évalué » tant qu'une fiche d'évaluation (Technology Card) n'associe pas chaque affirmation à des preuves vérifiables [2].
Pour DGF-Bench, l'analyse apporte deux précisions. D'abord, le benchmark évalue des décisions de gouvernance : ce n'est pas un outil qui fait respecter des règles pendant que les agents s'exécutent. Ensuite, des tests répétés peuvent alimenter une démarche d'apprentissage, mais ne suffisent pas, à eux seuls, pour atteindre le plus haut niveau de contribution du profil AISM. Ce niveau exige une vérification formelle des comportements critiques, des preuves conservées dans la durée et le maintien de l'autorité de l'organisation sur le système. Le profil range même parmi les affirmations interdites la phrase « DGF-Bench prouve une gouvernance de niveau 5 » [3].
Cette prudence me convient, car c'est la règle que DGF-Bench applique aux agents : mesurer l'effet d'une tromperie au lieu de le supposer. Dans mon article de recherche, cinq des six modèles testés rendaient une décision entièrement correcte sur au moins 82 des 85 points de validation. Face à ces cinq modèles, les attaques par ordre direct, par fausses données ou par fausse autorité n'ont réussi qu'une seule fois. Les attaques qui imitent les procédures internes de l'organisation ont, elles, trompé quatre de ces cinq modèles. L'outil d'approbation n'a exécuté aucune approbation falsifiée ; en revanche, des agents trompés ont soumis des approbations que les règles interdisaient [5].
Reproduire les résultats
L'analyse propose pour DGF-Bench une démarche précise : vérifier la version exacte du jeu de données et sa licence, reproduire les décisions sur dossiers intacts et sur dossiers attaqués, et documenter à la fois la capacité des agents à accomplir leur tâche et l'origine des données. Sa liste de travaux à venir prévoit aussi des expériences consacrées aux attaques qui imitent une procédure interne, avec un protocole préenregistré, un environnement isolé, des résultats comparés entre dossiers intacts et attaqués, et la recherche de contournements. Le responsable de ces expériences n'est pas encore désigné [2].
Tout le nécessaire pour reproduire ces résultats est public : l'article sur arXiv, le code sur GitHub, le paquet dgf-bench sur PyPI, qui calcule le score DGF en une seule commande, et le site dgfbench.com [6].
Sources
- Cyber Strategy Institute, « AI SAFE² Framework v3.1 », dépôt GitHub.
- Cyber Strategy Institute, « Technology contribution examples and adoption backlog », 2 octobre 2026.
- Cyber Strategy Institute, « AISM Technology Contribution Profile v1.0 ».
- Cyber Strategy Institute, liste officielle des contrôles du framework (ai-safe2-controls-v3.0.json).
- J. Canale, « DGF-Bench: A Benchmark for Simulating and Auditing Deception Against Multi-Agent Governance Boards », arXiv:2609.34913, septembre 2026.
- DGF-Bench : code sur GitHub, paquet dgf-bench sur PyPI, dgfbench.com.