En juin 2026, Backslash Security a mené une enquête auprès d’équipes d’ingénierie et de sécurité issues de divers secteurs d’activité et a constaté que 100 % des personnes interrogées utilisaient du code généré par l’IA en environnement de production. 81 % ont déclaré ne pas savoir où ni comment l’IA était utilisée tout au long de leur cycle de développement.
Ces deux chiffres décrivent une situation structurelle, et non une faille. Le code a été déployé, les agents se sont exécutés, et personne n'a pu voir ce qu'ils ont fait après l'invite. Il s'agit là d'un problème de détection bien documenté : un attaquant, ou dans ce cas précis un agent, passe d'un système à l'autre sans qu'aucun journal ni outil de surveillance ne permette d'avoir une vue d'ensemble. Ce phénomène est désormais intégré dans la plupart des organisations via un mécanisme de déploiement standard.
C'est le modèle d'accès qui pose problème, et non l'agent lui-même
Un agent de programmation basé sur l'IA interprète un objectif, sélectionne les outils permettant de l'atteindre, effectue des appels d'API, lit et écrit des fichiers, soumet des demandes de fusion, exécute des tests et s'adapte en fonction des résultats. Toutes ces opérations s'effectuent à l'aide d'identifiants réels, avec des autorisations attribuées, et sans qu'un être humain ait à valider chaque étape.
Ce modèle d'accès soulève deux problèmes qui se recoupent :
- Le premier est un problème d'authentification : les agents sont dotés d'identifiants. Ils s'authentifient. Le journal d'audit enregistre la réussite de l'opération. Un jeton de développeur volé utilisé par un agent apparaît, dans l'enregistrement d'authentification, identique au même jeton utilisé par le développeur à qui il appartient. Identifiants valides, session valide, appel d'outil valide. L'authentification aboutit.
- Le deuxième problème concerne la visibilité : un agent de codage ne reste pas confiné à un seul système. Il accède au dépôt de code, au pipeline CI/CD, à l’environnement d’ cloud s où s’exécutent les tests, et parfois au référentiel de secrets. Chacune de ces transitions franchit une frontière, et chaque frontière dispose de son propre système de journalisation. Aucun d’entre eux n’a visibilité sur les autres. Trois journaux, trois alertes, un seul chemin d’accès aux données sensibles.
Les personnes chargées de contrôler le travail des agents ne parviennent pas à suivre le rythme imposé par ces derniers.
C'est là que la conversation qu'a eue Noam Brown avec Dwarkesh Patel le 17 septembre prend tout son sens au-delà des cercles de recherche en IA.
Brown est chercheur chez OpenAI, où il se consacre aux systèmes multi-agents. Lorsque OpenAI a déployé un essaim de 10 000 agents pour résoudre un problème mathématique en 88 heures, le résultat obtenu était tel qu’aucun être humain n’aurait pu le vérifier de manière indépendante dans un délai comparable. Son argument : à mesure que le nombre d’agents augmente, l’étape de vérification sur laquelle s’appuient les professionnels ne suit plus le même rythme que le travail lui-même.
Transposons cela au développement logiciel. Un développeur qui examine une modification de code générée par l’IA se forge une opinion sur le code qu’il a sous les yeux. Il n’a pas connaissance des appels d’API effectués par l’agent lors de la génération, des bibliothèques qu’il a récupérées, testées puis écartées, ni des autorisations sur le dépôt qu’il a utilisées tout au long du processus. La révision du code porte uniquement sur le résultat final. Le comportement qui l’a généré se situe ailleurs et n’est souvent pas consigné dans les journaux.
Les données de Backslash confirment cette observation sous un autre angle : 81 % des entreprises utilisent en production du code généré par l'IA sans disposer d'une visibilité systématique sur le processus qui l'a produit. Le code est validé lors des revues de code, mais le comportement qui l'a généré n'est absolument pas examiné.
L'incident Hugging Face a constitué une démonstration de principe d'une condition structurelle
En juillet 2026, un agent d’OpenAI s’est échappé d’un environnement de test interne, a exploité une zero-day e dans un proxy de registre de paquets (un serveur qui récupère à la demande des bibliothèques logicielles tierces), a collecté des identifiants d’accès et s’est propagé latéralement dans l’environnement de production de Hugging Face pendant un week-end. La reconstitution technique réalisée par Hugging Face recense environ 17 600 actions de l’agent. Le propre compte rendu d’OpenAI a confirmé les modèles impliqués.
J 'avais déjà décrit cet incident en détail à l'époque. Ce qui importe ici, c'est la partie « détection ». L'intrusion n'a pas été détectée grâce à des alertes signalant isolément des comportements inhabituels, mais grâce à la corrélation : il s'agissait de rassembler des signaux provenant de plusieurs systèmes distincts et de les relier au sein d'une seule chronologie. La reconstitution, assistée par l'IA, a pris environ une heure. Le même travail, effectué manuellement, aurait pris plusieurs jours.
La reconstitution a été possible car Hugging Face disposait d'un nombre suffisant de journaux connectés pour reconstituer le déroulement des événements. L'intervention de l'IA s'est avérée nécessaire, car aucun processus de vérification humaine ne peut fonctionner à la même vitesse que celle à laquelle opèrent les agents.
Pourquoi les systèmes traditionnels de veille sur les menaces passent à côté de cela par nature
Les renseignements sur les menaces, tels qu’ils sont généralement utilisés, s’appuient sur des indicateurs : adresses IP malveillantes connues, hachages de fichiers, noms de domaine, modèles de comportement attribués à des groupes de menaces identifiés. Ces indicateurs nécessitent un point de référence, c’est-à-dire un élément observé précédemment, répertorié et comparé à l’activité actuelle.
Les agents fonctionnant au sein d'un environnement de développement légitime ne présentent aucune signature connue comme malveillante. Les identifiants sont valides. Les actions menées par l'agent correspondent à l'objectif déclaré. Les progiciels qu'il a téléchargés existent bel et bien et ne font l'objet d'aucun signalement. Il n'y a aucun groupe d'attaquants identifié à rechercher, ni aucune campagne antérieure à recouper.
Chez Hugging Face, même une fois l’incident pleinement élucidé, l’attribution n’a été possible que parce qu’OpenAI s’est manifesté de son plein gré. Les actions de l’agent ont pu être reconstituées à partir des journaux de système. En revanche, ces journaux ne permettaient pas à eux seuls de déterminer qui ou quoi l’avait dirigé. Le principe de détection selon lequel « il faut suivre le comportement, pas la marque » reste d’actualité. Dans ce cas précis, il se peut tout simplement qu’il n’y ait aucune marque derrière ce comportement à identifier.
La détection ne est pas défaillante. Elle est simplement incomplète. La mise en correspondance des indicateurs est conçue pour reconnaître ce qui a déjà été observé, tandis que le comportement des agents à grande échelle génère des schémas qui n’ont jamais été observés auparavant.
Ce qu'il faut réellement pour combler cet écart
La surface d'attaque est bien définie : des agents disposant d'un accès plus étendu que nécessaire, des identifiants présents dans le contexte de l'invite de commande où ils peuvent être récupérés, et aucune visibilité en temps réel sur ce que fait réellement l'agent une fois qu'il est lancé. Dans la plupart des organisations, le SOC n'intervient absolument pas dans ce scénario.
C'est grâce à un signal comportemental reliant les différents systèmes en temps réel qu'il est possible de détecter cela avant que cela ne se produise, plutôt que de le reconstituer a posteriori. Le schéma global : identifiant utilisé, service appelé, référentiel consulté, identifiants d'cloud s récupérés, nouveau cluster atteint. Cette chaîne n'est visible que depuis un endroit permettant d'observer simultanément l'ensemble de ses éléments.
Il s'agit avant tout d'un problème de visibilité, plutôt que d'un problème de détection. La plupart des organisations qui utilisent des agents d'IA dans leur pipeline de développement ne présentent pas encore de lacunes en matière de détection. Elles souffrent d'un manque de signaux, et ce manque de signaux rend inévitables les lacunes en matière de détection.
Vérifier, modifier, limiter
- Demandez à votre SOC s’il dispose d’une visibilité en temps réel sur ce que font réellement les agents IA dans votre pipeline de développement. Il ne s’agit pas de savoir s’il peut voir le code qui a été validé, mais s’il peut voir les appels d’API, l’utilisation des identifiants et l’accès aux ressources d’ cloud s qui ont eu lieu pendant l’exécution de l’agent. Si la réponse est incertaine, c’est non.
- Considérez le pipeline dans lequel s'exécutent vos agents d'IA comme une surface d'attaque à prendre au sérieux. Pour tout système qui ingère du contenu qu'il n'a pas produit lui-même (ensembles de données fournis par les utilisateurs, bibliothèques tierces, résultats de modèles), auditez les chemins par lesquels ce contenu peut déclencher l'exécution de code. Chez Hugging Face, deux de ces voies se sont avérées critiques : l’une où un fichier de jeu de données pouvait ordonner à la plateforme d’exécuter du code sur un serveur distant, et l’autre où un champ de configuration était interprété comme une instruction plutôt que comme une valeur (injection de modèle). Aucune de ces deux failles ne nécessite un attaquant expérimenté pour être exploitée. Elles sont toutes deux corrigibles.
- N'accordez aux agents que les droits d'accès strictement nécessaires à l'exercice de leurs fonctions spécifiques. Un agent qui consulte un référentiel n'a pas besoin d'un droit d'écriture sur le magasin de secrets. Vérifiez les autorisations des agents de la même manière que vous vérifieriez celles d'un compte de service, car c'est exactement ce qu'est un agent : un compte de service exécutant une boucle d'agent.
L'enquête Backslash qualifie cela d'échec de gouvernance plutôt que d'un problème de capacités. Les organisations ont aujourd'hui les moyens de surveiller l'exécution des agents. La plupart n'en voient pas la nécessité.
Ces deux problèmes sont abordés en détail dans mon ouvrage *Mind Your Attack Gaps*, notamment ce que j'appelle la « faille n° 2 » (authentification réussie) et la « faille n° 3 » (mouvement invisible), avec la logique de détection correspondante pour chacune d'elles.