HELDGUARD

AUDIT DE SÉCURITÉ AGENT IA

Quand l’IA peut agir, le risque ne s’arrête plus à sa réponse.

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.

Visualisation d’un agent IA, de ses outils et d’une tentative de franchissement d’une permission
CHAÎNE D’IMPACTDu message manipulé jusqu’à l’outil, la permission ou l’action exposée.

Quelle différence entre un chatbot et un agent IA ?

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.

ComposantQuestion de sécuritéImpact possible
OutilL’agent peut-il appeler une fonction sans validation suffisante ?Envoi, modification ou suppression non autorisée.
PermissionL’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émoireUne entrée peut-elle influencer durablement les sessions futures ?Empoisonnement du comportement ou élévation de privilège logique.
DélégationUn agent pair ou distant est-il considéré comme une source fiable ?Propagation d’instructions hostiles entre agents.
SortieLe résultat du modèle est-il exécuté ou rendu sans validation ?SSRF, injection, XSS, commande dangereuse ou fuite externe.

Les principaux chemins d’attaque

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.

Abus d’outil

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.

Permissions excessives

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 ».

Empoisonnement de mémoire

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.

Confused deputy

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.

Chaîne multi-agents

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.

Comment se déroule l’audit d’un agent IA ?

1. Cartographie des capacités

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.

2. Définition des frontières de confiance

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.

3. Scénarios d’attaque autorisés

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.

4. Validation de l’impact

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.

5. Remédiation et retest

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.

Ce que l’audit ne doit pas déléguer au modèle

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.

Référentiels utilisés

Cartographions les capacités de votre agent.

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.

Décrire mon agent