Quand les agents entrent en scène, votre modèle de sécurité vole en éclats

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

La plupart des outils de sécurité d’entreprise actuels reposent sur un ensemble d’hypothèses très précises. Ce n’est pas une mauvaise chose, car ces hypothèses ont été testées et validées des milliers de fois au cours des vingt dernières années. Parmi les principales figure l’idée que les logiciels font ce qu’on leur demande, que les utilisateurs peuvent être profilés et que les systèmes se comportent de manière prévisible dans des conditions connues. Cette approche fonctionnait lorsqu’il s’agissait de sécuriser des API, des serveurs web ou des personnes ayant de mauvaises pratiques en matière de mots de passe.

Mais tout cela vole en éclats avec l’arrivée des agents autonomes.

Les agents ne suivent pas toujours des scripts. Ils n’empruntent pas toujours des parcours définis de manière statique. Ils raisonnent, planifient, s’adaptent et, si vous n’y prêtez pas attention, peuvent mal se comporter. Autrement dit, votre stratégie de défense classique apparaît désormais, rétrospectivement, bien optimiste.

Heureusement, les chercheurs en sécurité commencent à s’attaquer à cette réalité. L’un des signes tangibles de cette évolution a pris la forme d’un article intitulé « Sécuriser l’IA agentique : modélisation des menaces pour les agents basés sur des LLM ». Celui-ci ne se contente pas d’énumérer de nouveaux scénarios inquiétants : il propose un nouveau cadre opérationnel, conçu pour le monde agentique dans lequel nous plongeons tête baissée.

SHIELD : un cadre conçu pour les agents, pas pour les API

Les auteurs présentent « SHIELD », une approche à plusieurs niveaux pour gérer les agents autonomes dans des environnements réels. Il ne s’agit pas simplement d’une liste de vecteurs d’attaque, mais d’un cadre de gouvernance. SHIELD comprend :

• Mise en bac à sable : Définissez précisément les éléments auxquels un agent peut accéder (outils, fichiers, API) avant qu’il n’agisse. Mettez en place une forme de contrôle d’accès strict. Le principe fondamental est pertinent, et de nombreuses initiatives visant à encadrer l’utilisation des outils par l’IA en général existent déjà.
• Humain dans la boucle : Insérez des points de contrôle ou des procédures d’escalade avant toute action irréversible. Cela semble assez évident, puisque ces mécanismes font partie intégrante de la plupart des initiatives d’automatisation.
• Contraintes d’interface : Règles strictes régissant les entrées et sorties lors des interactions de l’agent avec le système. Cela ressemble à un assainissement des entrées et à une vérification des réponses. Tiens donc.
• Suivi de l’exécution : Surveillez les appels d’outils, les changements d’état de la mémoire et les boucles de planification. Observabilité. Observabilité. Observabilité.
• Journalisation : Consignez les étapes du raisonnement et l’utilisation des outils, et pas seulement les résultats. Cet élément est nécessaire pour former un joli acronyme, mais il va en réalité de pair avec le suivi mentionné ci-dessus et s’inscrit dans une stratégie globale d’observabilité.
• Rejeu déterministe : Reconstituer les sessions d’inférence afin de vérifier pourquoi quelque chose s’est produit, et pas seulement ce qui s’est produit. J’ai énormément de mal à croire que ce soit possible, étant donné qu’il est presque impossible de recréer l’« état » d’un agent — et même de n’importe quelle IA. Mais bon, si c’est faisable, ce serait génial.

Nous n’en sommes encore qu’aux prémices, mais l’idée fondamentale de SHIELD est essentielle : l’IA agentique nécessite de nouveaux points de contrôle, de nouvelles hypothèses et de nouveaux modèles mentaux. Nous l’avons peut-être évoqué récemment, comme dans ce livre blanc. Mais pour l’heure, résumons simplement ce que cela implique concrètement pour les responsables de la sécurité et les ingénieurs.

Les cinq changements que la sécurité doit opérer pour l’IA agentique

1. Des modèles de menace statiques à la surveillance dynamique des comportements
Les modèles de menace traditionnels partent du principe que les attaquants suivent des schémas connus, notamment les déplacements latéraux, l’élévation de privilèges et la diffusion de charges malveillantes. Mais les agents ne suivent aucun schéma connu. Ils peuvent improviser.

Les équipes de sécurité doivent commencer à surveiller les comportements émergents. Cela implique de mettre en place une télémétrie permettant de suivre ce que font les agents, leur raisonnement et les moments où ils s’écartent des trajectoires prévues. Sémantique. Observabilité. Tout est dit.

2. Du contrôle périmétrique à l’application des politiques à l’exécution
Les pare-feu et les protections au niveau des passerelles ne sont d’aucune utilité lorsque l’agent LLM est déjà à l’intérieur et appelle des outils, accède à des fichiers ou envoie des requêtes API de manière autonome.

La sécurité doit se rapprocher de l’environnement d’exécution, en appliquant en temps réel des autorisations limitées à chaque tâche, l’isolation des environnements et la validation des intentions. Voyez cela comme une « policy-as-inference » : ce qu’un agent est autorisé à faire doit être vérifié au moment même où il décide de le faire. Les plans de données et de contrôle convergent, et la sécurité doit impérativement être intégrée à ce processus.

3. De la journalisation des événements à la capture du contexte
On ne peut pas sécuriser ce que l’on ne comprend pas. Or, avec les agents, la compréhension exige davantage que de simples journaux. Les chaînes de prompts, les métadonnées des appels d’outils, les instantanés de mémoire et le contexte d’exécution doivent tous être consignés et traçables. Le contexte est le nouveau périmètre de sécurité.

Pourquoi l’agent a-t-il planifié cinq réunions et envoyé un e-mail à un fournisseur à 2 heures du matin ? Vous ne le saurez pas à moins de pouvoir rejouer son arbre de décision. Il ne s’agit pas d’observabilité, mais d’analyse forensique des agents.

4. De la revue de code aux tests comportementaux
La logique d’un agent ne réside pas dans le code, mais dans la combinaison des poids, des prompts, des outils et du contexte. La revue statique devient donc inutile.

Il faut mettre en place une assurance qualité comportementale dans un environnement isolé : simuler les cas limites, les entrées malveillantes et les limites d’autorisation. Traitez les agents comme des ingénieurs juniors en formation, et non comme des modules de code déterministes.

Le red teaming doit évoluer : il ne s’agit plus de « pénétrer le système », mais de « manipuler l’agent », de manière répétée et en surveillant attentivement les défaillances en cascade.

5. De l’identité de l’utilisateur à l’identité et au périmètre de l’agent
Aujourd’hui, le contrôle d’accès est principalement centré sur l’utilisateur : qui êtes-vous et quels rôles avez-vous ? Cette approche ne fonctionnera pas pour les agents. Il faut désormais attribuer aux acteurs d’IA une identité, un périmètre de privilèges et des limites de tâches ainsi qu’une expiration automatique (de type TTL), une isolation de la mémoire partagée et des journaux d’audit persistants.

En bref : le modèle Zero Trust s’applique désormais aux acteurs non humains. Et cette confiance doit être gagnée chaque fois qu’ils font appel à un outil ou accèdent à une ressource.

La sécurité doit s’adapter

L’IA agentique n’est pas une simple nouveauté : elle représente un changement à l’échelle du système. Lorsque les modèles gagnent en autonomie, l’entropie de votre système augmente et vos anciennes hypothèses deviennent des faiblesses.

La pertinence de SHIELD ne tient pas seulement à sa liste de contrôles, mais à sa philosophie, qui repose sur deux hypothèses fondamentales :

• Partez du principe que les agents s’écarteront du scénario prévu, que ce soit par nature ou sous l’effet d’une manipulation
• Partez du principe que les erreurs de raisonnement peuvent entraîner des effets secondaires à l’échelle du système

Les équipes de sécurité qui les adoptent dès maintenant mettront en place des garde-fous capables de s’adapter à grande échelle. Et celles qui ne le font pas ? Ce sont elles qui devront réparer les dégâts après que les agents auront « simplement essayé d’aider ».

Donc non, vos cadres existants ne suffisent pas. Les agents sont entrés dans la pièce. Il est temps de leur opposer une gouvernance qui comprend réellement ce qu’ils sont.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie