Checklist sécurité d'un agent IA avant production

Pourquoi une checklist propre aux agents IA ?

Parce qu'un agent n'est pas un chatbot : il appelle des outils, lit des données et agit sans que vous validiez chaque étape. Le risque change de nature, puisqu'une réponse erronée devient une action erronée.

L'OWASP définit l'Excessive Agency (LLM06:2025) comme la vulnérabilité qui permet des actions dommageables en réponse à des sorties inattendues, ambiguës ou manipulées du modèle, quelle que soit la cause (hallucination ou injection de prompt). La checklist ci-dessous traduit ce principe en points vérifiables. Elle complète, sans le remplacer, un test d'intrusion complet de l'agent.

Comment l'utiliser : pour chaque point, notez OK, À corriger ou Sans objet, avec la preuve (capture, ligne de configuration, extrait de journal). Un point sans preuve est un point non vérifié.

Quels sont les 20 points à vérifier ?

Voici la checklist complète. Les points marqués Bloquant doivent être résolus avant toute mise en production.

Les sections suivantes expliquent le raisonnement derrière chaque famille.

Que vérifier sur le périmètre et les permissions (points 1 à 5) ?

Vérifiez que l'agent ne peut faire que ce que son cas d'usage exige. L'OWASP distingue trois causes d'Excessive Agency : trop de fonctionnalités, trop de permissions, trop d'autonomie. Les points 1 à 5 traitent les deux premières.

Un test simple : listez les outils et, pour chacun, écrivez la phrase « l'agent en a besoin pour… ». Ceux dont vous ne trouvez pas la phrase sont à retirer. Préférez des outils étroits (« créer un brouillon de réponse ») à des outils ouverts (« envoyer un e-mail à n'importe qui »). Pour les agents reliés à des serveurs MCP, appliquez la même logique à chaque serveur : notre page sécurité MCP détaille les risques.

Que vérifier sur les entrées (points 6 à 10) ?

Vérifiez que tout contenu que l'agent lit mais que vous ne maîtrisez pas est traité comme hostile. C'est le terrain de l'injection de prompt indirecte, décrite sur notre page injection de prompt.

Le point 10 est facile à oublier : le test se limite parfois au champ de saisie du chat sans couvrir l'e-mail, la page web ou le document que l'agent traite en arrière-plan. Le point 9 mérite aussi une attention : un RAG qui indexe tous les documents sans filtre par habilitation expose des données à tout utilisateur qui pose la bonne question.

Que vérifier sur les sorties (points 11 à 14) ?

Vérifiez que ce que produit le modèle ne peut ni attaquer un autre composant ni faire sortir des données. L'OWASP (LLM05:2025, Improper Output Handling) demande de traiter le modèle comme un utilisateur non fiable et de valider sa sortie avant qu'elle atteigne une fonction en aval.

Concrètement : encodage selon le contexte (HTML, SQL), requêtes paramétrées, politique de sécurité de contenu (CSP) stricte dans l'interface, et refus de charger des images ou liens externes générés par le modèle. Sur le point 14, l'OWASP rappelle que le prompt système ne doit pas être traité comme un secret ni comme un contrôle de sécurité.

Que vérifier sur la validation humaine (points 15 et 16) ?

Vérifiez qu'aucune action irréversible ne s'exécute sans accord explicite d'une personne, et que les plafonds sont codés en dur. Une règle écrite dans le prompt (« ne rembourse jamais plus de 50 € ») peut être contournée ; une vérification dans l'API de remboursement ne le peut pas.

Veillez à ce que l'approbation soit informée : la personne doit voir l'action exacte (destinataire, montant, contenu), pas un résumé rédigé par le modèle. Sinon, l'attaquant peut manipuler le résumé.

Que vérifier sur l'observabilité et l'exploitation (points 17 à 20) ?

Vérifiez que vous saurez détecter, comprendre et arrêter un détournement. Sans journal des appels d'outils, vous ne pourrez pas reconstituer ce qui s'est passé. L'OWASP recommande la journalisation et la limitation de débit comme mesures de réduction des dégâts.

Testez l'interrupteur d'arrêt avant d'en avoir besoin : qui peut couper l'agent, en combien de temps, et comment révoquer les jetons qu'il détient ? Une procédure jamais essayée est une procédure qui échouera le jour de l'incident.

Dans quel ordre traiter les écarts ?

Commencez par les points bloquants qui touchent aux permissions et à la validation humaine (1, 2, 3, 15, 16), car ils réduisent l'impact de toutes les autres failles. Une injection réussie contre un agent sans droits dangereux produit peu de dégâts.

Traitez ensuite les entrées (6 à 10) et les sorties (11 à 14), puis l'observabilité. Refaites la checklist à chaque ajout d'outil, de source de données ou de changement de modèle, et conservez les preuves : elles servent aussi lors d'un audit client ou d'un questionnaire de sécurité.

Comment passer de la checklist au test réel ?

La checklist vérifie la conception ; un test adverse vérifie qu'elle tient face à quelqu'un qui cherche la faille. Après les 20 points, faites attaquer l'agent par des scénarios réels : contenu piégé, tentative de sortie de périmètre, abus d'outil.

Notre Red Team Agent Express (1 900 €, 5 jours) couvre précisément cette étape pour un agent. Pour plusieurs agents ou une livraison en marque blanche par une agence, voyez le test d'intrusion d'agent IA. La logique d'ensemble est présentée sur notre page red team d'agents IA.