Si vous introduisez des agents, c’est votre modèle de sécurité qui s’en va

La plupart des outils de sécurité d’entreprise d’aujourd’hui reposent sur un ensemble précis d’hypothèses. Ce n’est pas un problème, car ces hypothèses ont été éprouvées et confirmées mille fois ces vingt dernières années. La principale de ces hypothèses est que les logiciels exécutent ce qu’on leur demande, que l’on peut profiler les utilisateurs, et que les systèmes agissent de façon prévisible dans des conditions connues. Cela fonctionnait quand vous sécurisiez des API, des serveurs web ou des utilisateurs avec une mauvaise hygiène de mot de passe.

Mais tout cela s'effondre dès l'arrivée des agents autonomes.

Les agents ne suivent pas toujours un script. Ils ne respectent pas systématiquement des chemins fixes. Ils réfléchissent, planifient, s’adaptent, et sans vigilance de votre part, ils peuvent mal agir. Votre manuel de défense classique est donc devenu bien trop optimiste.

Heureusement, les chercheurs en sécurité commencent à prendre cette réalité en main. Un signe fort de cette prise de conscience s’est manifesté à travers un article : « Sécuriser l’IA agentette : Modélisation des menaces pour les agents LLM ». Plutôt que d’énumérer de nouveaux scénarios effrayants, il propose un cadre opérationnel novateur, pensé pour ce monde agentique dans lequel vous plongez à toute allure.

Les auteurs présentent SHIELD, une méthode structurée pour gérer les agents autonomes dans des environnements réels. Ce n’est pas simplement une liste de vecteurs d’attaque, c’est un plan directeur de gouvernance. SHIELD comprend :

• Sandboxing : Définissez précisément ce qu’un agent peut manipuler (outils, fichiers, API) avant qu’il n’intervienne. Appliquez un contrôle d’accès strict. Le principe fondamental est solide, et de nombreuses initiatives encadrent déjà l’usage des outils par l’IA.
• Humain dans la boucle : Placez des points de contrôle ou des voies d’escalade avant toute action irréversible. Vous savez sans doute que c’est un élément incontournable de la plupart des projets d’automatisation.
• Contraintes de l’interface : Règles strictes pour les interactions d’entrée/sortie entre l’agent et le système. Cela revient à un assainissement des données entrantes et une vérification des réponses. Intéressant.
• Suivi de l'exécution : Surveillez les appels aux outils, les modifications de l’état de la mémoire et les boucles de planification. Observabilité. Observabilité. Observabilité.
• Journalisation : Enregistrez les étapes de raisonnement et l’usage des outils, pas seulement les résultats. Elle est nécessaire pour former un acronyme cohérent, mais s’inscrit surtout dans le suivi évoqué plus haut et fait partie d’une stratégie d’observabilité globale.
• Relecture déterministe : Reconstituez les sessions d’inférence pour comprendre pourquoi un événement s’est produit, pas seulement quoi. Je peine à croire que cela soit possible, car recréer « l’état » d’un agent — ou de n’importe quelle IA — est quasiment impossible. Cela dit, si vous y parvenez, ce serait impressionnant.

Il est encore tôt, mais l’idée clé de SHIELD est cruciale : une IA agentique exige de nouveaux points de contrôle, de nouvelles hypothèses et de nouveaux cadres de pensée. Peut-être vous l’avons-nous déjà dit récemment, comme dans ce livre blanc. Pour l’instant, résumons simplement ce que cela implique vraiment pour vous, responsables et ingénieurs en sécurité.

1. Du modèle statique de menace à la surveillance dynamique des comportements
Les modèles de menace traditionnels supposent que les attaquants appliquent des schémas connus comme les mouvements latéraux, l'escalade des privilèges ou la livraison de charges utiles. Or, les agents ne suivent aucun schéma connu. Ils savent improviser.

Vous devez commencer à surveiller les comportements émergents. Cela implique de mettre en place une télémétrie sur ce que font les agents, leur manière de penser, et leurs écarts par rapport aux chemins prévus. Sémantique. Observabilité. Le point.

2. Des contrôles de périmètre à l’application des politiques en temps réel
Les pare-feu et les protections aux points d’entrée ne servent à rien lorsque l’agent LLM est déjà à l’intérieur, utilisant des outils, accédant aux fichiers ou envoyant des requêtes API de façon autonome.

La sécurité doit s’approcher de l’exécution, en appliquant en temps réel les permissions limitées à chaque tâche, l’isolation de l’environnement et la validation des intentions. Considérez-la comme une politique par inférence : vous devez vérifier ce qu’un agent est autorisé à faire au moment où il choisit de l’exécuter. Les plans de données et de contrôle se fusionnent, et la sécurité doit s’y intégrer pleinement.

3. De la journalisation des événements à la capture du contexte
Vous ne pouvez pas sécuriser ce que vous ne comprenez pas, et avec les agents, comprendre demande bien plus que des journaux. Vous devez enregistrer et tracer rapidement les chaînes de commandes, les métadonnées des appels d’outils, les instantanés mémoire et le contexte d’exécution. Le contexte devient le nouveau périmètre.

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 que si vous pouvez rejouer son arbre de décision. Ce n’est pas de l’observabilité. C’est une analyse forensique d’agent.

4. Des revues de code aux tests comportementaux
La logique d’un agent ne réside pas dans le code, mais dans la combinaison des poids, des invites, des outils et du contexte. Cela rend la revue statique inefficace.

Vous avez besoin d’une assurance qualité comportementale en environnement sécurisé : simulez des cas extrêmes, des entrées adverses et les limites d’autorisation. Faites fonctionner les agents comme de jeunes ingénieurs en formation, pas comme des modules de code dont le comportement est prédéfini.

Le red-teaming doit passer de « pénétrer le système » à « manipuler l’agent » de manière répétée, en repérant avec soin les enchaînements de défaillances.

5. De l’identité utilisateur à l’identité et à la portée de l’agent
Aujourd’hui, la gestion des accès se concentre surtout sur l’utilisateur : qui êtes-vous et quels rôles assumez-vous ? Cette approche ne suffit pas pour les agents. Vous devez désormais attribuer une identité, définir la portée des privilèges et les limites des tâches aux acteurs IA, intégrer une expiration automatique (comme un TTL), assurer l’isolation de la mémoire partagée et garantir des pistes d’audit durables.

En résumé : la confiance zéro concerne désormais également les acteurs non humains. Vous devez leur accorder cette confiance à chaque utilisation d’un outil ou accès à une ressource.

L’IA agentique ne se limite pas à une innovation, c’est une transformation majeure des systèmes. Lorsque les modèles deviennent autonomes, votre système voit son entropie augmenter, et vos anciennes certitudes deviennent des faiblesses.

Ce que SHIELD réussit à faire ne se limite pas à sa liste de contrôles. C’est la philosophie, qui repose sur deux hypothèses clés :

• Anticipez que les agents dévieront du script, par nature ou manipulation
• Considérez que les erreurs de logique peuvent provoquer des répercussions sur l’ensemble du système

Les équipes de sécurité qui s’engagent maintenant établiront des garde-fous capables de s’adapter. Quant à celles qui ne le feront pas ? Ce seront elles qui devront réparer les dégâts causés par des agents « qui voulaient juste aider ».

Non, vos cadres actuels ne suffisent plus. Les agents ont fait leur entrée. Il est temps d'adopter une gouvernance qui saisit vraiment leur nature.