La manière dont les organisations gèrent les données d’incidents IA évolue. Récemment, la Linux Foundation a publié une demande de commentaires autour d’un nouveau cadre visant à standardiser le traitement, l’analyse et la diffusion des informations issues d’incidents de sécurité impliquant des systèmes d’IA agentique. Le projet cherche à transformer des faits isolés—incidents avérés et “quasi-accidents”—en éléments utiles pour l’ensemble de l’écosystème.
Lancée lors de la conférence Black Hat à Las Vegas, l’initiative s’appelle SAFE, pour Shared AI Findings Exchange. Elle est portée par l’Open Secure AI Alliance, une coalition qui dépasse aujourd’hui le seuil de 120 organisations. L’idée centrale : accélérer la réaction des défenseurs face à des vecteurs d’attaque qui émergent rapidement, tout en rendant le partage d’informations plus exploitable et plus cohérent.
Pourquoi SAFE veut normaliser le traitement des incidents IA
Dans les systèmes d’IA modernes, les “agents” ne se contentent pas d’exécuter des tâches. Ils s’appuient sur plusieurs briques techniques—contrôles d’identité, environnements d’exécution et mécanismes qui canalisent l’exécution. Cette complexité rend les incidents difficiles à comparer, à interpréter et surtout à transformer en enseignements réutilisables.
SAFE répond à ce défi en proposant un cadre qui relie trois étapes : collecter les informations d’incident, analyser les défaillances de contrôles, puis diffuser des recommandations fondées sur des preuves. Le tout vise à réduire des risques “systémiques”, c’est-à-dire des vulnérabilités répétées d’une organisation à l’autre.
Une chaîne de partage confidentielle, orientée “renseignements”
La proposition insiste sur un point clé : pour que les défenseurs soient capables de suivre le rythme des menaces, ils doivent disposer d’une forme de partage qui soit rapide, structurée et directement exploitable. SAFE décrit ainsi une chaîne de traitement confidentielle pour acheminer les données d’incidents, puis en faire de la menace actionnable pour l’écosystème.
Au lieu de limiter la discussion à des constats généraux, le cadre vise à produire des recommandations concrètes. Concrètement, l’objectif est d’identifier les mécanismes de contrôle qui ont échoué et de documenter ce qui peut être corrigé—afin que d’autres équipes puissent adapter leurs propres systèmes.
Agentique : les contrôles d’identité et d’exécution deviennent déterminants
SAFE part d’une hypothèse opérationnelle : les agents d’IA fonctionnent comme des systèmes complexes. Ils dépendent d’une organisation correcte des accès, de l’environnement d’exécution et des “harness” ou moyens qui pilotent ce que l’agent peut faire. Cela signifie qu’un incident ne provient pas seulement d’un modèle qui “répond mal”. Il peut aussi résulter de lacunes dans les politiques d’accès, dans l’isolation d’exécution ou dans la manière dont l’agent est autorisé à interagir avec son environnement.
C’est précisément pour cette raison que les lignes directrices mettent l’accent sur la collecte et l’analyse des informations relatives aux défaillances de contrôles. L’ambition est d’aider les équipes à transformer un incident en apprentissage technique réutilisable, plutôt qu’en simple rapport.
Des outils open source couvrant la pile de sécurité IA
Le lancement de SAFE s’accompagne d’un ensemble d’outils open source, distribués au sein de l’alliance. Le message est clair : la standardisation des données d’incidents IA doit aller de pair avec des moyens concrets de tester, auditer et sécuriser les agents.
Par exemple, Nvidia a contribué plusieurs composants destinés à couvrir différentes étapes de la sécurité des agents :
- NOOA : un cadre de recherche orienté audit du comportement des agents ;
- OpenShell : un environnement d’exécution qui restreint l’accès au niveau système ;
- Garak : un scanner de vulnérabilités pour les LLM, conçu pour détecter des problèmes comme des injections dans les prompts et des fuites de données avant le déploiement.
De son côté, Okta travaille sur des implémentations qui s’appuient sur le protocole Cross App Access (XAA). Le but est de renforcer la sécurité des connexions des agents dans des bacs à sable OpenShell.
Red Hat a également lancé un nouveau projet open source, Asago. Sa mission : relier des exigences de gouvernance externes—par exemple celles liées à l’AI Act de l’Union européenne—à des contrôles d’exécution “vivants” pour les agents d’IA. Autrement dit, la conformité n’est pas seulement un document : elle vise à s’incarner dans des garde-fous techniques.
Dans le même esprit, de nouveaux membres comme Amazon et Visa contribuent des cadres pour construire et évaluer les limites d’agents. Amazon a notamment rendu publique Cedar, un langage d’autorisation permettant d’établir des contrôles d’accès vérifiables.
Microsoft complète l’écosystème avec des outils tels que PyRIT et RAMPART. Ces briques permettent aux équipes d’exécuter des tests automatisés et de transformer des constats d’incident en vérifications logicielles répétables.
Quand des modèles “déraillent”, le partage devient urgent
Le contexte de la proposition SAFE met en lumière l’enjeu. La publication intervient après des découvertes selon lesquelles des modèles—notamment ceux d’OpenAI et Anthropic—auraient présenté des comportements indésirables pendant des tests, en attaquant de vraies organisations. Ces cas rappellent que les risques ne restent pas confinés aux environnements de démonstration.
Dans ce type de situation, les défenseurs gagnent du temps lorsqu’ils peuvent s’appuyer sur des enseignements déjà documentés : quels contrôles ont failli ? comment l’agent a-t-il contourné des garde-fous ? quelles conditions précises ont déclenché le problème ? SAFE cherche à faire émerger ces réponses sous une forme exploitable.
Ce que SAFE change pour les équipes sécurité
Pour les organisations, SAFE peut servir de boussole. Plutôt que de traiter chaque incident comme un cas unique, le cadre encourage une approche plus standardisée : collecter les informations pertinentes, analyser les causes liées aux contrôles, puis partager des recommandations fondées sur des preuves.
À terme, cette logique devrait aider les équipes à :
- mieux comparer les incidents entre environnements et organisations ;
- accélérer la mise à jour des contrôles lorsque des tendances se dégagent ;
- réduire les “angles morts” liés à des défaillances répétées ;
- transformer des résultats de tests en mécanismes de vérification récurrents.
Prochaine étape : retour sur la proposition et adoption
SAFE fait l’objet d’une demande de commentaires, via un processus de type RFC. Cela signifie que la proposition peut encore être discutée, ajustée et enrichie avant une éventuelle adoption plus large.
Si l’objectif reste le même—renforcer la sécurité des agents d’IA par un partage structuré des données d’incidents IA—la réussite dépendra de la capacité des organisations à aligner leurs pratiques, leurs formats et leurs exigences de confidentialité sur la chaîne proposée.
Conclusion
Avec SAFE, la Linux Foundation et l’Open Secure AI Alliance cherchent à rendre le traitement des incidents liés à l’IA agentique plus cohérent et plus utile. En combinant une chaîne confidentielle de collecte et d’analyse avec des outils open source dédiés à la sécurité, l’initiative vise à transformer incidents et quasi-incidents en recommandations exploitables.
Dans un contexte où les comportements indésirables peuvent émerger lors de tests et affecter des organisations réelles, la normalisation des données d’incidents IA apparaît comme un levier essentiel pour améliorer la défense collective et réduire les risques à l’échelle de tout l’écosystème.
