Qu'est-ce qu'un modèle de menace agentique ?
Un modèle de menace agentique cartographie la manière dont un agent autonome peut être attaqué : non pas à travers ses poids, mais à travers tout ce qu'il lit, mémorise, appelle et est autorisé à faire. Il identifie les surfaces d'attaque — injection de prompt directe et indirecte, empoisonnement d'outils, agentivité excessive, empoisonnement de la mémoire, chaîne d'approvisionnement, canaux d'exfiltration, le problème du député confus — afin que chacune bénéficie d'un contrôle dans le harness plutôt que d'un simple espoir dans le prompt système.
Définition
Un modèle de menace agentique est une énumération structurée des surfaces d'attaque, des objectifs de l'adversaire et des voies d'abus spécifiques à un agent IA — ses entrées, son contexte, sa mémoire, ses outils, ses identifiants et son autonomie — utilisée pour décider quels contrôles de harness sont requis avant de donner à l'agent un accès à la production.
Points clés
- Modélisez les menaces pesant sur les actions de l'agent, et non sur les sorties du modèle.
- Chaque entrée lue par l'agent est un canal d'instructions : documents, pages, résultats d'outils, autres agents.
- Chaque outil que l'agent peut appeler est une capacité dont l'attaquant hérite dès qu'une injection réussit.
- La mémoire transforme une attaque ponctuelle en une attaque persistante.
- Le rayon d'impact est défini par les identifiants et les flux sortants, non par le prompt.
- Une surface d'attaque non identifiée n'est pas une surface absente — consignez explicitement par écrit les risques acceptés.
Contexte
La modélisation classique des menaces s'intéresse à ce qu'un attaquant peut envoyer à votre système. Avec les agents, la question la plus difficile est de savoir ce que votre système va lire de sa propre initiative et traiter comme des instructions. Un agent qui récupère une page, ouvre un ticket ou lit le résultat d'un outil a élargi sa frontière de confiance sans que personne ne l'ait explicitement décidé.
Le second changement réside dans l'agentivité. Un chatbot trompé produit une phrase erronée ; un agent trompé effectue un appel, transfère de l'argent, supprime une branche ou envoie un fichier par e-mail. La gravité d'une attaque réussie est déterminée par les outils et les identifiants associés à l'agent, c'est pourquoi la gestion des permissions est une décision de sécurité et non de commodité.
Des frameworks structurent cet exercice : l'OWASP Top 10 pour les applications LLM répertorie les classes de vulnérabilités et MITRE ATLAS catalogue les tactiques adverses observées contre les systèmes d'IA. Utilisez-les comme des listes de contrôle pour votre propre architecture, et non comme des substituts à celle-ci.
Architecture
Injection de prompt directe — la personne qui interagit avec l'agent tente de contourner ses instructions. C'est la tentative la moins coûteuse et la plus facile à limiter, car cet utilisateur se trouve déjà dans les limites des permissions accordées par la session.
Injection de prompt indirecte — instructions dissimulées dans le contenu récupéré par l'agent : une page web, un PDF, un commentaire de ticket, un e-mail, un fichier source, la sortie d'un autre agent. L'attaquant n'interagit jamais directement avec votre agent ; il place du texte là où l'agent va le lire.
Empoisonnement d'outil — un outil dont la description ou le résultat est lui-même malveillant. Un serveur peut décrire un outil inoffensif au moment de l'approbation et le modifier par la suite, de sorte que la confiance est vérifiée une seule fois mais exploitée indéfiniment.
Agentivité excessive — l'agent détient des permissions plus larges que ce que requiert une tâche unique. Rien n'a encore mal tourné ; la surface d'attaque réside dans le fait qu'un agent détourné hérite instantanément de tout ce que le harness était prêt à lui accorder.
Empoisonnement de la mémoire — de faux faits ou instructions sont écrits dans la mémoire persistante ou une base de données vectorielle, de sorte que l'attaque survit à la session et se déclenche à nouveau lors de tâches futures et non liées.
Chaîne d'approvisionnement — modèles, prompts système, serveurs MCP, packages et jeux de données importés de l'extérieur de l'organisation. Une dépendance capable de réécrire la description d'un outil est une dépendance capable de réécrire le comportement de l'agent.
Canaux d'exfiltration — toute voie par laquelle des octets peuvent sortir : une requête fetch sortante, une URL d'image affichée dans une réponse, un outil d'e-mail ou de webhook, un commit. Les données n'ont pas besoin d'être lues par un humain pour être volées ; une URL suffit.
Député confus — l'agent agit avec des identifiants que le demandeur ne possède pas, de sorte qu'un attaquant ne pouvant pas accéder directement à un système demande à l'agent d'y accéder pour son compte.
Composants
Avantages
- Il transforme la question « notre agent est-il sûr ? » en une liste finie de surfaces disposant chacune d'un responsable et d'un contrôle.
- Il rend les décisions relatives aux permissions explicites et vérifiables avant que l'accès à la production ne soit accordé.
- Il fournit aux red teams une liste de cibles et offre aux suites d'évaluation des cas concrets à automatiser.
- Il vieillit bien : les modèles changent souvent, les surfaces évoluent lentement, de sorte que la cartographie survit au prochain changement de modèle.
Risques
- Modéliser le chatbot et non l'agent — énumérer les préjudices liés aux sorties tout en ignorant les outils qui les transforment en actions.
- Traiter le modèle comme le point de contrôle. L'alignement réduit les tentatives ; il ne limite pas les conséquences.
- Un document rédigé une fois et jamais révisé. Chaque nouvel outil constitue une nouvelle surface, le modèle doit donc être intégré au processus de gestion du changement.
- Confondre couverture et défense : nommer une surface ne signifie pas la contrôler, et un contrôle non testé n'est qu'une simple affirmation.
Outils et technologies
Exemples
- Un agent de support qui lit les e-mails des clients : le corps du message est une entrée d'instruction non approuvée, l'outil CRM est la capacité, et le canal de réponse est le chemin d'exfiltration. Trois surfaces pour une seule fonctionnalité.
- Un agent de codage avec accès en écriture au dépôt et sortie réseau : injection via le README d'une dépendance, capacité via l'outil de commit, exfiltration via tout registre qu'il peut atteindre.
- Un agent de recherche sur un wiki interne : toute personne pouvant modifier une page peut rédiger des instructions que l'agent lira, ce qui fait d'un éditeur interne à faibles privilèges un vecteur d'injection.
FAQ
- En quoi cela diffère-t-il d'un modèle de menace classique ?
- La méthode est la même ; ce sont les surfaces qui sont nouvelles. Les modèles classiques partent du principe que le code exécute des instructions et que les données n'en contiennent pas. Avec un agent, les données sont des instructions — ainsi, la recherche, la mémoire et les résultats des outils deviennent tous des canaux d'entrée accessibles par un attaquant.
- En ai-je besoin si mon agent est en lecture seule ?
- Oui, mais plus restreint. Un agent en lecture seule possède toujours une surface d'exfiltration — on peut lui faire répéter tout ce qu'il peut lire — et la « lecture seule » est une propriété qui doit être appliquée au niveau de la couche de l'outil, et non supposée à partir du prompt.
- Par quoi commencer si je n'ai encore rien rédigé ?
- Listez les outils que l'agent peut appeler et les données auxquelles chacun accède. Ce simple tableau génère la majeure partie de la cartographie : les capacités représentent le rayon d'impact, et les entrées qui peuvent les atteindre constituent les chemins d'attaque.
- À quelle fréquence doit-il être révisé ?
- Chaque fois qu'un outil, une source de données ou un niveau d'autonomie change — ce sont ces événements qui créent des surfaces. Les mises à niveau des modèles importent moins qu'on ne le pense ; elles modifient la probabilité, pas la portée.