Guide

Sécurité des agents IA : risques, référentiels et défenses

Un agent IA lit du texte non fiable, détient des permissions et agit sur des données. Cette page organise ses risques autour de l'OWASP Top 10 for LLM Applications 2025 et de MITRE ATLAS, puis liste les défenses qui tiennent.

Par Florian Bonamy · Mis à jour le 2026-10-29

La sécurité des agents IA désigne l'ensemble des mesures qui empêchent un agent (un modèle de langage capable de lire des contenus, d'appeler des outils et d'agir sur des données) de faire autre chose que ce que son propriétaire a autorisé. Les risques viennent du texte non fiable que l'agent lit, des permissions qu'il détient et de la confiance accordée à ses sorties. Les référentiels de départ sont l'OWASP Top 10 for LLM Applications 2025, les travaux OWASP sur les applications agentiques et la matrice MITRE ATLAS.

Quels sont les principaux risques des agents IA ?

Les dix catégories de l'OWASP Top 10 for LLM Applications 2025 forment le meilleur plan de lecture. Pour un agent qui agit, cinq d'entre elles dominent en pratique.

LLM01, injection de prompt. Un texte reçu par l'agent modifie son comportement. Dans sa forme indirecte, l'instruction est cachée dans un e-mail, un document ou une page web. Voir la page prompt injection et l'article sur l'injection de prompt dans les systèmes RAG.
LLM02, divulgation d'informations sensibles. L'agent révèle des données qu'il a en contexte : données clients, secrets, contenu d'autres sessions. L'article sur les fuites de données des chatbots en donne des exemples.
LLM05, gestion inadéquate des sorties. La sortie du modèle est transmise telle quelle à un navigateur, une base de données ou un interpréteur. Une sortie non validée devient alors une injection classique (XSS, SQL, commande système).
LLM06, agentivité excessive. L'agent dispose de trop d'outils, de trop de droits ou de trop d'autonomie. C'est le multiplicateur de tous les autres risques, parce qu'il détermine l'impact d'une injection réussie.
LLM07, fuite du prompt système. Les instructions internes, parfois assorties de règles métier ou d'identifiants, sont extraites et facilitent l'attaque suivante.

Les cinq autres catégories complètent le tableau : LLM03 (chaîne d'approvisionnement : modèles, bibliothèques, serveurs MCP tiers), LLM04 (empoisonnement des données et du modèle, voir data poisoning et corruption de modèle), LLM08 (faiblesses des vecteurs et des embeddings), LLM09 (désinformation) et LLM10 (consommation non bornée de ressources).

Pourquoi un agent est-il plus risqué qu'un simple chatbot ?

Un chatbot répond ; un agent agit. Dès qu'un modèle peut envoyer un e-mail, modifier un enregistrement, lancer une requête ou déclencher un paiement, une injection réussie ne produit plus seulement une mauvaise réponse : elle produit une action réelle, souvent avec les droits d'un utilisateur légitime.

Trois propriétés expliquent cette aggravation :

Les outils transforment le texte en effets. L'article sur la surface d'attaque du function calling détaille ce passage.
Le contexte mélange confiance et contenu externe. Le modèle ne distingue pas fiablement l'instruction du développeur de l'instruction cachée dans un document.
La chaîne est longue. Un agent s'appuie sur un modèle, un orchestrateur, des plugins, des serveurs MCP et des API. Chaque maillon peut être compromis, comme l'illustrent les incidents de chaîne d'approvisionnement rapportés autour des serveurs MCP, par exemple le ver npm lié à postmark-mcp.

Que disent l'OWASP agentique et MITRE ATLAS ?

L'OWASP prolonge son Top 10 LLM par des travaux consacrés aux applications agentiques, qui traitent des risques propres aux agents : détournement d'objectif, abus d'outils, usurpation d'identité, mémoire empoisonnée, communication entre agents. Un Top 10 spécifique au protocole MCP est également en cours d'élaboration. Les deux documents servent de grille de lecture pour un audit.

MITRE ATLAS est une base de connaissances d'adversaires contre les systèmes d'IA, construite sur le modèle de MITRE ATT&CK. Elle décrit des tactiques et techniques observées ou démontrées, ce qui permet de rattacher un constat à une technique reconnue et de parler le même langage qu'une équipe de détection. Un rapport de red team gagne en crédibilité quand ses constats citent la catégorie OWASP et la technique ATLAS correspondantes.

Que doit vérifier une entreprise avant de mettre un agent en production ?

Une entreprise doit pouvoir répondre par oui à huit questions avant la mise en production.

Inventaire : connaît-on tous les outils de l'agent, leurs permissions et leurs arguments ?
Droits minimaux : chaque outil est-il limité à ce que la tâche exige, en lecture seule quand c'est possible ?
Validation humaine : les actions irréversibles ou sensibles (envoi externe, suppression, paiement) exigent-elles une approbation ?
Contenu non fiable : sait-on d'où vient chaque texte lu par l'agent et le traite-t-on comme non fiable ?
Isolation des clients : un utilisateur ou un tenant peut-il atteindre les données d'un autre par les outils de l'agent ?
Sorties : les sorties du modèle sont-elles validées avant d'atteindre un navigateur, une base ou un autre système ?
Journalisation : chaque appel d'outil est-il tracé avec son déclencheur, ses arguments et son résultat ?
Test offensif : l'agent a-t-il été attaqué par quelqu'un qui n'est pas son concepteur ?

Notre page agent exposé aide à situer un agent sur ces points.

Comment défendre un agent IA en production ?

Les défenses efficaces sont structurelles : elles limitent ce que l'agent peut faire quelle que soit la qualité du modèle. Les consignes écrites dans le prompt aident, mais un attaquant peut les contourner.

Appliquer le moindre privilège aux outils

Donnez à chaque agent uniquement les outils et les droits dont il a besoin, avec des jetons à portée réduite et à durée courte. Un agent de support qui lit des tickets n'a pas besoin d'écrire dans la base clients. Séparez les agents qui lisent du contenu externe de ceux qui détiennent des droits d'écriture.

Exiger une validation humaine sur les actions sensibles

Toute action irréversible, externe ou financière passe par une approbation, avec un affichage clair de l'action réelle (destinataire, montant, données envoyées). Évitez les validations en masse qui conduisent à cliquer sans lire.

Isoler le contenu non fiable

Traitez tout contenu externe comme une donnée et non comme une instruction : balisage clair dans le contexte, traitement dans un agent sans outils sensibles, filtrage des liens et des images rendus dans l'interface (canal de fuite fréquent). Des travaux de recherche comme CaMeL proposent de séparer par conception les instructions de confiance des données non fiables.

Valider les sorties avant usage

La sortie d'un modèle est une entrée non fiable pour le système suivant. Validez les schémas, échappez avant affichage, utilisez des requêtes paramétrées, et ne faites jamais exécuter directement un texte produit par le modèle.

Journaliser et surveiller

Conservez les appels d'outils, les arguments et les identifiants de session, avec des alertes sur les motifs inhabituels : volumes de lecture, nouveaux destinataires, séquences d'outils rares. Sans journaux, un incident ne se reconstitue pas.

Maîtriser la chaîne d'approvisionnement

Fixez les versions des bibliothèques et des serveurs MCP, révisez leurs descriptions d'outils et leurs droits, et surveillez les avis de sécurité. Plusieurs incidents récents ont touché des composants de l'écosystème, comme l'injection de commandes dans un composant LiteLLM ou le détournement d'un agent via un commentaire de pull request.

Quelles failles d'agents observe-t-on le plus souvent en mission ?

Les missions de red team font ressortir des schémas récurrents, dont la plupart ne tiennent pas au modèle lui-même mais à la manière dont l'agent est branché. Voici les plus fréquents.

Écriture sans garde-fou : l'agent enregistre des données personnelles par un appel d'outil sans validation, sans idempotence et sans relecture, de sorte qu'une valeur fausse ou injectée est acceptée.
Lecture sans authentification : une API de lecture située derrière l'agent (relecture d'une session par identifiant, recherche par plaque ou par numéro) répond à n'importe qui, alors que l'agent est censé en être la seule porte.
Isolation par simple paramètre : le client est sélectionné par un paramètre d'URL ou un identifiant sans jeton, ce qui permet d'énumérer les autres.
Garde-fous mous : le modèle refuse de réciter une donnée mais en révèle la longueur, un préfixe ou l'existence, puisque la donnée reste dans son contexte.
Messages d'erreur bavards : une trace d'erreur sur un client inconnu expose des chemins, des bibliothèques ou des noms de stockage.
Affirmations d'actions : l'agent annonce avoir réalisé une action qu'il n'a pas faite, ou l'inverse, ce qui fausse les contrôles humains.

Ces constats se corrigent le plus souvent côté application et droits, avant même de toucher au prompt. C'est pourquoi un test d'agent inclut l'application hôte dans son périmètre de preuve. La page red teaming d'agent IA décrit le déroulé d'une mission.

Comment rattacher chaque risque à une réponse concrète ?

Chaque risque OWASP se traite par un petit nombre de contrôles. Cette correspondance sert de feuille de route pour une équipe qui démarre.

LLM01 injection de prompt : isoler le contenu non fiable, limiter les outils accessibles pendant le traitement d'un contenu externe, valider les actions sensibles.
LLM02 divulgation d'informations : ne placer dans le contexte que les données nécessaires à la requête en cours, et filtrer les canaux de sortie.
LLM03 chaîne d'approvisionnement : épingler les versions, relire les descripteurs d'outils MCP, suivre les avis de sécurité.
LLM04 empoisonnement : contrôler la provenance des données d'entraînement, de réglage fin et des documents indexés.
LLM05 sorties : valider et échapper avant tout usage par un autre système.
LLM06 agentivité excessive : droits minimaux, autonomie bornée, approbation humaine.
LLM07 prompt système : ne pas y placer de secret, et supposer qu'il sera lu.
LLM08 vecteurs et embeddings : cloisonner les index par client et appliquer les droits d'accès à la récupération.
LLM09 désinformation : exiger des sources vérifiables avant toute action qui dépend d'une affirmation du modèle.
LLM10 consommation non bornée : quotas, plafonds de coût, limites de boucles d'outils.

Pour la lecture détaillée de chaque catégorie, voir le guide OWASP LLM 2026 et l'article sur les applications générées par IA.

Garde-fous de prompt ou contrôles structurels : que choisir ?

Les deux se combinent, mais ils n'offrent pas le même niveau d'assurance.

Garde-fous de prompt (consignes, classifieurs, filtres) : faciles à déployer, utiles contre les cas courants, contournables par reformulation. Ils réduisent la probabilité d'un abus sans en borner l'impact.
Contrôles structurels (droits minimaux, validation humaine, isolation, listes d'actions autorisées) : plus coûteux à concevoir, indépendants du modèle, ils bornent l'impact même quand l'injection réussit.
Surveillance et journalisation : ne préviennent rien, mais permettent de détecter et de reconstituer. Indispensables dans les deux cas.
Test offensif : mesure l'écart réel entre l'intention et le comportement. C'est le seul moyen de savoir lesquels de ces contrôles tiennent.

Comment tester la sécurité d'un agent IA ?

Un test sérieux attaque l'agent comme le ferait un inconnu : dépôt d'instructions dans les sources que l'agent lit, tentatives d'abus d'outils, extraction de données, sortie de périmètre entre clients. Les benchmarks de recherche comme InjecAgent et AgentDojo montrent que cette évaluation doit porter sur l'agent complet, avec ses outils réels, car le modèle isolé donne une image trop optimiste.

CleanIssue réalise ce test en mission : le Red Team Agent Express à 1 900 € en 5 jours pour un agent, ou un red team sur mesure sur devis pour un périmètre plus large. Pour les agents qui exposent des serveurs MCP, la page sécurité MCP détaille les points de contrôle. La méthode décrit le déroulé complet.

Où en est le Shield de CleanIssue ?

Le Shield est la couche logicielle prévue entre l'agent qui propose une action et le système qui l'autorise, pour bloquer les actions non autorisées. Il est en développement et n'est pas disponible aujourd'hui. D'ici là, les contrôles ci-dessus se mettent en place avec l'orchestrateur, les API et les droits que vous maîtrisez déjà.

Pour aller plus loin

Commencez par un rendez-vous découverte de 30 minutes, gratuit, pour situer votre agent par rapport à ces risques. Les définitions des termes se trouvent dans le glossaire, et les tarifs sur la page tarifs.

Questions fréquentes

Quels sont les principaux risques de sécurité d'un agent IA ?

Injection de prompt (surtout indirecte), divulgation d'informations sensibles, gestion inadéquate des sorties, agentivité excessive et fuite du prompt système, auxquels s'ajoutent la chaîne d'approvisionnement, l'empoisonnement de données, les faiblesses des embeddings, la désinformation et la consommation non bornée, selon l'OWASP Top 10 for LLM Applications 2025.

Pourquoi un agent est-il plus risqué qu'un chatbot ?

Un chatbot répond, un agent agit. Avec des outils, une injection réussie produit une action réelle (envoi, modification, paiement), souvent avec les droits d'un utilisateur légitime.

Comment se protéger d'une injection de prompt ?

Aucune consigne de prompt ne suffit seule. Combinez des droits minimaux, la validation humaine des actions sensibles, l'isolation du contenu non fiable, la validation des sorties et la journalisation, puis vérifiez le tout par un test offensif.

Qu'est-ce que l'agentivité excessive ?

C'est la catégorie LLM06 de l'OWASP : l'agent dispose de trop d'outils, de trop de droits ou de trop d'autonomie. Elle détermine l'impact d'une injection réussie, donc réduire les droits est l'une des mesures les plus rentables.

Que sont MITRE ATLAS et l'OWASP agentique ?

MITRE ATLAS est une base de connaissances des tactiques et techniques d'adversaires contre les systèmes d'IA, sur le modèle d'ATT&CK. Les travaux OWASP sur les applications agentiques traitent des risques propres aux agents : détournement d'objectif, abus d'outils, mémoire empoisonnée, communication entre agents.

Les garde-fous de prompt suffisent-ils ?

Non. Ils réduisent la probabilité d'un abus sans en borner l'impact, et peuvent être contournés par reformulation. Les contrôles structurels (droits, validation, isolation) bornent l'impact même quand l'injection réussit.

Comment tester la sécurité de mon agent IA ?

Par un red team : on attaque l'agent complet avec ses outils réels, depuis la position d'un inconnu qui dépose du texte dans ses sources. CleanIssue propose le Red Team Agent Express à 1 900 € en 5 jours, ou un red team sur mesure sur devis.

Le Shield de CleanIssue est-il disponible ?

Non. Le Shield, couche logicielle destinée à bloquer les actions non autorisées entre l'agent et ses outils, est en développement. Les défenses décrites sur cette page se mettent en place dès maintenant avec vos propres moyens.