Beaucoup de gens ne mesurent pas toutes les implications de l’IA agentique. Nous devons le faire, surtout en matière de sécurité, même si cela ébranle nos fondements.
Spoiler : ce sera le cas.
Par exemple, le Top 10 de l’OWASP sur les agents IA part d’un constat juste : les agents amplifient les vulnérabilités existantes. Vos API ne sont pas soudainement devenues sécurisées simplement parce que vous avez placé un LLM devant elles. Au contraire, elles sont désormais davantage exposées, puisqu’un système les sonde en permanence, enchaîne les actions et explore différentes voies à la manière d’un attaquant très patient. Cette liste met également en évidence, à juste titre, l’exécution en plusieurs étapes, l’enchaînement d’outils et la manière dont les décisions évoluent au fil du temps.
Mais elle s’arrête juste avant d’aborder le problème plus profond auquel nous devons faire face.
Réussites et échecs
La liste de l’OWASP souligne que les agents n’inventent pas des modes de défaillance entièrement nouveaux ; ils rendent les anciens plus dangereux. Le détournement des outils, la transmission des privilèges d’une étape à l’autre et le détournement des objectifs constituent des risques réels, qui se manifestent au fil de séquences plutôt que dans des invites ou des requêtes isolées. L’OWASP comprend la nature dynamique des systèmes agentiques. Tout cela est vrai.
Mais ces recommandations restent encore largement ancrées dans le modèle traditionnel requête-réponse. Elles partent du principe que la requête constitue la principale unité de contrôle : valider l’identité, vérifier les autorisations, examiner et prendre une décision. Ce modèle fonctionnait lorsque les workflows étaient prédéfinis et délimités par la conception de l’application.
Les systèmes agentiques remettent en cause cette hypothèse.
Ils construisent des flux à l’exécution afin d’atteindre un objectif. Ils évaluent les résultats, s’adaptent, procèdent par itérations et élargissent leur périmètre. Chaque requête prise individuellement peut être parfaitement valide — l’identité est correcte, les autorisations sont conformes et les règles sont respectées — alors même que le comportement global peut s’éloigner considérablement de l’intention initiale.
C’est de là que vient notre sentiment de perte de contrôle. Ce n’est pas que la gestion des identités nous fasse défaut. L’authentification reste robuste. La propagation et la délégation des identifiants fonctionnent comme prévu. Les agents opèrent avec leur propre identité ou avec des identifiants délégués, et les jetons circulent de manière fiable entre les services.
Le problème se situe ailleurs. Le contrôle d’accès traditionnel reposait sur un principe implicite : des flux délimités. Les applications définissaient les séquences d’actions. Même avec une logique de branchement, le système lui-même limitait ce qui pouvait se produire. Cette structure nous permettait d’évaluer les requêtes de manière isolée, car les parcours possibles étaient limités. Nos politiques reposent sur ce principe, et nos mécanismes d’application sont justement censés faire respecter ces limites.
Mais les agents remplacent les flux prédéfinis par des flux émergents. Leur comportement évolue de manière dynamique, combinant souvent des appels d’API ponctuels avec des sessions de longue durée et des interactions en continu. Un agent peut explorer un jeu de données, enrichir progressivement son contexte, puis effectuer des opérations d’écriture que personne n’avait anticipées. Les boucles incontrôlées, les hausses de coûts inattendues et les actions surprenantes entre différents systèmes ne sont pas dues à des défaillances d’identité ou à des requêtes individuelles ; elles résultent de l’enchaînement d’actions valides en séquences involontaires.
Ils sont conçus pour fonctionner sans limites, mais restent bridés par des systèmes de sécurité qui partent du principe qu’ils sont soumis aux mêmes contraintes que les applications traditionnelles.
La traversée de répertoires en est un bon exemple. Depuis longtemps, nous considérons la manipulation des chemins comme malveillante et la bloquons. Et à juste titre, car nous disposons d’un ensemble clairement défini de chemins attendus, et tout écart par rapport à cet ensemble doit être considéré comme suspect.
Mais pour un agent chargé de récupérer des documents ou de constituer un contexte à partir d’un système de fichiers, parcourir l’arborescence n’a rien de suspect. C’est au contraire indispensable. Bloquez totalement cette possibilité et l’agent devient inutile. Autorisez-la sans aucune limite et vous donnez les clés du royaume à un explorateur agressif.
Le véritable problème n’est pas le parcours. C’est le parcours sans limites qui pose problème. Le même schéma se retrouve dans l’utilisation abusive d’outils, le détournement d’objectifs et l’empoisonnement de la mémoire : le risque s’accumule au fil des séquences, et non de manière isolée.
Le changement nécessaire : passer de la validation des requêtes à la gouvernance des comportements
L’identité reste nécessaire pour l’authentification et l’attribution, mais elle ne suffit pas à régir les comportements dans la durée. Les modèles fondés sur les rôles et les périmètres supposent des schémas prévisibles et des interactions limitées. Dans les environnements agentiques où l’exécution repose à la fois sur des modèles basés sur les requêtes et sur les sessions, ils n’offrent qu’un contrôle sommaire.
Nous devons faire évoluer le contrôle d’accès vers une gouvernance des comportements. Cela implique d’évaluer les requêtes dans leur contexte global : ce qui s’est déjà produit, la manière dont le comportement évolue et la façon dont les actions s’étendent à plusieurs protocoles. L’application des règles doit devenir continue et tenir compte des protocoles, en suivant l’accumulation des actions au fil des appels distincts et des sessions persistantes.
La solution réside dans une politique fondée sur des contraintes. Au lieu de prescrire des parcours précis, définissez le cadre opérationnel :
- Limites d’accès aux ressources (lire les données de ces jeux de données, mais ne jamais écrire dans l’environnement de production)
- Limites quantitatives (plafonds concernant les actions, les coûts ou l’élargissement du périmètre)
- Contraintes liées aux capacités (approbation supplémentaire requise avant toute action destructive)
- Politiques conditionnelles qui se renforcent lorsque le risque augmente
Ces contraintes s’appliquent à l’ensemble de la séquence, qu’elle soit véhiculée par des requêtes HTTP ou des flux WebSocket. Les couches architecturales partagées, telles que les passerelles API, les maillages de services et les plateformes d’orchestration, deviennent essentielles. Elles offrent le point d’observation nécessaire pour surveiller, corréler et intervenir à mesure que le comportement se manifeste, tout en propageant le contexte d’exécution avec l’identité.
Le routage lui-même devient un mécanisme de contrôle : il permet de rediriger vers des environnements soumis à des restrictions, de limiter le débit ou d’interrompre les séquences qui approchent des limites définies. L’application des règles devient progressive plutôt que binaire, afin d’orienter le comportement sans interrompre immédiatement les tâches utiles.
La mise à disposition des applications et la sécurité doivent pouvoir fonctionner de concert pour atteindre ces objectifs, en se coordonnant et en communiquant par l’intermédiaire d’un plan de contrôle partagé afin de garantir que les comportements sont encadrés par des politiques, et non par des workflows prédéfinis.
Cette évolution ne nécessite pas d’anticiper tous les scénarios possibles. Elle exige d’affiner en permanence les contraintes en fonction des comportements observés, créant ainsi une boucle de rétroaction entre les opérations et les politiques.
Le changement que nous devons opérer
L’IA ne se contente pas d’introduire de nouveaux risques. Elle nous oblige à repenser la manière dont nous appliquons les contrôles dont nous disposons déjà. Sans cette évolution, nous continuerons d’osciller entre des systèmes techniquement sécurisés mais pratiquement inutilisables, et des systèmes très performants qui échappent discrètement à tout contrôle.
L’unité de sécurité n’est plus la requête, mais le comportement.
La question n’est plus simplement de savoir si une requête est autorisée, mais si le comportement qu’elle représente doit être autorisé à se poursuivre.
C’est le changement de paradigme que nous devons opérer en matière de sécurité agentique.
À propos de l’auteur
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 VittieArticles de blog associés
Les paquets empoisonnés sont en train de tuer notre industrie
L’open source ne dispose pas d’un registre central recensant les paquets malveillants, alors même que l’IA et l’automatisation accélèrent les attaques contre la chaîne d’approvisionnement. L’écosystème a besoin d’un moyen fiable de signaler et de suivre les compromissions.
Top 10 des risques liés à la mise en production d’applications d’IA : manque de sécurité et de conformité réglementaire
L’IA étend la conformité au-delà de la sécurisation des chemins d’accès et des espaces de stockage pour englober la gouvernance du comportement à l’exécution — accès aux modèles, contexte de récupération, résultats et actions des agents —, de sorte que les contrôles doivent être rapprochés de l’inférence.
Top 10 de la livraison d’applications d’IA : politiques de livraison incompatibles
Les divergences de politiques deviennent des sources de pannes pour l’IA : des mécanismes de basculement, des délais d’expiration, des limites et des contrôles de sécurité incohérents entraînent des défaillances silencieuses, des résultats partiels et des résultats différents selon le point de terminaison.
Top 10 de la mise à disposition d’applications d’IA : orientation du trafic non optimisée
L’IA remet en cause les principes traditionnels de répartition du trafic : les backends ne sont pas interchangeables, les coûts varient et les agents multiplient les requêtes de manière imprévisible. Le routage doit donc tenir compte du modèle, de l’état des GPU et de la localisation des données.
Top 10 de la livraison d’applications d’IA : contrôles du trafic insuffisants
Les limites de débit et les mécanismes de régulation traditionnels ne tiennent pas compte de l’étendue réelle des répercussions. Les charges de travail d’IA se répartissent entre les modèles, les bases de données vectorielles et les services, provoquant des pics de latence, des défaillances en cascade et des nouvelles tentatives.
La gestion des fenêtres de contexte en IA n’a rien de magique. C’est une question d’architecture.
Découvrez pourquoi les créateurs d’applications d’IA doivent gérer le contexte, la mémoire et l’infrastructure, tout en faisant évoluer les processus de livraison et la sécurité afin d’éviter la dérive, la latence et les attaques par injection de prompts.