Runtime : la nouvelle frontière de la sécurité des agents IA

Les agents d’IA opèrent déjà au sein des réseaux d’entreprise, effectuant discrètement une partie du travail que les employés effectuaient autrefois eux-mêmes : écrire du code, rédiger des e-mails, récupérer des fichiers et se connecter aux systèmes internes.

Parfois, ils commettent aussi des erreurs coûteuses.

Chez Meta, une employée a demandé à un assistant IA de l’aider à gérer sa boîte de réception. Il l’a supprimé à la place. Chez Amazon, un agent interne a décidé de manière autonome de démolir et de reconstruire un environnement de déploiement, mettant ainsi un service AWS hors ligne pendant 13 heures.

Ces incidents offrent un aperçu d’un changement plus vaste auquel les responsables de la sécurité sont confrontés : les logiciels autonomes agissent désormais dans les environnements d’entreprise avec de réelles autorisations et de réelles conséquences.

Pendant des années, la plupart des efforts visant à sécuriser l’IA se sont concentrés sur la prévention : analyse des modèles, filtrage des invites et analyse du code généré par l’IA avant qu’il n’atteigne la production. Mais à mesure que les entreprises déploient des agents autonomes qui interagissent directement avec les systèmes internes, certains responsables de la sécurité affirment que le risque réel ne commence qu’une fois ces agents opérationnels.

« En matière de sécurité, nous partons toujours du principe que la prévention échouera », déclare Sullivan. « C’est pourquoi la détection et la surveillance sont tout aussi importantes. »

La rapidité et l’autonomie des agents IA signifient que des erreurs ou des actions inattendues peuvent se répercuter rapidement sur les systèmes. Cette dynamique explique pourquoi un nombre croissant de responsables de la sécurité se mobilisent, du moins conceptuellement, autour de ce que Sullivan appelle la sécurité d’exécution, ou surveillent en permanence les agents lorsqu’ils opèrent dans les environnements d’entreprise.

En termes simples, la sécurité d’exécution se concentre sur ce que fait le logiciel pendant son exécution, plutôt que de simplement l’évaluer avant son déploiement.

Pourquoi les agents changent le modèle de sécurité

Les RSSI ont passé des années à régir le comportement humain au sein des réseaux d’entreprise. Ils disposent d’outils de gestion des identités, de contrôles d’accès basés sur les rôles, d’analyse du comportement des utilisateurs et de détection des points de terminaison.

La question est de savoir si ces mêmes cadres – et ces mêmes outils de suivi des employés – peuvent être étendus aux agents IA. Les responsables de la sécurité qui étudient le problème affirment que la réponse est : seulement partiellement. Les cadres traditionnels s’appliquent toujours sur le plan conceptuel, mais les mécanismes requis pour observer le comportement des agents sont fondamentalement différents.

« Ce qui n’est pas nouveau, le comment est nouveau », déclare Hanah-Marie Darley, co-fondatrice et directrice de l’IA de Geordie AI. « Comment obtenez-vous réellement ces données, où vous obtenez réellement les informations comportementales de l’agent principalement via des journaux, et toutes les plates-formes d’agents IA ne signifient pas que vous obtenez des journaux, que vous avez des journaux en premier lieu. »

Les outils de sécurité traditionnels ont été conçus pour intercepter le comportement humain aux points de contrôle périmétriques où les employés accèdent à Internet, se connectent aux systèmes ou déplacent des données au-delà des frontières. Les agents contournent souvent complètement ces points de contrôle. Ils fonctionnent via des appels API et des connexions MCP qui peuvent ne jamais passer par les outils de sécurité qui signaleraient normalement un comportement anormal.

Ils génèrent également beaucoup plus d’activité. Alors qu’un employé type peut produire 50 à 100 événements de journal sur une période de deux heures, un agent peut générer 10 à 20 fois ce volume dans la même fenêtre. Et surtout, ils ne produisent souvent aucun journal.

Certaines plates-formes d’agent génèrent par défaut des pistes d’audit robustes. D’autres non. Les agents de codage peuvent écraser leurs propres journaux de session lorsqu’une session précédente est relue, ce qui signifie qu’une équipe de sécurité enquêtant sur un incident peut constater que l’enregistrement de ce qui s’est passé a été effacé.

Le problème des stocks

Avant qu’un RSSI puisse surveiller ce que font les agents, il est confronté à un défi plus élémentaire : savoir quels agents existent.

Cette idée simple est plus difficile qu’il n’y paraît. Dans de nombreuses grandes entreprises, les agents prolifèrent plus rapidement que ce que n’importe quel inventaire central peut capturer. Les équipes marketing déploient des assistants IA. Les services RH font appel à des agents pour la sélection des CV. Les ingénieurs exécutent des agents de codage avec un accès étendu au système de fichiers. Les employés non techniques connectent des outils de productivité IA tels que des preneurs de notes, des gestionnaires de messagerie et des assistants de planification aux comptes d’entreprise, souvent sans l’approbation formelle du service informatique.

« Les RSSI sont actuellement confrontés à une question difficile de la part de leur conseil d’administration et de leur PDG », explique Sullivan. « Quelle IA est actuellement utilisée au sein de l’entreprise ? Vous devez répondre à cette question. Quelle IA est utilisée et que fait-elle ? »

Darley recommande de commencer par un effort d’inventaire structuré, idéalement en utilisant des outils spécialement conçus pour la découverte d’agents, car les systèmes de gestion d’applications à usage général ne peuvent souvent pas voir les agents vivant dans le cloud, dans des référentiels de code ou sur des plateformes SaaS tierces.

« Commencez avec au moins un système », conseille-t-elle. « Cela vous donnera une idée de l’échelle, vous aidera à comprendre qui sont les propriétaires et commencera à vous renseigner sur le type d’outillage dont vous avez réellement besoin. »

Sans inventaire, la surveillance comportementale n’a rien sur lequel elle puisse s’ancrer. Les équipes de sécurité peuvent consulter les journaux des agents qu’elles connaissent. Mais les agents qu’ils ont manqués sont précisément ceux qui sont les plus susceptibles d’avoir des conséquences fâcheuses.

À quoi ressemble la surveillance de l’exécution

Une fois qu’une organisation sait où se trouvent ses agents, la question est de savoir quoi surveiller – et comment.

L’EDR de CrowdStrike, par exemple, crée un graphique des menaces : une carte connectée des comportements et de leurs causes en amont. Si une connexion réseau suspecte se produit, le graphique des menaces peut remonter à travers de nombreux degrés de séparation jusqu’à l’application ou à l’agent qui a initié la chaîne.

« La technologie EDR peut associer ce comportement final au fait qu’il provient d’une application finalement pilotée par un système agent », explique Zaitsev. « Un pare-feu vous indique simplement que quelque chose sur cet ordinateur essaie de communiquer avec un modèle d’IA dans le cloud. EDR vous permet de dire : cette application spécifique parle à ce modèle spécifique. »

Pour les agents IA en particulier, cela crée un nouvel ensemble de contrôles. Un système qui reconnaît une application d’agent connue (Claude Code, OpenAI’s Codex, OpenHands) peut appliquer une politique différente à cette application qu’à la même application exécutée sous contrôle humain. « Il y a des activités qui peuvent être inoffensives si un humain est responsable », explique Zaitsev, « mais s’il s’agit d’un agent d’IA en qui je n’ai pas nécessairement confiance, je souhaiterai peut-être appliquer des politiques différentes à la volée. »

La sécurité au moment de la construction a toujours un rôle central à jouer

Toutes les entreprises ne se contenteront pas d’introduire des agents d’IA prêts à l’emploi. Beaucoup construiront eux-mêmes de tels systèmes.

Pour cette raison, la surveillance de l’exécution ne signifie pas que la sécurité au moment de la construction (analyse du code, évaluation des modèles avant le déploiement et vérification des invites) est un problème d’hier. Varun Badhwar, PDG d’Endor Labs, s’oppose à ce type de cadrage.

Une vulnérabilité détectée alors qu’un développeur est encore en train d’écrire du code prend quelques minutes à corriger. Cette même vulnérabilité, une fois déployée dans un conteneur, exécutée via le contrôle qualité et transférée vers un environnement de production, nécessite de retracer chaque étape de ce parcours avant de pouvoir y remédier – pour un coût environ cent fois supérieur. Badhwar utilise l’analogie d’une chaîne de fabrication automobile : les contrôles de qualité sur la chaîne de montage coûtent toujours moins cher que le rappel de 70 000 voitures dans la rue.

Son cadre est simple : Shift gauche, bouclier droit. Intégrez autant de contrôles de sécurité que possible au processus de développement : détectez les problèmes pendant la création des agents, et non après leur exécution. Ensuite, protégez-vous avec la surveillance de l’exécution comme filet de sécurité du dernier kilomètre, car certaines choses passeront toujours à travers et les vulnérabilités du jour zéro, par définition, ne peuvent pas être anticipées au moment de la construction.

Ce que les RSSI devraient faire maintenant

Pour les RSSI, le changement concerne moins un nouvel outil unique qu’une nouvelle façon de penser les risques liés à l’IA. Au lieu de se concentrer uniquement sur la manière dont les agents sont créés, les équipes de sécurité ont de plus en plus besoin d’avoir une visibilité sur leur comportement une fois qu’elles commencent à opérer au sein des systèmes de l’entreprise.

La voie à suivre pour les RSSI ne consiste donc pas à créer un seul nouveau produit ou à remplacer l’infrastructure existante. Il s’agit d’une extension méthodique de la discipline de sécurité à une nouvelle catégorie d’acteurs au sein de l’entreprise.

Zaitsev l’encadre en utilisant le modèle de sécurité en profondeur : vous n’arrêtez pas de sécuriser les agents au moment de la construction simplement parce que la surveillance de l’exécution est disponible. Vous construisez les deux. « L’EDR et la sécurité d’exécution constituent ce filet de sécurité de dernier niveau », dit-il. « Vous voulez toujours toutes ces autres couches. »

Mais les experts affirment que les points de départ suivants pourraient constituer des premières étapes pratiques vers la mise en œuvre de la sécurité d’exécution pour la plupart des RSSI :

Construisez d’abord un inventaire. Choisissez un système (une plate-forme SaaS majeure, vos référentiels de code, votre flotte de points de terminaison) et cartographiez les agents qui y opèrent. Identifiez les propriétaires, les autorisations et les protocoles. Sans visibilité, rien d’autre n’est possible.

Étendez la surveillance comportementale aux agents. Que ce soit via EDR, des outils de sécurité d’agent dédiés ou une combinaison, établissez à quoi ressemble la normale. À quels systèmes chaque agent doit-il toucher ? Quelles données doit-il traiter ? Avec qui doit-il communiquer ? Les écarts par rapport à cette ligne de base sont votre signal.

Appliquez des politiques spécifiques à l’agent. Ne gouvernez pas les agents avec les mêmes contrôles que vous utilisez pour les employés. Ils ont différents modèles d’accès, différents profils de risque et différents modes de défaillance. Les outils orientés agents peuvent différencier les politiques selon qu’une application est ou non pilotée par l’IA.

Concevez une réponse aux incidents avant que vous en ayez besoin. Sachez comment arrêter un agent qui se comporte mal sans détruire les preuves de ses actes. Les journaux comportementaux doivent être capturés dans des magasins distincts et protégés en écriture, et pas seulement dans la journalisation native de la plateforme d’agent, qui peut être écrasée.

Planifiez des solutions d’IA aux problèmes d’IA. Vous ne parviendrez pas à embaucher pour relever le défi du volume. Les équipes de sécurité auront besoin d’automatisation pour surveiller les systèmes qui fonctionnent à la vitesse des machines.

Voir aussi :

• IA agentique : un cauchemar de sécurité en devenir pour un RSSI ?
• Vous pensez que l’IA agentique est difficile à sécuriser aujourd’hui ? Attends juste quelques mois
• Ce que les RSSI doivent savoir sur les nouveaux outils de sécurisation des serveurs MCP
• Des serveurs MCP mal configurés exposent les systèmes d’agents IA à des compromissions
• Comment les responsables de la cybersécurité peuvent-ils se défendre contre l’impulsion du NHI piloté par l’IA ?
• MCP : sécuriser l’épine dorsale de l’IA agentique