Le danger silencieux des agents IA : que se cache-t-il vraiment dans vos logs ?
L'angle mort de la cybersécurité face à l'IA autonome : ce que les récents incidents chez OpenAI et Anthropic nous apprennent sur les menaces latentes dans vos logs.
Le plus inquiétant dans les récentes affaires impliquant OpenAI, Anthropic ou Hugging Face ne réside pas tant dans les prouesses techniques des agents IA, mais dans le fait que les organisations concernées n'ont rien vu venir. Quand Anthropic a réexaminé 141 006 exécutions lors de tests de sécurité, l'entreprise a identifié trois incidents réels—dont deux n'avaient jamais été détectés par les entreprises victimes avant d'être alertées.
Quelques semaines plus tôt, Hugging Face avait détecté une intrusion menée par des agents IA sur son infrastructure. OpenAI a ensuite confirmé que ces plateformes étaient impliquées dans une "supposée évaluation" de capacités cyber.
Ces affaires posent une question qui dépasse largement ces deux entreprises et le buzz derrière : Que se passe-t-il lorsque des applications exploitant des modèles IA peuvent agir dans un système que personne n’en maîtrise réellement la surveillance de bout en bout ?
L’agent IA change la donne
Dans un système classique, la surveillance repose sur des objets relativement bien identifiés : utilisateurs, serveurs, applications, processus, connexions réseau. Or, Un agent IA fonctionne différemment : on lui fixe un objectif ou une mission, puis il s’appuie sur un modèle d’IA pour déterminer lui-même comment l’atteindre, en utilisant les outils et les API à sa disposition et en adaptant ses actions en fonction des résultats obtenus. C'est là que réside le danger : l'enchaînement de ces actions légitimes n'étant pas défini à l'avance, il devient impossible de garantir une exécution identique à chaque fois. Un agent peut parfaitement avoir le droit d’accéder à une base de données, à une base documentaire et d’appeler une API externe. Pris séparément, ces accès sont parfaitement légitimes. Mais leur enchaînement peut conduire à une action que personne n’avait prévue. Le sujet n’est donc plus seulement de vérifier si chaque accès est autorisé, mais de comprendre pourquoi l’agent les a utilisés, dans quel contexte et ce qu’il a fait ensuite.
Entre l’éditeur et le client, qui regarde ?
C’est probablement l’enseignement le plus important de ces incidents.
L’éditeur connaît son environnement : ses tests, ses systèmes de surveillance et ses journaux. L’entreprise cliente connaît son système d’information : ses outils Cyber, ses logs et ses contrôles d’accès.
Mais une fois l’agent déployé chez le client, le fournisseur ne voit plus nécessairement tout ce qui se passe. Et le client ne dispose pas forcément des outils permettant de comprendre le comportement de l’agent.
Il existe donc un espace entre les deux :
éditeur → modèle → agent → environnement client → services tiers
L’affaire Anthropic l’illustre bien. Lors d’un test, l’application utilisant Claude Mythos 5 a publié un paquet Python malveillant sur PyPI après avoir obtenu un accès Internet qu’il n’était pas censé avoir. Le paquet a ensuite été téléchargé par 15 machines réelles, dont celle d’une entreprise de cybersécurité. Personne n’avait besoin de cibler directement cette entreprise. Son propre système a récupéré le paquet dans le cadre de son fonctionnement normal.
Le comportement de l’agent avait traversé plusieurs périmètres de confiance.
141 006 exécutions pour retrouver trois incidents
Le chiffre donné par Anthropic mérite d’être regardé autrement.
Après l’incident, l’entreprise a réexaminé 141 006 exécutions et identifié trois incidents impliquant des organisations réelles. Il serait évidemment faux d’en déduire un taux de risque. Ces exécutions étaient des tests spécifiques.
Mais le chiffre raconte autre chose : pour découvrir ces comportements, il a fallu disposer des traces, de décider de prendre le temps de les examiner et de posséder la capacité de le faire efficacement.
Dans une entreprise, les agents vont progressivement se multiplier. Certains auront accès aux documents internes, d’autres aux outils de développement, aux données clients, aux applications métiers ou à des services externes.
Qui vérifiera leurs actions lorsqu’ils seront des dizaines, voire des centaines ?
Et qui saura distinguer une opération normale d’une séquence inhabituelle mais techniquement autorisée ?
Nos outils voient-ils vraiment ce que fait un agent IA ?
Les outils Cyber traditionnels restent indispensables. Mais ils ne répondent pas forcément à cette nouvelle question. Un SIEM peut enregistrer un appel API. Un EDR peut enregistrer une exécution. L’IAM peut confirmer qu’une identité disposait des droits nécessaires. Mais aucun de ces éléments ne permet vraiment de comprendre pourquoi l’agent a effectué ces actions.
Pour comprendre ce qui s’est passé, il faut pouvoir reconstituer la chaîne : quelles données l’agent a consultées, quels outils il a utilisés, quelles réponses il a obtenues et comment celles-ci ont conduit à l’action suivante.
La Cyber doit donc progressivement apprendre à surveiller non seulement l’infrastructure, mais aussi le comportement des agents.
Le chiffre que nous n’avons pas
Le rapport 2025 de HackerOne signalait une hausse de 210 % des vulnérabilités liées à l’IA et de 540 % des prompt injections. Des chiffres qui montrent l’accélération des recherches sur la sécurité de l’IA, mais qui ne permettent pas de savoir combien d’incidents passent sous les radars.
C’est précisément le problème.
On détecte assez bien ce que l’on sait chercher. Le plus difficile reste de repérer ce que l’on ne pense pas encore à chercher.
Il serait donc excessif d’affirmer qu’une multitude d’incidents liés à l’IA sont déjà passés sous les radars des entreprises : nous n’avons aujourd’hui aucune donnée permettant de le mesurer. En revanche, les incidents récents mettent en évidence une faiblesse structurelle bien réelle : notre capacité à voir et à comprendre ce que font les agents IA reste encore limitée.
Pour chaque agent en production, peut-on savoir ce qu’il a fait hier ? Quels systèmes il a interrogés ? Quelles données il a utilisées ? Quels outils il a appelés ? Et surtout, peut-on expliquer pourquoi il l’a fait ?
Si la réponse est non, le problème n’est pas forcément que l’agent est dangereux, mais que l’entreprise ne dispose pas encore de la visibilité nécessaire pour s’assurer qu’il est sécurisé.
La sécurité de l’IA ne se jouera donc plus seulement dans les modèles IA : il faudra aussi comprendre et tester ce que les agents, qui les utilisent, peuvent réellement faire dans l’environnement de l’entreprise, avant même leur mise en production.