Auditer un agent IA : comprendre les failles, mener l'audit

Les agents IA sont passés en production. Ils répondent à vos clients, lisent vos documents, écrivent dans vos bases et appellent vos API. Et comme toute brique qui agit sur le système, ils s'auditent.

Le sujet s'est structuré très vite. En décembre 2025, l'OWASP a publié son premier Top 10 dédié aux applications agentiques, en complément du Top 10 LLM. En mars 2026, OpenAI a racheté Promptfoo, un outil de test de sécurité IA, pour renforcer ses propres agents. Tester un agent avant de l'exposer n'est plus optionnel.

Cet article suit deux fils. La théorie d'abord : pourquoi un agent élargit la surface d'attaque, le détail des familles de failles, et les référentiels. La pratique ensuite : cadrer un audit, monter un banc de test, manier l'outillage et sa configuration, et produire un rapport crédible. Il décrit ce qu'on teste et comment s'en protéger ; il ne fournit pas de quoi mener une attaque.

Pourquoi un agent élargit la surface d'attaque

Un chatbot produit du texte. Un agent, lui, boucle : il réfléchit, agit à l'aide d'outils, observe, recommence. Cette boucle lui donne du pouvoir, et c'est ce pouvoir qui crée le risque. Pire, la boucle amplifie : une seule observation piégée empoisonne l'action suivante, qui empoisonne la décision d'après. Quatre zones d'exposition apparaissent, qu'un simple modèle n'a pas.

Les entrées. Un agent ne lit pas que la question de l'utilisateur. Il lit des mails, des pages web, des tickets, des réponses d'API. Chacun peut contenir une instruction cachée. La frontière entre donnée à traiter et ordre à exécuter devient floue.

Les outils et connecteurs. Un agent utile est connecté : messagerie, bases, dépôts, serveurs MCP. Chaque outil est une porte. Un outil mal borné, ou un serveur tiers compromis, donne un accès direct au cœur du système.

La mémoire et le contexte. Beaucoup d'agents gardent une mémoire entre sessions, ou s'appuient sur une base documentaire (RAG). Une information piégée qui s'y installe oriente durablement les décisions, bien après le moment où elle a été plantée.

L'identité et les droits. C'est l'angle mort le plus fréquent. L'agent agit avec des droits qu'on lui prête : compte partagé, jeton fourre-tout. Sans identité propre ni journal dédié, impossible de prouver qui a fait quoi, l'agent ou la personne.

Les référentiels

Trois référentiels publics structurent le domaine. Ils servent de grille de lecture et de langage commun avec un RSSI. Ils décrivent les catégories de failles, pas la façon de les exploiter.

OWASP Top 10 for LLM Applications (2025) couvre les applications à base de LLM, agent ou non.

OWASP Top 10 for Agentic Applications (décembre 2025) est dédié aux agents : autonomie, outils, mémoire, coopération entre agents.

MITRE ATLAS est la base de connaissances des tactiques et techniques d'attaque contre l'IA, l'équivalent d'ATT&CK. Sa première mise à jour 2026 a ajouté des techniques agentiques : abus d'API de service, collecte d'identifiants via les outils d'un agent, empoisonnement des données d'un outil, destruction de données par invocation d'outil. Un rapport sérieux rattache chaque constat à l'une de ces références : c'est ce qui le rend comparable et actionnable.

Les failles en détail

Les tableaux sont la carte. Voici les mécanismes des familles qui pèsent le plus dans un audit d'agent, et pour chacune la défense associée. On reste au niveau du principe : comprendre pourquoi ça marche, et comment fermer la porte.

Injection de prompt, directe et indirecte. La directe passe par l'utilisateur. L'indirecte, plus dangereuse pour un agent, se cache dans un contenu qu'il lit sans méfiance : un mail, une page, un ticket, la sortie d'un outil. Le modèle ne distingue pas structurellement une donnée à lire d'un ordre à suivre ; une phrase bien placée devient une instruction. Défense : traiter toute sortie d'outil et tout contenu externe comme non fiables, cloisonner le prompt système, exiger une confirmation humaine sur les actions sensibles.

Autonomie excessive et mauvais usage des outils. L'agent dispose souvent de plus d'outils, de droits et de liberté que la tâche ne l'exige. Un attaquant détourne un outil légitime vers une fin nuisible, ou enchaîne plusieurs outils sûrs en une séquence qui ne l'est plus. Défense : moindre privilège par outil, bornage strict des paramètres, validation humaine sur ce qui écrit, paie, supprime ou envoie à l'extérieur.

Empoisonnement de la mémoire et du contexte (RAG). Une information fausse ou piégée plantée dans la mémoire ou la base documentaire oriente les décisions bien après l'injection, et pour les utilisateurs suivants. Défense : cloisonner la mémoire par client et par session, TTL, valider et signer les sources, ne pas réinjecter l'historique aveuglément.

Abus d'identité et de privilèges. L'agent agit avec des identifiants prêtés, surdimensionnés et persistants ; un agent détourné atteint bien plus que sa tâche. Défense : identité propre à l'agent, jetons à portée minimale et courte durée, journal distinguant l'agent de l'humain.

Communication inter-agents et défaillances en cascade. Quand plusieurs agents coopèrent, des messages non authentifiés permettent d'en usurper un ; une décision compromise se propage à toute la chaîne. Défense : authentifier les échanges entre agents, borner la confiance, prévoir des coupe-circuits.

Divulgation de données et fuite du prompt système. L'agent révèle les données d'un autre client, des documents internes, ou son propre prompt système. Défense : filtrage des sorties, cloisonnement strict des données, aucun secret dans le prompt système.

Hallucination métier et complaisance. L'agent produit une réponse plausible mais fausse sur le cœur de métier, ou valide une affirmation erronée de l'utilisateur. Défense : ancrage sur des sources vérifiées, garde-fous sur les affirmations à enjeu, tests de non-régression métier.

Où l'audit s'inscrit dans l'AI Act

Le cadre a bougé en 2026. Le Digital Omnibus sur l'IA, publié au Journal officiel le 24 juillet 2026 (règlement UE 2026/1744), a reporté les obligations sur les systèmes à haut risque : annexe III au 2 décembre 2027, annexe I au 2 août 2028.

Ce report ne vide pas le sujet. La transparence (article 50) s'applique bien à partir du 2 août 2026 : l'utilisateur doit savoir qu'il parle à une IA, et les contenus générés doivent être marqués. La littératie IA (article 4) reste exigible : former les équipes qui déploient et utilisent ces systèmes.

Un audit de sécurité n'est pas imposé nominativement, mais il alimente la documentation attendue : démontrer qu'on a identifié et traité les risques d'un système qui agit sur des données et des personnes. Pour un futur système haut risque, c'est une brique de la gestion des risques exigée à l'échéance.

Cadrer l'audit

La pratique commence bien avant le premier test. Un audit mal cadré est au mieux inutile, au pire un incident.

L'autorisation écrite est non négociable. Tester un agent, c'est tenter de le détourner : sans mandat signé définissant périmètre et fenêtre d'intervention, l'exercice est une intrusion.

Le périmètre. Quelle interface, quels outils, quels comptes. On liste ce qui est hors champ : production critique, données réelles de clients, actions irréversibles (paiement, suppression, envoi externe).

L'environnement. On teste sur un environnement dédié, isolé de la production, avec des données factices et des comptes jetables. Les actions déclenchées ne doivent atteindre ni vrais clients ni vrais systèmes. Toute la session est journalisée et rejouable, et un coupe-circuit permet d'arrêter l'agent à tout moment.

Les comptes de test. Pour tester le contrôle d'accès et les IDOR, il faut plusieurs comptes de rôles différents. C'est la seule façon de vérifier qu'un agent ne franchit pas les cloisons entre clients ou entre niveaux de privilège.

Le déroulé en cinq étapes

Une mission suit toujours la même charpente. C'est cette discipline, pas la puissance de l'outil, qui fait la différence entre un audit sérieux et une série de tests au hasard.

1. Cadrage : périmètre, autorisation, comptes de test, budget de temps.
2. Reconnaissance : comprendre l'agent. Quels outils, quels rôles, quelles données, quels parcours.
3. Tests : une passe automatisée large, puis des tests manuels sur les pistes intéressantes.
4. Vérification : chaque trouvaille est rejouée. Une faille qu'on ne sait pas reproduire n'entre pas dans le rapport.
5. Rapport : constats prouvés, classés par impact, avec un plan de correction.

Les outils en détail

Quatre outils libres couvrent l'essentiel de la passe automatisée. Aucun ne remplace le jugement : ils déroulent des batteries de cas connus, à vous de trier, vérifier et compléter à la main. On ne les lance que contre son propre endpoint de test, dans l'environnement isolé défini au cadrage.

garak (NVIDIA) raisonne en trois briques : un générateur (la cible, par exemple votre endpoint REST), des sondes qui envoient des familles de cas connus, et des détecteurs qui jugent les réponses. On pointe garak sur un endpoint HTTP de test via un fichier rest.json, on liste les familles avec --list_probes, puis on lance :

# rest.json : pointer garak sur votre endpoint de test
{
  "rest.RestGenerator": {
    "uri": "https://agent-de-test.interne/chat",
    "method": "post",
    "headers": { "Authorization": "Bearer $TOKEN_TEST" },
    "req_template_json_object": { "message": "$INPUT" },
    "response_json": true,
    "response_json_field": "reply"
  }
}

# lister les familles de sondes, puis lancer
garak --list_probes
python -m garak --target_type rest -G rest.json

PyRIT (Microsoft) est une boîte à outils plus bas niveau, pensée pour les scénarios élaborés. On compose une cible, des convertisseurs (qui transforment la forme des entrées), des scoreurs (qui évaluent les réponses) et des orchestrateurs (qui pilotent le déroulé, y compris sur plusieurs tours). C'est l'outil des tests multi-tours, là où une mise en condition progressive révèle ce qu'un test en un coup manque.

promptfoo (open source, racheté par OpenAI en mars 2026) fonctionne par campagne décrite dans un fichier de config : une cible, un purpose qui décrit l'agent, des plugins qui sont des catégories de vulnérabilités à couvrir, et des stratégies. Il génère les cas, interroge la cible et produit un rapport.

# promptfooconfig.yaml
targets:
  - id: https
    label: agent-de-test
    config:
      url: https://agent-de-test.interne/chat
      method: POST
      headers: { Authorization: 'Bearer $TOKEN_TEST' }
      body: { message: '{{prompt}}' }
redteam:
  purpose: "Assistant support, acces catalogue et comptes de test"
  plugins:
    - pii               # fuite de donnees personnelles
    - bola              # acces a l objet d un autre utilisateur (IDOR)
    - bfla              # fonction reservee a un autre role
    - rbac              # controle d acces par role
    - excessive-agency  # autonomie excessive

# generer, executer et consulter le rapport
npx promptfoo@latest redteam run
npx promptfoo@latest redteam report

Giskard (français, open source, version 3) est orienté qualité et sécurité des agents : on écrit des checks (assertions, du simple prédicat au juge LLM) et des scénarios multi-tours qui s'arrêtent au premier échec. Pratique pour verrouiller des garde-fous métier et les rejouer en non-régression.

L'installation de chaque outil tient en une ligne :

# garak (NVIDIA, Apache 2.0)
python -m pip install -U garak

# PyRIT (Microsoft, MIT)
pip install pyrit

# promptfoo (OpenAI, open source)
npx promptfoo@latest redteam init

# Giskard (France, open source, v3)
pip install giskard-checks

La cible, dans chaque cas, est l'URL ou l'API de votre agent de test. Le catalogue précis des cas se consulte dans la documentation de chaque outil : c'est là que vit le détail. Depuis le rachat de promptfoo par OpenAI, la partie open source reste maintenue : ces outils entrent dans l'outillage standard.

La matrice de test

Relier chaque famille de faille à ce qu'on vérifie, comment, et à la défense attendue : c'est le cœur méthodique d'un audit, et ce qui rend le rapport lisible.

Deux principes gouvernent cette matrice. D'abord, le multi-tours : beaucoup de garde-fous tiennent au premier message et cèdent après une mise en condition progressive ; un audit sérieux teste la conversation, pas seulement le prompt. Ensuite, la vérification humaine : l'outil propose, l'auditeur dispose. Une alerte non rejouée n'est pas une faille, c'est une hypothèse.

Le rapport et la priorisation

Un audit ne vaut que par son rapport. C'est le seul livrable que lit le client, et c'est là que se joue la crédibilité.

Chaque constat porte une preuve rejouable, une gravité justifiée par un scénario d'impact et non par la catégorie, un rattachement à l'OWASP et à MITRE ATLAS, et une remédiation concrète. La priorisation suit l'impact métier réel.

Modèle de rapport

Structure d'un livrable exploitable :

1. Résumé exécutif : verdict go / no-go, risques majeurs, en une page
2. Périmètre et autorisation : ce qui a été testé, le mandat, la fenêtre
3. Synthèse des constats : tableau par gravité
4. Détail par constat : identifiant, famille OWASP/ATLAS, preuve rejouable, scénario d'impact, gravité, remédiation
5. Plan de remédiation priorisé : par impact, avec effort estimé
6. Retest : vérification des corrections critiques

Le rapport se clôt sur un verdict lisible par une direction, et un retest valide que les failles critiques sont fermées. C'est exactement la démarche d'un Crash-test IA : on ne cherche pas à impressionner par un nombre de trouvailles, on prouve ce qui compte et on dit comment le corriger.

Testez vos acquis

Lexique