In this article
Comment les agents d’IA compromettent toujours la sécurité, même quand rien ne semble défaillir
Les agents d’IA passent rapidement de l’expérimentation à la production. Ils trient les alertes, examinent les pull requests, résument les journaux, acheminent les tickets et agissent sur différents systèmes avec de véritables identifiants.
Du point de vue de la sécurité, nombre de ces systèmes semblent sains. Aucun code vulnérable aux erreurs de mémoire. Aucune faille d’injection évidente. Aucun problème d’authentification. Et pourtant, ils peuvent quand même échouer — parfois de façon catastrophique — en suivant une simple phrase.
Le problème ne vient pas de correctifs manquants ou de dépendances non analysées, mais plutôt de la façon dont les systèmes non déterministes, comme les LLM, redéfinissent les frontières de confiance.
Des recherches récentes de Snyk Labs explorent les raisons pour lesquelles les modèles traditionnels de sécurité des applications peinent à analyser le comportement des agents, et pourquoi la modélisation des menaces s’impose comme l’une des défenses les plus efficaces pour les applications natives de l’IA.
La sécurité déterministe ne s’applique pas facilement aux systèmes agentiques
La sécurité traditionnelle des applications repose sur des comportements prévisibles. Les entrées sont considérées comme des données, le code encadre les instructions et les contrôles imposent des frontières claires. Les agents d’IA fonctionnent toutefois autrement. Ils interprètent le sens, raisonnent en fonction du contexte et décident quand agir. Cela crée une nouvelle catégorie de risques : le système se comporte exactement comme prévu, mais le résultat reste préjudiciable.
Par exemple :
Un agent d’IA lit un texte non fiable provenant d’un ticket, d’un e-mail ou d’un document.
Ce texte modifie subtilement la façon dont l’agent interprète sa tâche.
L’agent utilise des outils et des autorisations légitimes pour effectuer une action.
Des données sensibles se retrouvent là où elles n’auraient jamais dû se trouver.
Du point de vue d’un outil d’analyse de sécurité, rien n’est « défaillant » ; du point de vue d’un attaquant, tout a fonctionné. C’est pourquoi l’injection de prompt figure en tête de la liste OWASP Top 10 pour les LLM, et pourquoi l’analyse statique seule ne peut pas détecter ces défaillances.
Le véritable risque des systèmes agentiques tient au comportement, pas à la technique
L’un des principaux changements mis en évidence par ces recherches concerne l’origine des défaillances. Les systèmes agentiques échouent généralement au niveau comportemental, et non au niveau du code. Les équipes de sécurité doivent de plus en plus se poser des questions comme :
Cette entrée sert-elle de contexte ou d’instruction ?
Faut-il autoriser cet agent à agir à partir de ce qu’il vient de lire ?
Que se passe-t-il si cette sortie devient l’entrée d’un autre agent ?
Il s’agit de décisions sémantiques, par nature probabilistes. Même des garde-fous bien conçus ne peuvent garantir des résultats parfaits à grande échelle. C’est là que nombre d’outils existants perdent en efficacité — non pas parce qu’ils sont mal conçus, mais parce qu’ils n’ont jamais été pensés pour raisonner sur l’intention, l’autonomie et les flux d’information.
Les incidents récents dans le secteur rendent ce changement indéniable.
Début 2025, des chercheurs ont révélé des défaillances dans les déploiements d’agents d’entreprise de ServiceNow et de Salesforce, alors qu’aucune vulnérabilité traditionnelle n’était présente.
Dans le cas de ServiceNow, un agent interne a correctement traité une demande qui semblait provenir d’un fournisseur de confiance. Cependant, comme l’identité était considérée comme une métadonnée fournie par l’utilisateur plutôt que comme une revendication vérifiée, l’agent a créé une session à privilèges élevés pour le compte d’un attaquant — un cas classique de mandataire confus, déclenché entièrement par la logique de l’agent.
Chez Salesforce, le contenu d’un champ de formulaire public était transmis sans modification à la fenêtre de contexte d’un agent interne de « synthèse ». Une entrée non fiable a ainsi pu influencer l’intention de l’agent et transformer un processus courant en voie d’exfiltration de données. Dans les deux cas, les analyses du code n’ont rien détecté, les autorisations étaient techniquement valides et les systèmes se sont comportés comme prévu. La défaillance s’est produite au niveau comportemental, là où les agents ont déduit le sens, l’autorité et l’intention à partir d’un contexte que les outils de sécurité traitaient comme de simples données inertes.
Pourquoi l’assemblage des agents compte davantage que chaque agent pris individuellement
Nombre des défaillances les plus graves des systèmes agentiques ne trouvent pas leur origine dans un agent isolé. Elles apparaissent lorsque des agents sont combinés dans des processus, des pipelines ou des systèmes orchestrés. Pris individuellement, chacun peut sembler bien conçu : les autorisations sont limitées, les politiques appliquées et les comportements conformes aux attentes. Les contrôles de sécurité sont concluants, car rien ne paraît manifestement dangereux lorsqu’on examine chaque agent séparément.
Le risque apparaît aux points de jonction. Lorsque la sortie d’un agent devient l’entrée d’un autre, de nouveaux flux de données se créent — souvent sans vérification explicite de la sensibilité, de l’intention ou de la destination. Des informations peuvent franchir les frontières de confiance simplement parce que le système suppose que les agents en aval « feront ce qu’il faut ». Cela rappelle des problèmes de sécurité bien connus, comme le mandataire confus ou les écarts entre le contrôle et l’utilisation, mais avec une différence importante : dans les systèmes agentiques, ces défaillances peuvent être déclenchées dynamiquement par le raisonnement du modèle, plutôt que par une logique fixe.
À mesure que les processus agentiques se complexifient, le risque devient une propriété émergente du système plutôt qu’un défaut d’un composant particulier. L’analyse de sécurité doit donc porter en priorité sur l’assemblage des agents, et non sur chaque agent individuellement.
La modélisation des menaces donne aux équipes de sécurité un moyen d’agir
Les outils de sécurité traditionnels peinent à analyser le comportement agentique, car rien ne présente de défaillance technique. La modélisation des menaces réintroduit une structure en déplaçant l’attention de la correction du code vers le comportement du système. Au lieu de se demander si une fonction est vulnérable, les équipes examinent comment les données, les autorisations et les décisions circulent dans un système agentique.
Cette approche fait émerger des questions auxquelles les outils d’analyse ne peuvent pas répondre. Où les entrées non fiables pénètrent-elles dans le processus ? Quels agents peuvent lire des données sensibles ? Quelles actions modifient l’état externe ? Comment les décisions prises plus tôt dans un processus limitent-elles ou permettent-elles les actions ultérieures ?
En cartographiant ces relations, la modélisation des menaces révèle des chemins de défaillance qui n’apparaissent que lorsque les composants interagissent et restent invisibles lorsqu’on examine les agents séparément. Pour les équipes de sécurité qui doivent gérer des systèmes non déterministes, c’est un avantage crucial. La modélisation des menaces ne cherche pas à prévoir tous les résultats. Elle aide plutôt les équipes à comprendre où des défaillances peuvent survenir et à concevoir des contrôles qui en limitent l’impact.
De la prévention au confinement
Les systèmes agentiques nous obligent à repenser la notion de « sécurité ». Lorsque le comportement est probabiliste, le risque peut rarement être ramené à zéro. Même les mesures de protection les plus solides laissent une marge de défaillance et, à grande échelle, de faibles probabilités deviennent des réalités opérationnelles. Dans ce contexte, les stratégies de sécurité fondées uniquement sur la prévention ne suffisent pas.
Le confinement devient tout aussi important que la détection. L’objectif consiste désormais à limiter les ressources auxquelles chaque agent peut accéder, les combinaisons de capacités possibles et la circulation des données sensibles. Au lieu de supposer que les frontières tiendront toujours, les systèmes sont conçus pour rester sûrs même si elles cèdent. Cette approche privilégie la réduction du périmètre d’impact, la séparation des capacités et les contrôles explicites des flux de données.
La modélisation des menaces facilite cette transition en aidant les équipes à déterminer où le confinement est le plus important. Elle fournit un cadre pour concevoir des systèmes résilients, qui continuent de protéger les utilisateurs et les données même lorsque les modèles se comportent de façon inattendue.
Pourquoi la sécurité de l’IA agentique commence par la modélisation des menaces
Les agents d’IA transforment le comportement des logiciels et, par conséquent, la manière dont les défaillances de sécurité se produisent. Les risques majeurs ne résident plus dans des vulnérabilités ou des erreurs de configuration isolées, mais dans la façon dont les systèmes autonomes interprètent le contexte, combinent leurs capacités et agissent au-delà des frontières de confiance. Pour sécuriser ces systèmes, il faut dépasser les hypothèses déterministes et adopter des approches qui tiennent compte du comportement, des interactions et de leur impact.
La modélisation des menaces offre une voie concrète. En considérant le comportement des agents et la composition du système comme des enjeux de sécurité à part entière, les équipes acquièrent la clarté nécessaire pour concevoir des contrôles adaptés au développement piloté par l’IA. À mesure que les systèmes agentiques deviennent essentiels aux applications modernes, cette évolution déterminera la capacité des organisations à faire progresser leur sécurité au rythme des innovations.
Envie d’approfondir le sujet et de lire l’étude complète ? Entrez dans le Lab dès aujourd’hui.
Ou, si vous êtes déjà client de Snyk et que ces recherches vous intéressent, demandez à rejoindre le programme Evo Design Partner pour découvrir en avant-première notre solution Secure Agent Design (modélisation des menaces liées à l’IA).
SNYK LABS
Découvrez les dernières innovations de Snyk en sécurité de l’IA
Les clients Snyk peuvent désormais tester Snyk AI-BOM et Snyk MCP-Scan en avant-première expérimentale – et ce n’est qu’un début !