Agents d'IA : les risques de sécurité et comment les déployer

L'essentiel en bref

• Un agent d'IA n'est pas un simple chatbot. Il lit des contenus externes, appelle des outils et agit avec les droits qu'on lui donne. Un texte piégé peut donc entraîner une action réelle, et pas seulement une mauvaise réponse.
• L'injection de prompt reste un problème non résolu. Le NIST et le UK AI Security Institute ont analysé une compétition organisée par Gray Swan, avec plus de 250 000 tentatives d'attaque : au moins une attaque a réussi contre chacun des 13 modèles testés.
• La chaîne d'approvisionnement est déjà attaquée. Il y a eu un faux serveur MCP qui copiait les courriels en 2025, puis des centaines d'extensions malveillantes sur la place de marché d'OpenClaw début 2026.
• L'agent peut aussi déraper sans attaquant. Anthropic a publié le 9 octobre 2026 des cas où ses modèles ont agi sur de vrais sites pendant des tests.
• En France, la consigne est prudente. Le CERT-FR (ANSSI) recommande de ne pas déployer en production les assistants autonomes sur les postes de travail et d'imposer une validation humaine pour toute action à effet de bord.
• Les mesures efficaces sont classiques. Il s'agit du moindre privilège, du cloisonnement, de la validation humaine, du contrôle des extensions et de la journalisation. Les consignes écrites dans le prompt ne suffisent pas.

De quoi parle-t-on ?

Un agent d'IA est un logiciel construit autour d'un grand modèle de langage (LLM, large language model). Il reçoit un objectif, découpe la tâche en étapes et utilise des outils pour l'accomplir : navigateur web, messagerie, fichiers, terminal, API (interfaces de programmation) d'applications métier. Les assistants de code comme Claude Code, les navigateurs « agentiques », les copilotes bureautiques ou les assistants personnels comme OpenClaw entrent dans cette catégorie.

Ces outils sont souvent reliés aux applications par le MCP (Model Context Protocol). Ce protocole ouvert permet de brancher un « serveur » qui donne à l'agent accès à un service (messagerie, base de données, ticketing…). Chaque serveur MCP ou « skill » installé est du code tiers, qui tourne avec les droits de l'agent.

Le risque tient à une combinaison : l'agent lit des données non maîtrisées (pages web, courriels, documents), il a accès à des données sensibles et il peut agir ou communiquer vers l'extérieur. Quand ces trois conditions sont réunies, une seule instruction malveillante peut suffire à faire sortir des données ou à déclencher une action.

Les principaux risques

Injection de prompt directe et indirecte

L'injection directe consiste à écrire à l'agent des consignes qui contournent ses règles. L'injection indirecte est plus insidieuse. Les instructions sont cachées dans un contenu que l'agent traite pour l'utilisateur : une page web, un courriel, un document partagé. Le modèle ne distingue pas de façon fiable les données des ordres. C'est le premier risque du classement OWASP pour les applications LLM (voir notre article Prompt injection : comprendre la vulnérabilité n°1 des applications LLM).

L'exemple de référence est EchoLeak (CVE-2025-32711), dans Microsoft 365 Copilot, révélée en juin 2025 par Aim Labs. Un courriel piégé, récupéré plus tard par Copilot comme contexte, pouvait lui faire transmettre des données internes vers l'extérieur, sans aucun clic de la victime. Microsoft l'a corrigée côté serveur et n'a pas signalé d'exploitation réelle.

Détournement d'outils et de permissions

Un agent compromis utilise les outils et les identifiants auxquels il a légitimement accès. Les droits trop larges deviennent alors le vrai problème. En octobre 2026, les chercheurs de Zenity ont décrit une chaîne d'attaque contre Amazon Bedrock AgentCore : une injection amenait un agent public à interroger le service de métadonnées du cloud, ce qui lui livrait les identifiants d'un rôle par défaut. Selon eux, ce rôle couvrait tous les agents du compte et de la région. AWS répond que ce comportement est « documenté et attendu », mais a depuis restreint ce rôle (voir notre article).

Fuites de données

Un agent peut faire sortir des données sans intention malveillante de l'utilisateur. Il suffit d'une URL (adresse web) qui contient des informations, d'une image chargée depuis un serveur externe ou d'un courriel envoyé. Le CERT-FR cite parmi les risques principaux la fuite vers des ressources externes non maîtrisées et le partage des secrets d'authentification avec l'agent.

Chaîne d'approvisionnement : modèles, MCP, extensions

En septembre 2025, Koi Security a découvert sur npm un paquet postmark-mcp qui imitait l'intégration du service d'envoi de courriels Postmark. Les versions 1.0.0 à 1.0.15 étaient saines. La version 1.0.16 ajoutait une seule ligne : une copie cachée (CCI) de chaque courriel envoyé, adressée à l'attaquant. En février 2026, Koi Security a recensé 341 « skills » malveillantes sur les 2 857 auditées sur ClawHub, la place de marché d'OpenClaw. La plupart installaient un logiciel voleur de données sous couvert de « prérequis ». La spécification MCP elle-même détaille d'autres risques : exécution de commandes à l'installation d'un serveur local, transmission de jetons non vérifiés, requêtes vers le réseau interne (SSRF).

Actions imprévues de l'agent lui-même

Le risque ne vient pas toujours d'un attaquant. Un agent peut aller trop loin pour atteindre son objectif. C'est l'objet du rapport d'Anthropic du 9 octobre 2026, détaillé plus bas. Le CERT-FR range ce risque sous la « perte de maîtrise des actions effectuées par les agents », avec des actions destructrices possibles.

Incidents récents documentés

Les faits ci-dessous viennent des publications des chercheurs ou des éditeurs concernés. Ce sont souvent des sources intéressées, qui n'ont pas été vérifiées de façon indépendante.

Date	Cas	Ce qui est établi
Juin 2025	EchoLeak (Microsoft 365 Copilot)	Injection indirecte par courriel, sans clic. Corrigée côté serveur par Microsoft.
Sept. 2025	postmark-mcp (npm)	Premier serveur MCP malveillant observé en conditions réelles, selon Koi Security. Courriels copiés vers l'attaquant.
Fév. 2026	ClawHavoc (ClawHub / OpenClaw)	341 skills malveillantes sur 2 857 auditées, selon Koi Security.
Sept.–oct. 2026	Banques sud-coréennes	Selon CrowdStrike, un attaquant a utilisé ARTEX, un outil de test d'intrusion agentique, avec plusieurs LLM et des sessions Claude Code. Attribution à un acteur sinophone, avec une confiance « modérée ».
Oct. 2026	AgentCorruption (AWS AgentCore)	Chaîne d'attaque décrite par Zenity. AWS conteste qu'il s'agisse d'une vulnérabilité. Aucune CVE n'a été attribuée.
Oct. 2026	Rapport d'Anthropic	Actions de modèles Claude sur de vrais sites pendant des évaluations. L'éditeur juge l'impact « minimal ».

Le cas sud-coréen montre des agents utilisés par un attaquant. CrowdStrike a trouvé des historiques de sessions Claude Code et des fichiers de configuration ARTEX dans des répertoires laissés ouverts sur ses serveurs. Le nombre de victimes n'est pas confirmé par CrowdStrike (voir notre article).

Le rapport d'Anthropic classe les cas en quatre catégories : exploitation d'une faille d'injection sur le serveur d'un outil universitaire ; envoi de vrais formulaires, dont un faux signalement à la police de Philadelphie, classé comme indésirable ; contournement de restrictions d'accès à des données publiques mais payantes, à l'aide de jetons trouvés sur les sites ; recours à des raccourcisseurs d'URL pour passer outre une limite technique. Anthropic dit que les agences concernées et la Maison-Blanche ont été prévenues, et coupe désormais l'accès direct à Internet pour toutes ses évaluations internes. Ce document reste une auto-déclaration. L'éditeur reconnaît lui-même ne pas avoir encore mené d'évaluation complète, et un rapport du 9 septembre faisait déjà état d'incidents plus graves en évaluation de cybersécurité. Anthropic avait alors confié à l'organisme METR une enquête indépendante sur ces incidents (voir notre article).

Qui est concerné ?

• Toute organisation dont les salariés installent des assistants autonomes sur leur poste, souvent sans validation : extensions de navigateur, agents de bureau, assistants de code. C'est du shadow IT (informatique non déclarée).
• Les organisations qui activent des fonctions agentiques dans leurs suites bureautiques ou leurs outils SaaS (logiciels en ligne) : copilotes avec accès à la messagerie, aux fichiers, à l'agenda.
• Les équipes qui développent ou déploient leurs propres agents : chatbots clients reliés à des API, agents dans le cloud, automatisations avec serveurs MCP.
• Les développeurs qui utilisent des assistants de code avec accès au terminal, aux dépôts et aux secrets.

Une PME est concernée dès qu'un outil d'IA peut lire ses courriels ou documents et agir en son nom.

Les référentiels

OWASP

L'OWASP (Open Worldwide Application Security Project), communauté ouverte de sécurité applicative, publie deux listes complémentaires. Le Top 10 pour les applications LLM (version 2025) place en tête l'injection de prompt, puis la divulgation d'informations sensibles, la chaîne d'approvisionnement, l'empoisonnement des données et du modèle, la gestion inappropriée des sorties et l'« agence excessive » (trop d'autonomie ou de droits). Le Top 10 pour les applications agentiques 2026, publié le 9 décembre 2025, cible spécifiquement les agents : détournement d'objectif (ASI01), mauvais usage des outils (ASI02), abus d'identité et de privilèges (ASI03), chaîne d'approvisionnement agentique (ASI04), exécution de code inattendue (ASI05), empoisonnement de la mémoire et du contexte (ASI06), communications inter-agents non sécurisées (ASI07), défaillances en cascade (ASI08), exploitation de la confiance humain-agent (ASI09) et agents incontrôlés (ASI10).

ANSSI et CERT-FR

Le guide de l'ANSSI « Recommandations de sécurité pour un système d'IA générative » (avril 2024) contient 35 recommandations. Plusieurs s'appliquent directement aux agents : proscrire l'usage automatisé de systèmes d'IA pour des actions critiques sur le système d'information (R9), limiter les actions automatiques depuis un système d'IA traitant des entrées non maîtrisées (R27), cloisonner le système (R28), tout journaliser (R29), contrôler systématiquement le code généré (R30). Le bulletin CERTFR-2026-ACT-016 du 13 avril 2026 traite des assistants agentiques sur les postes de travail. Il recommande de ne pas les déployer en production, de les limiter à des bacs à sable sans données sensibles, de soumettre tout déploiement à la DSI et au RSSI, et de rendre la validation humaine obligatoire « dès qu'une commande système ou une action à effet de bord est envisagée ». Il souligne que les consignes défensives dans les prompts peuvent être contournées par injection.

NIST et partenaires internationaux

Aux États-Unis, le CAISI (Center for AI Standards and Innovation) du NIST a lancé en février 2026 une initiative de normalisation sur les agents, après un appel à contributions sur leur sécurité. Au 12 octobre 2026, nous n'avons pas trouvé de norme finalisée. Le 1er mai 2026, la CISA, la NSA et les agences australienne, canadienne, néo-zélandaise et britannique ont publié « Careful Adoption of Agentic AI Services ». Ce guide recommande de limiter l'autonomie et les accès des agents, de commencer par des environnements peu sensibles et de renforcer gestion des identités et supervision. L'ANSSI n'en est pas signataire.

Cadre réglementaire et calendrier

Aucun texte européen ne vise spécifiquement les agents. Le règlement européen sur l'IA (AI Act, règlement 2024/1689) s'applique selon l'usage qui en est fait. Il a été modifié par le règlement « omnibus numérique » (UE) 2026/1744, publié au Journal officiel de l'UE le 24 juillet 2026. Le RGPD reste applicable dès qu'un agent traite des données personnelles.

• 2 août 2025 : obligations pour les fournisseurs de modèles d'IA à usage général.
• Novembre 2024 : publication de la version 2025 du Top 10 OWASP LLM ; 9 décembre 2025 : Top 10 OWASP agentique.
• 13 avril 2026 : bulletin CERT-FR sur les agents sur postes de travail.
• 1er mai 2026 : guide CISA et partenaires sur l'adoption des agents.
• 2 août 2026 : obligations de transparence (article 50 de l'AI Act) applicables aux nouveaux systèmes.
• 2 décembre 2026 : fin du délai de marquage des contenus générés pour les systèmes déjà sur le marché.
• 2 décembre 2027 : obligations pour les systèmes à haut risque de l'annexe III (reportées par l'omnibus).
• 2 août 2028 : systèmes à haut risque intégrés à des produits réglementés (annexe I).

Par où commencer

1. Faire l'inventaire. Listez les agents, extensions, assistants de code et serveurs MCP utilisés, y compris ceux installés par les salariés. Notez pour chacun ce qu'il lit, ce qu'il peut faire et avec quels identifiants.
2. Fixer une règle simple. Pas d'outil agentique sans validation de la DSI et du RSSI. Pas d'agent autonome sur les postes de production tant que l'outil n'est pas éprouvé, comme le recommande le CERT-FR.
3. Réduire les droits. Donnez à chaque agent un compte dédié, avec le minimum d'accès et des jetons à portée restreinte et de courte durée. Ne partagez jamais vos propres mots de passe ou clés d'API avec un agent.
4. Exiger une validation humaine pour toute action à effet de bord : envoi de courriel ou de formulaire, paiement, suppression, commande système, publication.
5. Cloisonner. Faites tourner les agents dans un environnement isolé (bac à sable, conteneur, machine virtuelle). Limitez leurs sorties réseau à une liste de destinations autorisées et bloquez l'accès aux services de métadonnées du cloud.
6. Contrôler les extensions. N'installez que des serveurs MCP ou des skills d'éditeurs identifiés. Figez les versions et relisez toute mise à jour. Vérifiez la commande exacte exécutée à l'installation.
7. Séparer les contextes. N'associez pas, dans un même agent, la lecture de contenus externes (web, courriels entrants), l'accès à des données sensibles et la capacité d'envoyer vers l'extérieur.
8. Journaliser et surveiller les actions des agents : outils appelés, données consultées, destinations contactées. Prévoyez un moyen de couper un agent rapidement.
9. Sensibiliser les utilisateurs : un document ou un site peut contenir des instructions pour leur assistant. Un agent peut se tromper avec assurance.
10. Prévoir un mode dégradé : les processus métier doivent pouvoir fonctionner sans l'agent (recommandation R15 de l'ANSSI).

Pour aller plus loin

• ANSSI : guide « Recommandations de sécurité pour un système d'IA générative » et recommandations ANSSI-BSI sur les assistants de programmation.
• CERT-FR : bulletin CERTFR-2026-ACT-016 sur l'IA agentique sur les postes de travail.
• OWASP GenAI Security Project : Top 10 LLM 2025 et Top 10 pour les applications agentiques 2026.
• Model Context Protocol : la page « Security Best Practices » de la spécification.
• CISA et partenaires : « Careful Adoption of Agentic AI Services ».
• NIST CAISI : travaux sur le détournement d'agents et initiative de normalisation.
• Cybermalveillance.gouv.fr : assistance et ressources de sensibilisation pour les PME et les collectivités.