Sécurité des agents
Les agents lisent des textes écrits par des inconnus, puis agissent avec vos identifiants. Cette page présente la règle fondamentale, les deux listes OWASP de 2026, les incidents recensés à ce jour et les défenses qui les auraient empêchés.
La trifecta létale
- Accès aux données privéesE-mails, dépôts, bases de données, fichiers ou tout autre élément protégé par vos identifiants.
- Exposition à du contenu non fiablePages web, tickets, demandes d'assistance, e-mails reçus et descriptions d'outils : tout texte qu'un attaquant peut rédiger.
- Capacité à communiquer avec l'extérieurEnvoyer des e-mails, ouvrir des pull requests, récupérer des URL ou afficher des images distantes. Simon Willison a nommé cette combinaison de trois facteurs en juin 2025.
Si un agent cumule ces trois capacités, partez du principe qu'une injection de prompt peut l'amener à transmettre vos données à un attaquant. Ne comptez pas sur le refus du modèle ; retirez au moins un de ces éléments à chaque agent et à chaque session.
Checklist de sécurité
22 vérifications couvrant les entrées, les outils, l'environnement d'exécution, MCP, la CI et les opérations. Cochez-les au fur et à mesure et exportez le résultat dans un fichier Markdown.
Journal des incidents
Pour chaque incident public lié à la sécurité des agents depuis avril 2025 : ce qui s'est passé, pourquoi l'attaque a fonctionné et ce qu'il faut modifier dans votre propre configuration.
Incidents récents
- Détournement de session et accès intersessions aux tâches dans le MCP Python SDK
- L’approbation automatique de WebFetch dans Claude Code permettait d’exfiltrer des données via huggingface.co
- Comment and Control : le texte des PR vole les secrets des agents CI
- Le MCP TypeScript SDK a divulgué des réponses entre clients
- ClawHavoc : des centaines de skills ClawHub malveillantes diffusent AMOS
Top 10 OWASP des applications agentiques 2026
L'OWASP GenAI Security Project a publié cette liste le 9 décembre 2025. Elle couvre les risques qui apparaissent lorsqu'un modèle planifie, conserve une mémoire, appelle des outils et travaille avec d'autres agents.
ASI01Détournement des objectifs de l'agentUn attaquant modifie l'objectif de l'agent, généralement au moyen d'instructions dissimulées dans le contenu qu'il lit. L'agent poursuit alors l'objectif de l'attaquant avec les outils et les autorisations de l'utilisateur.
ASI02Utilisation abusive et détournement des outilsL'agent utilise des outils légitimes de manière préjudiciable, par exemple pour supprimer des enregistrements, envoyer des messages ou enchaîner des appels, parce qu'il a été manipulé ou qu'il dispose d'outils dont les capacités dépassent les besoins de la tâche.
ASI03Abus d'identité et de privilègesLes agents agissent au moyen d'identifiants, de jetons délégués et d'autorisations héritées. Les attaquants exploitent ces identités, ou les failles entre elles, pour élever leurs privilèges ou se faire passer pour quelqu'un d'autre.
ASI04Vulnérabilités de la chaîne d'approvisionnement agentiqueLes outils, les serveurs MCP, les skills, les plugins, les modèles et les prompts chargés à la compilation ou à l'exécution peuvent être malveillants ou compromis. Comme les agents en chargent beaucoup dynamiquement, un seul composant défectueux affecte toutes les sessions qui l'utilisent.
ASI05Exécution de code inattendue (RCE)Les agents qui écrivent et exécutent du code, ou transmettent la sortie du modèle à des shells et des interpréteurs, peuvent être manipulés pour exécuter sur l'hôte les commandes choisies par l'attaquant.
ASI06Empoisonnement de la mémoire et du contexteLes attaquants introduisent de fausses informations ou des instructions dans la mémoire d'un agent, les documents récupérés ou le contexte enregistré. Le contenu malveillant persiste et influence les sessions suivantes, longtemps après la disparition de l'entrée initiale.
ASI07Communication non sécurisée entre agentsLes messages échangés entre agents ne sont pas correctement authentifiés, contrôlés quant à leur intégrité ou validés. Ils peuvent donc être usurpés, rejoués ou modifiés pour induire en erreur l'agent qui les reçoit.
ASI08Défaillances en cascadeUne seule défaillance, comme une entrée empoisonnée, un résultat d’outil erroné ou un agent compromis, peut se propager entre les agents connectés et les étapes automatisées plus vite que les équipes ne peuvent réagir.
ASI09Exploitation de la confiance humain-agentLes agents paraissent sûrs d’eux et serviables, si bien que les gens ont tendance à approuver leurs propositions. Les attaquants exploitent cette confiance pour amener une personne à confirmer une action malveillante ou à révéler des informations.
ASI10Agents hors de contrôleUn agent compromis ou qui s’est écarté du comportement prévu continue d’agir de son propre chef, en dehors du périmètre et de la supervision qui lui ont été fixés.
Top 10 OWASP des applications LLM 2026
Cette édition, publiée le 4 août 2026, remplace la liste de 2025. L'autonomie excessive est passée de la sixième à la troisième place, et « System Prompt Leakage » a été renommé « Hidden Context Exposure ».
LLM01Injection de promptUne entrée modifie le comportement du modèle d’une manière non prévue par le développeur. Elle peut provenir directement de l’utilisateur ou indirectement de documents, de pages web et de résultats d’outils consultés par le modèle.
LLM02Divulgation d’informations sensiblesLe modèle ou l’application révèle dans ses réponses des données personnelles, des identifiants, des secrets d’entreprise ou d’autres informations confidentielles provenant des données d’entraînement, du contexte ou de systèmes connectés.
LLM03Autonomie excessiveL’application accorde au modèle davantage de fonctions, d’autorisations ou d’autonomie que la tâche ne l’exige. Une réponse manipulée ou erronée peut alors causer des dommages réels. Cette catégorie est passée de la sixième place en 2025 à la troisième en 2026.
LLM04Chaîne d’approvisionnementLes modèles, jeux de données, adaptateurs, packages et plugins tiers peuvent être altérés ou vulnérables, et introduire ces risques dans votre application.
LLM05Empoisonnement des données et des modèlesDes attaquants manipulent les données de pré-entraînement, de réglage fin ou d'embedding pour y implanter des portes dérobées, des biais ou des comportements défectueux qui ne se manifestent qu'ultérieurement en production.
LLM06Consommation sans limitesSans limites sur le nombre de requêtes, la taille des entrées ou les ressources de calcul, des attaquants peuvent faire grimper votre facture, épuiser vos ressources ou copier un modèle en lui envoyant un grand nombre de requêtes.
LLM07DésinformationLe modèle produit des résultats faux ou trompeurs qui semblent crédibles. Les utilisateurs ou les systèmes en aval s'y fient sans les vérifier.
LLM08Exposition du contexte cachéAnciennement appelée fuite du prompt système. Les prompts système, les instructions cachées et les autres éléments de contexte que l'utilisateur n'est pas censé voir peuvent être extraits, révélant les règles, la logique ou les secrets qui y figurent.
LLM09Faiblesses des vecteurs et des embeddingsDes failles dans la génération, le stockage et la récupération des embeddings permettent aux attaquants d’injecter du contenu, de faire fuiter des données entre différents tenants ou de retrouver le texte source. Les systèmes RAG sont particulièrement exposés.
LLM10Mauvaise gestion des sortiesLes résultats du modèle sont transmis aux navigateurs, shells, bases de données ou autres composants sans validation ni encodage, ce qui ouvre la voie aux attaques XSS, aux injections SQL, à l'exécution de code et à l'exfiltration de données.
Défenses
Quinze défenses documentées, chacune accompagnée d'un lien vers sa source. Combinez-en plusieurs, car aucune ne bloque toutes les attaques à elle seule.
Brisez la triade fatale
La règle de Simon Willison : un agent qui peut lire des données privées, voir du contenu non fiable et envoyer des données vers l’extérieur peut être détourné par n’importe quel texte qu’il lit. Supprimez au moins l’un de ces trois éléments pour chaque agent ou session. Par exemple, l’agent qui trie les tickets publics n’a accès à aucun secret, et celui qui détient des secrets n’a aucun canal de sortie.
Restreignez l’agent après une entrée non fiable
Les recherches sur les patterns de conception pour la sécurité des agents établissent une règle : dès qu’un agent a ingéré une entrée non fiable, celle-ci ne doit pas pouvoir déclencher d’actions lourdes de conséquences. Ces patterns comprennent action-selector, plan-then-execute, dual LLM et la minimisation du contexte. Choisissez-en un par workflow. Par exemple, fixez le plan avant que l’agent ne lise des données non fiables.
Suivre les flux de données avec CaMeL
CaMeL divise l’agent en deux : un planificateur privilégié écrit du code à partir de la demande de l’utilisateur, et un modèle isolé traite les données non fiables. Les valeurs issues de la partie isolée portent des étiquettes de capacité, que les règles vérifient avant l’exécution de tout outil. Dans l’article, CaMeL a résolu 77% des tâches AgentDojo avec une sécurité démontrable, contre 84% pour un agent sans défense.
Utiliser des identifiants à privilèges minimaux
Par défaut, accordez aux agents un accès en lecture seule limité au projet et ne leur donnez jamais une clé admin ou service_role, qui contourne la sécurité au niveau des lignes dans Supabase. Limitez les tokens CI et de dépôt à la seule tâche qu’ils doivent effectuer. L’incident Amazon Q Developer a été lié à un token GitHub trop largement autorisé dans CodeBuild.
Exiger une approbation pour les actions importantes
Demandez à une personne de confirmer les appels d’outils qui écrivent, suppriment, envoient ou dépensent, et refusez par défaut si personne ne répond. Supabase recommande l’approbation manuelle des appels d’outils MCP. Dans OpenClaw, définissez tools.exec.ask sur always et laissez askFallback sur deny. Affichez tous les arguments pour que la personne chargée de la vérification voie exactement ce qui va être exécuté.
Isoler l’exécution du code et des outils
Exécutez les commandes shell et le code généré dans un conteneur ou une VM sans identifiants, qui n’a accès qu’à l’espace de travail. OpenClaw désactive l’isolation par défaut et règle tools.exec.security sur full sur les hôtes de gateway. Activez donc l’isolation, réglez la sécurité exec sur deny ou allowlist, définissez fs.workspaceOnly sur true et laissez le mode élevé désactivé. Vérifiez le résultat avec openclaw sandbox explain.
Limiter l’accès réseau sortant
Bloquez par défaut le trafic sortant des agents et des serveurs MCP, puis autorisez uniquement les hôtes dont chacun a besoin. N’approuvez jamais automatiquement les requêtes vers des hôtes mutualisés où tout le monde peut publier : c’est ainsi que CVE-2026-54316 a transformé huggingface.co en canal d’exfiltration. Un serveur de messagerie ne devrait accéder qu’à son API de messagerie, comme l’a montré postmark-mcp.
Ne pas exposer les plans de contrôle à Internet
Liez les gateways d’agents, les tableaux de bord et les proxies de débogage à loopback et exigez un token d’au moins 24 caractères, généré par exemple avec openssl rand -hex 32. Pour y accéder à distance, passez par un tunnel SSH ou Tailscale Serve, et n’utilisez Tailscale Funnel qu’avec l’authentification par mot de passe. Exécutez régulièrement openclaw security audit --deep.
Valider l’audience des tokens MCP
La spécification d’autorisation MCP exige qu’un serveur rejette les tokens d’accès qui ne lui sont pas destinés et interdit de transmettre le token d’un client à une API en amont. Les clients envoient des indicateurs de ressource RFC 8707 afin que chaque token soit lié à un seul serveur. Un serveur proxy doit obtenir le consentement de chaque client, sans quoi il devient un deputy confus.
Isoler les sessions et les tenants MCP
Créez une instance de serveur et de transport distincte pour chaque session au lieu d’en partager une entre plusieurs clients. Associez chaque session et chaque tâche au principal authentifié qui l’a créée, puis vérifiez cette association à chaque requête. Les deux avis de sécurité du SDK MCP publiés en 2026 provenaient d’un état partagé ou non associé.
Vérifier les skills, plugins et serveurs MCP
Verrouillez les versions exactes, examinez le diff avant chaque mise à jour et vérifiez les résultats des scanners, notamment VirusTotal et l’état de l’audit de sécurité ClawHub. Hachez les descriptions des outils lorsque vous approuvez un serveur et déclenchez une alerte si elles changent : vous détecterez ainsi les rug pulls. OpenClaw ne bloque rien par défaut au moment de l’installation ; configurez donc vous-même security.installPolicy.
Contrôler qui peut envoyer des messages à l’agent
Limitez l’accès par message privé à l’association ou à une liste d’autorisations, exigez une mention avant que l’agent agisse dans les discussions de groupe, et définissez session.dmScope sur per-channel-peer afin que les expéditeurs ne partagent jamais le même contexte. Toute personne pouvant envoyer un message à l’agent peut tenter de lui donner des instructions : la liste des expéditeurs fait donc partie de votre surface d’attaque.
Ne pas exposer de secrets aux exécutions CI non fiables
N’exécutez pas un agent disposant de secrets du dépôt dans des workflows qu’une personne extérieure peut déclencher par une pull request, une issue ou un commentaire. Traitez comme malveillants les titres, descriptions et commentaires associés à ces événements. Si une étape a réellement besoin de secrets, ne l’exécutez qu’après l’approbation de l’exécution par un responsable de la maintenance.
Traiter les sorties du modèle comme non fiables
Encodez ou assainissez les sorties du modèle avant de les afficher, et ne les transmettez jamais sans vérification à un shell, une requête SQL ou un navigateur. Bloquez le chargement automatique des images Markdown et des liens vers des domaines externes, et définissez une Content Security Policy stricte. EchoLeak a exfiltré des données au moyen d’URL qui se chargeaient automatiquement.
Vérifier les signatures des agents, puis les autoriser
Pour identifier un agent qui appelle votre site ou votre API, vérifiez sa signature Web Bot Auth à l’aide des clés que l’opérateur publie dans /.well-known/http-message-signatures-directory. ChatGPT agent signe en tant que Signature-Agent https://chatgpt.com. Une signature valide indique qui exploite l’agent, pas quel utilisateur l’a envoyé ni ce que cet utilisateur est autorisé à faire. Autorisez donc chaque requête séparément.
Questions sur la sécurité des agents
Qu'est-ce qu'une injection de prompt dans les agents IA ?
Le prompt injection est un texte que le modèle traite comme des instructions alors qu'il lui est fourni comme une donnée, par exemple dans une page web, un e-mail ou la description d'un outil. Dans un agent, ces instructions peuvent déclencher des appels d'outils exécutés avec vos identifiants. OWASP le classe sous LLM01:2026, et Agent Goal Hijack (ASI01) couvre sa forme agentique.
Qu'est-ce que le trio infernal des agents IA ?
C'est le terme de Simon Willison pour désigner un agent qui combine l'accès à des données privées, l'exposition à du contenu non fiable et un moyen de communiquer avec l'extérieur. Lorsque ces trois éléments sont réunis, un prompt injection peut lire vos données et les transmettre à l'extérieur. La fuite de jetons MCP de Supabase en 2025 en est un cas d'école.
Comment sécuriser un serveur MCP ?
Refusez les jetons d'accès qui n'ont pas été émis pour votre serveur et ne transmettez jamais le jeton d'un client à une API en amont. Créez une instance de serveur et de transport par session, et associez les sessions et les tâches à l'utilisateur authentifié. Utilisez le SDK TypeScript en version 1.26.0 ou ultérieure et le SDK Python en version 1.27.2 ou ultérieure : ces versions corrigent une fuite de réponses entre clients et le détournement de sessions.
Un meilleur system prompt peut-il empêcher le prompt injection ?
Ne comptez pas dessus. Les recherches sur les modèles de conception des agents concluent qu'une fois qu'un agent a ingéré une entrée non fiable, il faut le contraindre afin que cette entrée ne puisse pas déclencher d'actions lourdes de conséquences. CaMeL, qui applique cette contrainte grâce au suivi des capacités, a résolu 77% des tâches d'AgentDojo avec une sécurité vérifiable, contre 84% pour un agent sans défense.
Quelle est la différence entre l'OWASP LLM Top 10 et l'Agentic Top 10 ?
L'OWASP Top 10 for LLM Applications, dont l'édition 2026 est parue le 4 August 2026, couvre les risques liés à toute application reposant sur un modèle de langage. L'OWASP Top 10 for Agentic Applications, publié le 9 December 2025, couvre les risques qui apparaissent lorsque le modèle planifie, utilise des outils, conserve une mémoire et communique avec d'autres agents. La plupart des développeurs d'agents ont besoin des deux.
Peut-on exposer sans risque une passerelle OpenClaw à Internet ?
Non. Conservez la valeur par défaut de gateway.bind, loopback, et utilisez un tunnel SSH ou Tailscale Serve si vous avez besoin d'un accès à distance. OpenA2A a recensé 192,492 passerelles exposées le 1 September 2026, et CVE-2026-25253 a montré que même les installations limitées à loopback doivent être rapidement mises à jour.