Les professionnels de la cybersécurité sont aujourd’hui obsédés par la traçabilité des données et les fuites via les prompts des grands modèles de langage. Pourtant, cette préoccupation relève d’un problème d’hier. Selon le rapport 2025 AI Security Benchmark de SandboxAQ, 52 % des responsables de la sécurité citent les fuites de données sensibles comme leur principale inquiétude. En tant qu’ingénieur en cryptographie et sécurité, je m’intéresse aux fondements de ces systèmes. Le véritable risque a évolué : il ne s’agit plus de ce que les utilisateurs disent à une IA, mais de ce que les agents autonomes sont autorisés à faire.

Nous entrons dans l’ère des opérations fantômes : le déploiement incontrôlé d’agents autonomes exécutant des logiques, s’intégrant à des systèmes via des appels API et modifiant des états sans supervision de sécurité formelle. Les retours directs des responsables de la sécurité confirment cette tendance. De nombreuses organisations ont déjà déployé l’IA à travers leurs unités métiers, utilisant des services gérés, l’intégrant dans les flux de travail, voire construisant leurs propres agents. Pourtant, lorsqu’on leur demande où se trouvent ces agents et ce qu’ils sont autorisés à faire ou à accéder, les réponses sont souvent incertaines.

L’ère OpenClaw : une adoption rapide mais risquée

Une tendance émergente montre une adoption accélérée des frameworks d’IA agentique pour automatiser et rendre certains processus plus efficaces. Des projets open-source comme Moltbot et le mouvement OpenClaw visent à fournir des outils déployables avec un minimum de friction. Bien que ces initiatives favorisent l’innovation, elles contournent les principes traditionnels de sécurité « par conception » appliqués au code de production.

Dans un scénario d’opérations fantômes, un développeur bien intentionné pourrait utiliser un framework agentique pour automatiser un flux de travail complexe, comme un processus ETL ou un script de déploiement cloud. Pour le faire fonctionner rapidement, il pourrait accorder à l’agent une clé API à privilèges élevés (par exemple, un accès AdministratorAccess AWS ou un jeton d’accès personnel GitHub avec portée complète sur les dépôts de code). Le résultat est une entité autonome non déterministe s’exécutant dans une fonction cloud avec les clés du royaume, invisible pour vos outils de gestion de la posture de sécurité cloud (CSPM).

Le risque ne concerne plus seulement la confidentialité des données ou la sécurité et la vie privée ; il s’agit de l’intégrité opérationnelle de l’entreprise. L’impact passe d’une amende pour non-conformité à une perte financière directe et à une rupture de confiance dans notre propre technologie.

Pourquoi votre stack de sécurité est aveugle face à ces menaces

Notre suite d’outils de sécurité actuelle n’est pas conçue pour résoudre les problèmes des opérations fantômes. Les solutions standard de prévention des fuites de données (DLP) et de gestion des identités et des accès (IAM) sont souvent aveugles aux identités éphémères agentiques. Un CSPM peut voir un serveur légitime exécutant un processus légitime, mais il ne voit pas la logique IA non vérifiée appelant une ressource tierce via une clé API intégrée.

Nous avons un déficit de visibilité profond. On ne peut sécuriser ce que l’on ne voit pas, et on ne voit pas ces agents là où ils naissent. Si votre vision de la sécurité commence une fois le logiciel en cours d’exécution, vous regardez au mauvais endroit. Ce problème est amplifié par une chaîne d’approvisionnement de plus en plus complexe.

L’incident récent impliquant OpenAI et son fournisseur d’analytique, Mixpanel, sert d’exemple de base : une faille chez un sous-traitant a exposé des métadonnées de compte. Avec les frameworks agentiques, la chaîne d’approvisionnement s’étend à chaque modèle, plugin et outil externe que l’agent est autorisé à appeler.

L’importance d’un AI Bill of Materials

Sans un inventaire unifié qui cartographie quel agent utilise quel modèle, s’exécute sur quel hôte et accède à quelles ressources, les équipes de sécurité ne peuvent pas comprendre l’étendue des dommages potentiels. C’est ici que le concept d’AI Bill of Materials (AI BOM) devient opérationnel, non théorique.

Un AI BOM est un inventaire structuré des modèles, agents, couches d’orchestration et dépendances intégrés dans une application ou un système IA. Il doit identifier les appels de modèles tiers gérés ainsi que les modèles auto-hébergés découverts dans les dépôts ou les charges de travail cloud. Sans cette base d’inventaire, la gouvernance ne peut être appliquée.

Il y a également une confusion sur le marché quant à ce qu’un AI BOM peut réellement capturer. Certains s’attendent à ce qu’il inclue la traçabilité complète des données d’entraînement, les versions de modèles et les chaînes de dépendances. En pratique, la transparence des données d’entraînement varie. Les modèles standard peuvent exposer des métadonnées via des sources telles que les cartes de modèle, tandis que les modèles finement ajustés ou entraînés en interne peuvent ne pas faire surface automatiquement cette traçabilité.