La Linux Foundation a publié une demande de commentaires sur le Shared AI Findings Exchange, ou SAFE, un cadre proposé pour collecter et partager des informations sur les incidents de cybersécurité impliquant des agents IA. L’initiative est élaborée par l’Open Secure AI Alliance, alors que les entreprises passent des tests de modèles à des systèmes capables d’accéder à des outils, des données et des applications d’entreprise.

NVIDIA, Cisco, CrowdStrike, Hugging Face et Red Hat figurent parmi les organisations contribuant à la proposition, selon un article de blog de NVIDIA. L’alliance indique compter désormais plus de 120 organisations. L’idée centrale consiste à transformer des rapports confidentiels sur des incidents et des quasi-incidents en recommandations fondées sur des preuves, susceptibles d’aider d’autres développeurs à éviter les mêmes échecs.

SAFE vise la couche opérationnelle de la sécurité de l’IA

La proposition SAFE va au-delà de la divulgation classique des vulnérabilités. Les directives décrites par NVIDIA appellent à la collecte et à l’analyse confidentielles des incidents liés à l’IA, à la notification des parties concernées, à l’identification des défaillances de contrôle récurrentes et à la publication de recommandations opérationnelles destinées à réduire le risque systémique.

Cette portée reflète un changement dans la manière dont les systèmes d’IA sont construits. Un agent n’est pas seulement un modèle ; il peut aussi inclure un cadre d’orchestration, des contrôles d’identité, des outils, des restrictions d’exécution, des garde-fous, des systèmes de journalisation et d’évaluation. Une faiblesse dans l’une de ces couches peut affecter ce qu’un agent peut voir, accéder ou modifier.

Pour les développeurs, un format d’incident partagé pourrait faciliter la comparaison des défaillances de sécurité des agents d’un produit ou d’un déploiement à l’autre. Aujourd’hui, les informations sur l’injection de prompts, l’usage abusif d’outils, les identifiants divulgués ou les actions autonomes dangereuses peuvent rester au sein d’entreprises individuelles. L’approche proposée par SAFE vise à créer un mécanisme de partage des enseignements sans exposer immédiatement des détails opérationnels sensibles.

La proposition reste à l’état de projet. L’annonce disponible ne précise ni la taxonomie complète des signalements, ni le modèle de gouvernance, ni les exigences de participation, ni le calendrier de finalisation des directives.

L’alliance associe le signalement à des outils ouverts

NVIDIA a présenté SAFE aux côtés d’un ensemble plus large de contributions de sécurité de membres de l’Open Secure AI Alliance. Ses propres exemples incluent le banc d’essai de recherche NVIDIA Labs Object-Oriented Agent, que l’entreprise dit conçu pour faciliter le test, le traçage et l’audit du comportement des agents, ainsi que NVIDIA OpenShell, un environnement d’exécution destiné à limiter ce qu’un agent peut accéder et faire.

NVIDIA a également mis en avant Garak, son scanner open source de vulnérabilités pour grands modèles de langage, qui vérifie des problèmes tels que les fuites de données, l’injection de prompts et les comportements de jailbreak. D’autres outils cités incluent NeMo Guardrails, NeMo Anonymizer et NeMo Safe Synthesizer, couvrant l’application des politiques, la protection des données sensibles et la génération de données synthétiques orientée confidentialité.

Plusieurs membres de l’alliance contribuent des outils à différents niveaux de la pile. Okta développe des implémentations de référence pour l’identité et l’accès des agents via Cross App Access. Palo Alto Networks a contribué Agent Guard et Agent Watch issus de sa plateforme de sécurité des identités Idira. Red Hat a introduit asago, un projet open source qui relie les exigences de gouvernance aux autorisations d’exécution et aux journaux d’audit, selon NVIDIA.

Amazon, décrit comme un nouveau membre de l’alliance dans l’article, contribue Strands Agents et Cedar. Strands Agents est une boîte à outils open source pour construire des agents, tandis que Cedar est un langage d’autorisation conçu pour définir et appliquer des limites d’accès. Ces projets traitent des questions de mise en œuvre que SAFE seul ne peut pas résoudre : ce qu’un agent peut faire, quelle identité il utilise et comment ces décisions sont consignées.

Les éléments probants reposent actuellement sur les déclarations des participants

L’information principale est confirmée par la source NVIDIA : la Linux Foundation a publié un RFC pour SAFE, et un groupe de travail de l’Open Secure AI Alliance y contribue. Le nombre de membres et les descriptions des outils participants proviennent également de NVIDIA, un membre de l’alliance ayant un intérêt direct à promouvoir une infrastructure ouverte de sécurité de l’IA.

La source disponible n’inclut ni tests indépendants de SAFE, ni preuve que le cadre a été adopté par des entreprises, ni démonstration que les outils listés réduisent les taux d’incidents en production. Les affirmations concernant les capacités des produits NVIDIA et les contributions des autres membres doivent donc être considérées comme des descriptions de fournisseurs ou de participants, et non comme des résultats de performance vérifiés de manière indépendante.

Il n’y a pas non plus d’indication à ce stade que SAFE soit devenu une norme formelle. Un RFC crée une occasion de révision et de modification, mais sa valeur pratique dépendra du fait que les organisations s’accordent sur ce qu’il faut signaler, sur la manière d’anonymiser les incidents et sur la rapidité avec laquelle des enseignements utiles parviennent aux développeurs et aux opérateurs.

Pourquoi cette proposition compte pour les équipes IA

Pour les équipes produit qui déploient des agents, le principal bénéfice potentiel est l’apprentissage opérationnel. Une structure de signalement commune pourrait aider les ingénieurs sécurité à distinguer un comportement isolé du modèle des échecs causés par les autorisations, les intégrations d’outils, la logique d’orchestration ou une surveillance insuffisante. Cette distinction est importante car changer le modèle ne corrige pas nécessairement une vulnérabilité située dans le système environnant.

Les acheteurs d’entreprise pourraient également examiner un processus SAFE mature lorsqu’ils évaluent des fournisseurs. Ils pourraient demander si un fournisseur d’IA participe à la divulgation d’incidents, comment il traite les quasi-incidents et si ses contrôles sont reliés à des preuves concrètes. Mais ces bénéfices ne se concrétiseront que si le cadre produit des rapports cohérents et exploitables, plutôt que des alertes générales difficiles à appliquer.

L’initiative met aussi en évidence une tension concurrentielle dans l’infrastructure IA. Les outils de sécurité open source peuvent améliorer l’inspection et la portabilité, tandis que le signalement partagé peut révéler des faiblesses récurrentes chez les fournisseurs. En même temps, les entreprises peuvent hésiter à divulguer des incidents impliquant des données clients, des systèmes propriétaires ou des risques réputationnels. Les règles de confidentialité et de gouvernance de SAFE seront centrales pour résoudre cette tension.

Ce qu’il faut surveiller ensuite

Le prochain signal viendra du contenu du processus de retour d’information de la Linux Foundation : en particulier, savoir si SAFE définit un schéma d’incident exploitable, des protections claires pour les informations sensibles et des responsabilités pour notifier les organisations concernées.

Les développeurs devraient aussi surveiller des preuves de mise en œuvre plutôt que de nouvelles annonces d’adhésion. Des indicateurs utiles seraient des rapports d’incidents anonymisés publiés, des intégrations avec des outils d’observabilité et d’évaluation des agents, et des exemples montrant comment une observation partagée a conduit à un changement d’autorisations, de contrôles d’exécution ou de politique de déploiement.

Enfin, le marché devra voir si SAFE s’articule avec les cadres existants de sécurité et de gouvernance, y compris les recommandations de NIST et d’OWASP, sans créer une autre couche de conformité déconnectée. L’adoption par des organisations extérieures à l’alliance fondatrice serait un test plus solide que le nombre actuel de participants.

Point de vue de Creati.ai

SAFE s’attaque à une faiblesse réelle de la sécurité des agents : les équipes sont censées gérer des systèmes capables d’agir à travers des modèles, des outils et des ressources d’entreprise, alors qu’une grande partie des connaissances disponibles reste fragmentée. Un processus partagé pour les incidents et les quasi-incidents pourrait rendre l’ingénierie défensive plus cumulative, au lieu d’obliger chaque entreprise à redécouvrir les mêmes modes de défaillance.

Mais la crédibilité de la proposition reposera sur son exécution. Le cadre a besoin de règles de signalement précises, d’incitations à une participation sincère et d’un niveau de détail technique suffisant pour produire des contrôles que les développeurs peuvent réellement déployer. Tant que ces éléments ne seront pas visibles, SAFE doit être compris avant tout comme un effort important de normalisation — pas encore comme une solution de sécurité démontrée.