Depuis quelques mois, les titres s’enchaînent : « un agent IA a compromis un système de production », « le modèle s’est échappé de son sandbox », « l’IA exécute des actions que personne n’avait autorisées ». Le registre est quasi-apocalyptique, les partages vont bon train, et tout le monde repart avec une vague angoisse existentielle sur l’alignement des modèles. Sauf que les experts en sécurité, eux, ont une lecture nettement plus terre-à-terre de ces incidents.
Conclusion partagée par plusieurs chercheurs : les agents IA n’ont pas « disjoncté ». Ils ont simplement fait ce qu’on les a laissé faire. Le vrai problème, c’est que les équipes qui déploient ces agents sautent allègrement les fondamentaux de sécurité qu’on applique à n’importe quel système informatique depuis trente ans.
Ce n’est pas un problème d’IA qui échappe au contrôle humain. C’est un problème de déploiement sans isolation correcte ni journalisation digne de ce nom. Un bug humain, pas un bug d’algorithme.
TL;DR — Les rapports d’ »agents IA qui hackent » sont presque tous dus à des lacunes de containment et de monitoring côté infrastructure, pas à un comportement imprévisible du modèle. Les principes classiques — moindre privilège, isolation, journalisation — s’appliquent aux agents IA exactement comme à n’importe quel système. Ceux qui les ignorent ont des incidents.
« L’IA qui hacke » : décryptage d’une panique bien orchestrée
Quand on lit attentivement les rapports d’incidents récents, un pattern se dégage assez vite. Dans la grande majorité des cas documentés, l’agent IA n’a pas contourné de protections sophistiquées. Il a exécuté des actions que son environnement lui permettait explicitement de faire : accéder à des fichiers système parce que personne n’avait restreint les permissions, appeler des APIs externes parce que les règles réseau laissaient tout passer, persister des données sensibles parce qu’aucun mécanisme d’isolation n’était en place.
Ce n’est pas de la magie noire. C’est le résultat prévisible d’un déploiement sans principe de moindre privilège. N’importe quel pentester en rit jaune : c’est exactement le type de configuration qu’on exploite dans les audits classiques, sauf que là c’est un LLM qui joue le rôle de l’attaquant opportuniste — sans même en avoir l’intention.
La narrativité « l’IA est incontrôlable » vend des articles et nourrit les débats sur l’alignement. Mais elle masque un problème bien plus prosaïque : on déploie des systèmes autonomes avec les mêmes pratiques de sécurité décontractées qu’une démo de startup un vendredi à 17h. Le modèle n’est pas le problème. L’infra autour du modèle, si.
Containment : l’art d’oublier le bac à sable
Le containment, c’est l’idée qu’un système — IA ou non — ne devrait pas avoir accès à plus de ressources que ce dont il a besoin pour sa tâche. Un agent qui résume des PDFs n’a pas besoin d’accès en écriture au système de fichiers. Un agent qui répond aux emails n’a pas besoin de se connecter à la base de données de production. C’est le principe de moindre privilège, formalisé dans les années 70, enseigné dans toutes les formations de sécurité, et apparemment optionnel dès qu’on met « IA » dans la description du système.
Pourquoi cette lacune répétée ? Probablement parce que configurer un sandbox propre prend du temps, et que les agents IA ont tendance à casser dès qu’on leur retire des permissions. La tentation est forte d’ouvrir large pour que « ça tourne », avec l’intention de durcir plus tard. Sauf que « plus tard » n’arrive généralement pas avant le premier incident.
L’isolation réseau est dans le même état. Des agents qui tournent avec un accès internet non filtré, sans whitelist d’endpoints autorisés, sans inspection du trafic sortant. Un agent capable de faire des requêtes HTTP arbitraires vers n’importe quelle destination est un vecteur d’exfiltration potentiel — et en cas de prompt injection réussie, c’est directement exploitable par un tiers malveillant.
DÉCOUVREZ NOS RÉALISATIONS
My Nounou
Application PWA de mise en relation parents / assistantes maternelles. Planning, cahier de liaison, generation de contrats et fiches de…
Voir le projet →Monitoring : quand personne ne regarde ce que fait l’agent
L’autre grand absent de la plupart des déploiements d’agents IA : la journalisation fine et la supervision active. Dans un système classique, on loggue les accès aux ressources sensibles, on génère des alertes sur les comportements anormaux, on dispose de dashboards. Pour les agents IA, beaucoup d’équipes se contentent de capturer les inputs et outputs visibles par l’utilisateur — et rien de ce qui se passe en coulisses, côté appels d’outils et actions intermédiaires.
Un agent qui enchaîne des appels d’outils peut générer des dizaines d’actions intermédiaires pour chaque requête utilisateur. Si ces actions ne sont pas tracées avec suffisamment de granularité, tu ne sauras jamais ce qui s’est passé en cas d’incident. Un audit post-mortem sans logs, c’est à peu près aussi utile qu’un détective sans indices.
Des outils comme Langfuse, Arize Phoenix ou Helicone permettent de tracer toute la chaîne d’exécution d’un agent — appels d’outils, tokens consommés, latences, erreurs. Ils s’intègrent en quelques lignes dans les principaux frameworks (LangChain, LlamaIndex, SDK Anthropic et OpenAI). Le coût d’intégration est faible. Le coût de ne pas les avoir après un incident, beaucoup moins.
Le problème, c’est que ces outils demandent un effort d’intégration souvent zappé dans les cycles de déploiement rapides. Résultat : l’agent tourne en production depuis trois mois, et personne ne sait vraiment ce qu’il a fait ni quelles données il a touchées.
Les agents IA ne deviennent pas incontrôlables. Ils font exactement ce qu’on leur a permis de faire — et c’est là le vrai problème.
Les fondamentaux de sécurité s’appliquent aussi bien à l’IA qu’au reste
Ce qui ressort de ces incidents, c’est que la sécurité des agents IA n’est pas un chantier nouveau ou exotique. C’est l’application rigoureuse de principes que la sécurité informatique a formalisés depuis longtemps : moindre privilège, isolation des environnements d’exécution, journalisation complète des actions, audits réguliers, défense en profondeur. Rien de tout ça n’est spécifique à l’IA. Ce sont des fondamentaux.
L’IA introduit des nuances réelles. Les actions d’un agent sont moins déterministes que celles d’un script classique. Il peut prendre des chemins d’exécution imprévus selon le contenu de sa fenêtre de contexte. La surface de prompt injection est nouvelle et mérite des protections spécifiques. Mais le modèle de menace sous-jacent reste le même : un composant avec trop de droits et trop peu de surveillance est un risque, quelle que soit sa nature.
Ce qui change avec l’autonomie, c’est la vitesse d’exécution. Un humain qui fait une erreur de configuration peut la corriger avant qu’elle soit exploitée. Un agent IA peut enchaîner cent actions en quelques secondes. L’argument pour un containment solide en amont est donc encore plus fort que pour un système classique — pas question de remettre le durcissement à la prochaine itération.
Ce que ça veut dire concrètement quand tu déploies un agent
Si tu intègres un agent IA dans une application sur mesure ou un outil métier, quelques questions s’imposent avant la mise en production. D’abord : quels outils cet agent peut-il appeler ? Si la réponse est « tout ce qui est disponible dans le framework », c’est un problème. La liste des outils autorisés doit être la plus restrictive possible selon le cas d’usage. Un agent de support client n’a pas besoin d’accéder aux logs système ni à l’API d’administration.
WESTCODE BY LEB
Studio web en Mayenne — On crée des outils numériques qui transforment
Ensuite : comment est isolé l’environnement d’exécution ? Si l’agent tourne dans le même contexte que ton application principale, avec les mêmes credentials et les mêmes droits d’accès, tu exposes une surface d’attaque considérable. Un environnement séparé, des credentials spécifiques à l’agent avec des droits strictement limités à ses besoins — c’est le minimum.
Attention à la prompt injection. Si ton agent traite des contenus venant de sources externes — emails, pages web scrapées, documents uploadés par des utilisateurs — il peut être manipulé par des instructions malveillantes cachées dans ces contenus. Ce vecteur d’attaque est spécifique aux LLM et demande des validations d’input dédiées, ainsi qu’une limitation des actions disponibles dans les contextes à risque.
Enfin, la question du monitoring ne peut pas être une réflexion post-lancement. Des traces d’exécution détaillées, des alertes sur les appels d’outils inhabituels, une rétention des logs suffisante pour des audits post-incident : la mise en place d’une supervision sérieuse n’est pas un luxe dès qu’un système agit de façon autonome sur ton infrastructure.
Le vrai danger, c’est la paresse opérationnelle — pas l’alignement
Mon avis sur le sujet : le narratif « l’IA disjoncte » est confortable parce qu’il déresponsabilise. Si c’est la faute du modèle, pas besoin de remettre en question ses propres pratiques de déploiement. Si c’est un problème d’alignement philosophique, c’est aux grands labos de le régler. On reste spectateur.
Sauf que la réalité des incidents documentés, c’est que la quasi-totalité d’entre eux auraient pu être évités avec des mesures de sécurité basiques correctement appliquées. Ce n’est pas rassurant — parce que ça veut dire que le problème est entièrement dans notre camp. Les bonnes pratiques existent, sont documentées, sont accessibles. C’est juste une question de discipline et de temps alloué.
Le pari que je fais : dans deux ans, les équipes qui auront eu des incidents sérieux avec des agents IA auront presque toutes en commun un manque de containment et une absence de monitoring. Celles qui auront fait les choses correctement dès le début regarderont ça de loin — et elles auront les logs pour expliquer pourquoi leur déploiement n’a pas posé de problème.
