Un projet ouvert, pas encore une norme adoptée
La Linux Foundation a publié le 4 août 2026 une demande de commentaires pour créer le Shared AI Findings Exchange, ou SAFE. L’initiative est portée par des participants de l’Open Secure AI Alliance, avec un premier texte préparé notamment par Cisco, CrowdStrike, Hugging Face, NVIDIA et Red Hat. L’objectif est de permettre aux organisations d’apprendre collectivement des incidents et quasi-incidents de sécurité impliquant des systèmes d’intelligence artificielle, sans exposer immédiatement les données sensibles de chaque victime.
SAFE part d’un problème opérationnel : les entreprises enquêtent aujourd’hui sur leurs incidents en interne, puis partagent rarement les traces, les erreurs de configuration et les contrôles qui ont échoué. Le RFC propose un canal confidentiel pour agréger ces informations, avertir les parties touchées et convertir les causes récurrentes en recommandations applicables. Le périmètre englobe les modèles, les instructions, les garde-fous, les outils, les environnements d’exécution, la surveillance, les opérations humaines et la chaîne d’approvisionnement.
Il faut toutefois lire le document au conditionnel. La Linux Foundation ne publie ni une certification, ni une réglementation, ni une spécification finalisée. Le dépôt GitHub est ouvert aux issues et aux contributions ; la gouvernance, les procédures et les obligations restent donc susceptibles de changer. NVIDIA indique que l’alliance réunit plus de 120 organisations, mais cette taille ne signifie pas que tous ses membres ont déjà adopté les délais et exigences détaillés dans le projet.
Des seuils de signalement et un calendrier très précis
Le texte propose de rendre signalable tout accès, exploitation, perturbation ou modification non autorisée d’un système tiers par une IA. Seraient aussi concernés le contournement d’un bac à sable ou d’une limite réseau, l’accès sans consentement à des informations confidentielles et la poursuite d’une action après que l’opérateur soupçonne une sortie du périmètre autorisé. L’intention du modèle ne changerait pas cette qualification : croire qu’une cible réelle appartient à une simulation n’annulerait pas le devoir de signaler.
Le calendrier proposé commence par une alerte aussi rapide que possible à l’organisation directement touchée. Les clients exposés de façon crédible seraient informés sous 72 heures, puis un rapport initial confidentiel serait transmis à SAFE sous quatre jours ouvrés. Selon la gravité, un avis plus large pourrait suivre sous 14 jours, un rapport factuel préliminaire sous 30 jours et un état des corrections sous 90 jours. Des mises à jour lisibles par machine seraient fournies chaque semaine tant qu’un risque important demeure ouvert.
Ces échéances ne remplaceraient pas les contrats, les règles de divulgation coordonnée de vulnérabilités, ni les obligations envers les autorités ou les forces de l’ordre. Le RFC prévoit des exceptions étroites lorsqu’une publication créerait un risque immédiat d’exploitation ou compromettrait une enquête, tout en maintenant l’obligation d’alerter rapidement les organisations affectées. Cette articulation juridique sera l’un des points les plus difficiles à harmoniser entre pays et secteurs.
Des traces complètes pour produire des défenses réutilisables
SAFE demande de préserver les éléments nécessaires à une analyse forensique : prompts, traces, appels d’outils, journaux, configurations, versions des modèles et garde-fous, dépendances, identités des agents, permissions, identifiants disponibles, validations humaines, fichiers modifiés et chronologie complète. Les quasi-incidents seraient inclus, même en l’absence de dommage confirmé. La revue chercherait ensuite les causes techniques et systémiques plutôt qu’un coupable unique.
La sortie attendue ne se limiterait pas à un rapport. Lorsque la divulgation ne crée pas de nouveau danger, l’initiative pourrait publier des tests reproductibles, des politiques lisibles par machine, des règles de détection, des configurations de référence et des procédures de réponse. Le RFC cite comme exemples le blocage réseau par défaut, les listes explicites de cibles autorisées, les manifestes d’évaluation signés, les contrôles d’isolation avant exécution et l’arrêt automatique lorsqu’un agent doute de son périmètre.
NVIDIA présente parallèlement plusieurs briques ouvertes de l’alliance, dont son environnement de test NOOA, le runtime OpenShell et le scanner de vulnérabilités Garak. D’autres membres apportent des outils d’identité, d’autorisation, de red team et de résilience. Ces projets ne constituent pas SAFE lui-même et ne prouvent pas qu’un agent est sécurisé. Ils montrent plutôt le type de contrôle que les enseignements d’un incident pourraient tester, améliorer ou remplacer.
Un bénéfice potentiel réel, avec une gouvernance encore à démontrer
Pour les développeurs et les entreprises qui déploient des agents, la proposition apporte surtout une grille commune. Un incident pourrait être comparé à d’autres cas au lieu d’être traité comme une anomalie isolée, et les corrections pourraient devenir des contrôles automatisés. Pour les utilisateurs, l’effet serait indirect mais concret : notification plus rapide d’une exposition, meilleure traçabilité des actions d’un agent et réduction du risque qu’une même erreur de confinement soit répétée par plusieurs fournisseurs.
La neutralité annoncée devra néanmoins être prouvée. Le RFC souhaite une gouvernance indépendante, une représentation des chercheurs, opérateurs d’infrastructures critiques, autorités et utilisateurs affectés, ainsi qu’un traitement identique des systèmes ouverts et propriétaires. TechCrunch relève toutefois que Google, OpenAI et Anthropic ne figurent pas parmi les membres annoncés, alors que leurs modèles et services occupent une place importante dans l’écosystème. Leur absence limite pour l’instant la portée universelle du projet.
Il reste aussi à déterminer qui vérifiera les rapports, comment les informations seront anonymisées, quelles sanctions suivraient un défaut de signalement et comment mesurer l’adoption des recommandations. Un dispositif trop public pourrait décourager les déclarations ; un dispositif trop confidentiel empêcherait l’examen indépendant. SAFE est donc une proposition structurée et utile, mais son efficacité dépendra de règles finales claires, d’une gouvernance réellement autonome et de preuves que ses membres appliquent les enseignements publiés.
Commentaires
Chargement…
Préparation de votre espace lecteur…
Chargement des commentaires…