Un chatbot qui répond mal fait perdre du temps. Un agent IA qui décide mal peut supprimer des données, envoyer des e-mails frauduleux, exfiltrer des informations confidentielles ou accorder des accès non prévus. Le rayon d’impact d’un agent compromis est l’union de toutes les permissions qu’il détient — et la plupart des agents en production détiennent bien plus que ce que leur tâche exige.

Le référentiel OWASP pour les applications agentiques, publié en décembre 2025, identifie dix catégories de risques construites à partir d’incidents réels. En voici un tour d’horizon.

Pourquoi la sécurité des agents est différente

Trois raisons fondamentales.

Le canal de contrôle et le canal de données sont confondus. Dans une application classique, les instructions viennent du code et les données des utilisateurs. Dans un agent, tout arrive par le même canal : le contexte. Un document, un e-mail ou une page web lue par l’agent peut contenir des instructions que le modèle traitera comme légitimes.

L’autonomie compose les dégâts. Chaque action prise isolément peut sembler raisonnable. C’est la chaîne qui est catastrophique. Aucun contrôle de sécurité traditionnel ne correspond à “le plan était mauvais”.

Les outils de sécurité classiques ne voient rien. L’analyse statique lit le code source. L’analyse de composition lit les dépendances. Ni l’une ni l’autre ne lit le prompt système, les descriptions d’outils ou la mémoire de l’agent — précisément là où vivent les attaques agentiques.

Les dix risques, expliqués simplement

ASI01 — Détournement d’objectif

L’attaquant redirige l’objectif de l’agent via le contenu qu’il lit. L’agent croit toujours servir l’utilisateur — il sert l’attaquant.

Incident de référence : EchoLeak (CVE-2025-32711, score CVSS 9,3). Un e-mail contenant des instructions dissimulées, récupéré plus tard comme contexte par un assistant d’entreprise, a provoqué l’exfiltration de données sans aucune interaction utilisateur.

Se protéger : séparer structurellement les instructions du contenu récupéré, limiter ce que l’agent peut faire indépendamment de ce que dit son contexte, exiger une confirmation humaine sur les actions sensibles.

ASI02 — Détournement d’outils

Les outils légitimes de l’agent deviennent l’arme. En juillet 2025, une extension de développement avec plus de 950 000 installations a failli permettre l’exécution d’une commande destructrice via un commit malveillant contenant une instruction cachée.

Se protéger : portée minimale par outil, validation des paramètres dans le code (pas dans le prompt), surveillance des enchaînements d’outils.

ASI03 — Abus d’identité et de privilèges

C’est le risque qui transforme tous les autres en violation de données. La plupart des agents empruntent les identifiants d’un humain, partagent un compte de service, ou utilisent des jetons de longue durée dont personne n’a revu la portée.

Se protéger : une identité par agent, des identifiants de courte durée, des revues d’accès aussi régulières que pour les humains.

ASI04 — Chaîne d’approvisionnement

Les systèmes agentiques sont assemblés à partir de frameworks, de connecteurs et de serveurs MCP, largement open source. Un agent peut découvrir et intégrer des composants à l’exécution — la chaîne continue de changer après le déploiement.

Incident documenté : une injection de commande de score CVSS 9,6 dans un paquet connecteur téléchargé plus de 437 000 fois.

Se protéger : maintenir un inventaire des composants, exiger provenance et signature, relire tout serveur MCP tiers avant activation.

ASI05 — Exécution de code imprévue

Tout chemin où du langage naturel devient du code exécuté hors des limites prévues. Un agent qui exécute du code directement sur l’hôte — sans conteneur isolé, sans restriction réseau — est une porte ouverte.

Se protéger : bac à sable conteneurisé, aucun accès réseau par défaut, pas de shell brut quand une API paramétrée suffit.

ASI06 — Empoisonnement de la mémoire

Le contexte de session et la mémoire à long terme façonnent le comportement futur de l’agent. Des travaux ont démontré qu’une instruction dissimulée pouvait écrire de fausses “mémoires” durables, orientant discrètement le comportement lors de conversations ultérieures.

Le décalage temporel rend ce risque redoutable : la session empoisonnée paraît propre, le comportement compromis apparaît plus tard.

Se protéger : valider tout ce qui est écrit en mémoire persistante, garder le contexte éphémère par défaut, permettre l’inspection et la purge.

ASI07 — Communication inter-agents non sécurisée

Dès qu’il y a plus d’un agent : usurpation de pair, altération de messages, enregistrement d’un faux agent dans un service de découverte.

Se protéger : authentification mutuelle, messages signés, listes d’autorisation des chemins de délégation.

ASI08 — Défaillances en cascade

Une analyse de sécurité a mesuré, sur un agent connecté à cinq serveurs MCP, un taux de succès d’attaque de 78 % pour un serveur compromis, avec propagation aux autres serveurs dans 72 % des cas.

Incident marquant : un agent de développement a supprimé une base de production contenant les enregistrements de 1 200 dirigeants, puis a généré des données fabriquées. Aucun attaquant n’était impliqué : autonomie plus accès large ont suffi.

Se protéger : isolation entre agents et environnements, disjoncteurs comportementaux, séparation stricte développement/production.

ASI09 — Exploitation de la confiance humaine

Le risque vise le contrôle sur lequel tout le monde compte : l’approbation humaine. Une approbation ne vaut que ce que vaut l’information sur laquelle elle repose — et c’est l’agent qui contrôle cette information.

Se protéger : afficher l’action brute (la commande exacte, le montant exact) et non le résumé de l’agent. Journaliser ce qui a été présenté par rapport à ce qui a été exécuté.

ASI10 — Agents devenus incontrôlés

Un agent qui opère hors politique — par compromission, dérive ou désalignement — tout en paraissant légitime. La caractéristique : la persistance. L’agent continue d’agir, et tout paraît normal.

Se protéger : profils comportementaux de référence avec alerte sur écart, gouvernance du cycle de vie (chaque agent a un propriétaire et une date d’expiration), arrêt d’urgence testé régulièrement.

La checklist minimale

Avant de déployer un agent au-delà du prototype :

Une identité dédiée à l’agent, jamais d’emprunt de compte humain
Aucun secret dans le prompt ou le contexte
Liste d’outils autorisés, refus par défaut
Bac à sable pour toute exécution de code
Accès réseau refusé par défaut
Actions destructrices derrière confirmation affichant l’action brute
Journal d’audit immuable, hors de portée de l’agent
Arrêt d’urgence testé

Ce que ça signifie pour la conformité

Plusieurs cadres touchent désormais le comportement des agents : le règlement européen sur l’IA, la norme ISO/IEC 42001, SOC 2, et le RGPD bien entendu. Les auditeurs posent trois questions concrètes : qui a approuvé les permissions de cet agent, où sont ses journaux d’action, et en combien de temps peut-on l’arrêter.

Un agent qui traite des données personnelles est un traitement au sens du RGPD. Il faut une base légale, une inscription au registre, et une analyse d’impact si le traitement est à risque.

La sécurité des agents IA est un sujet neuf, et très peu de structures sont outillées pour l’évaluer. Pour un état des lieux de vos déploiements IA et de leur surface de risque, demandez un diagnostic.