Injection indirecte par une source
Une instruction est cachée dans un email, un PDF, une page web, un ticket ou la sortie d’un outil que l’agent consulte comme une donnée légitime.
AUDIT DE SÉCURITÉ AGENT IA
Un audit de sécurité d’agent IA détermine si une entrée manipulée peut atteindre une donnée, abuser d’une permission ou déclencher une action non autorisée. Il couvre le modèle, mais aussi l’orchestrateur, la mémoire, les outils, les API, les identités techniques et les contrôles humains.
Un chatbot produit principalement une réponse. Un agent IA peut en plus choisir une étape, consulter une source, appeler une fonction, modifier un enregistrement, envoyer un message ou déléguer une tâche. Cette capacité d’action augmente le rayon d’impact d’une erreur ou d’une manipulation.
Selon l’OWASP AI Agent Security Cheat Sheet, la sécurité d’un agent doit couvrir ses outils, sa mémoire, son identité, ses communications et sa supervision. Tester uniquement la réponse textuelle du modèle laisse donc de côté l’essentiel de l’architecture.
| Composant | Question de sécurité | Impact possible |
|---|---|---|
| Outil | L’agent peut-il appeler une fonction sans validation suffisante ? | Envoi, modification ou suppression non autorisée. |
| Permission | L’identité technique possède-t-elle plus de droits que nécessaire ? | Accès à des données ou opérations hors périmètre. |
| Mémoire | Une entrée peut-elle influencer durablement les sessions futures ? | Empoisonnement du comportement ou élévation de privilège logique. |
| Délégation | Un agent pair ou distant est-il considéré comme une source fiable ? | Propagation d’instructions hostiles entre agents. |
| Sortie | Le résultat du modèle est-il exécuté ou rendu sans validation ? | SSRF, injection, XSS, commande dangereuse ou fuite externe. |
Une instruction est cachée dans un email, un PDF, une page web, un ticket ou la sortie d’un outil que l’agent consulte comme une donnée légitime.
L’agent est amené à utiliser une fonction autorisée dans un but non prévu : transfert de données, modification d’un compte ou appel vers une destination hostile.
Le compte utilisé par l’agent possède trop de fonctions, trop de droits ou trop d’autonomie. L’OWASP regroupe ces causes sous le risque d’« excessive agency ».
Une information contrôlée par l’attaquant est conservée comme préférence, règle ou fait de confiance et modifie ensuite les décisions d’une autre session.
Un utilisateur sans privilège pousse l’agent, qui dispose d’une identité plus puissante, à accomplir une opération que l’utilisateur ne pourrait pas réaliser directement.
Une instruction hostile franchit plusieurs délégations, profite de frontières de confiance mal définies puis atteint un agent ayant davantage de permissions.
Le périmètre recense les modèles, instructions, mémoires, outils, schémas de fonctions, API, comptes techniques, sources externes et agents pairs. Chaque capacité est associée à son niveau de privilège et à son effet réel.
L’audit distingue les entrées fiables des contenus non fiables : utilisateur, document importé, résultat de recherche, message reçu, réponse d’un outil ou consigne d’un autre agent. Une donnée externe ne doit jamais acquérir automatiquement le statut d’instruction.
Les tests combinent prompt injection, variations multi-tours, contenus indirects, paramètres d’outils et séquences d’action. Les limites sont fixées par écrit : comptes de test, données interdites, fonctions sensibles et conditions d’arrêt.
Une faiblesse est qualifiée selon la reproductibilité, la permission atteinte, la sensibilité de la donnée, le nombre d’utilisateurs concernés et la possibilité de chaîner plusieurs défauts. Une simple réponse étrange n’est pas traitée comme une compromission.
Les correctifs portent d’abord sur les contrôles déterministes : moindre privilège, allowlist de fonctions, validation des paramètres, séparation des identités, confirmation hors LLM, isolation de la mémoire et filtrage des flux sortants.
Le prompt système peut orienter le comportement, mais il ne constitue pas une frontière de sécurité. Les décisions critiques doivent rester en dehors du LLM : autorisation, portée des données, contrôle d’accès, plafond financier, validation d’une destination et confirmation d’une action irréversible.
L’OWASP LLM06:2025 décrit l’excessive agency comme la possibilité d’effectuer des actions dommageables à cause de fonctionnalités, permissions ou autonomie excessives. L’ANSSI recommande également de limiter les interactions aux besoins opérationnels et de prévoir une validation humaine lorsque l’action est critique.
Indiquez ses outils, ses API, sa mémoire et les données accessibles. Le périmètre est défini avant tout scénario d’attaque.