Expertise · Sécurité des agents
Sécuriser un agent IA
Sécuriser un agent, ce n’est pas le rendre prudent : c’est borner ce qu’il peut faire, filtrer ce qu’il a le droit de voir, et garder la trace de ce qu’il a fait. Un modèle qui appelle des outils ne produit plus du texte, il déclenche des actions. La capacité technique arrive toujours avant les garde-fous, et cet écart est le risque.

Quelles failles touchent réellement un agent en production ?
Quatre questions suffisent à couvrir ce qui casse : ce qui entre, ce qu’il a le droit de voir, ce qu’il a le droit de faire, et ce qu’on peut prouver après coup. Les incidents observés se rangent presque tous dans l’une de ces quatre familles.
| Famille | La question à poser | Ce qui casse quand on l’oublie |
|---|---|---|
| Ce qui entre | Un contenu lu peut-il donner un ordre ? | Injection indirecte : l’agent exécute la consigne d’un tiers |
| Ce qu’il voit | Les droits du demandeur sont-ils appliqués ? | Un document confidentiel cité à qui n’y a pas accès |
| Ce qu’il fait | Quelles actions peut-il déclencher seul ? | Une action irréversible sans validation humaine |
| Ce qu’on prouve | Que reste-t-il de vérifiable ? | Un incident inexplicable, faute de journal |
Un contenu lu par l’agent peut-il lui donner un ordre ?
Un document, une page ou un courriel traité par l’agent est une entrée, pas une consigne. Quand le modèle ne fait plus la différence, l’injection indirecte devient une prise de contrôle.
L’agent respecte-t-il les droits de celui qui l’interroge ?
Un agent répond avec son propre accès, pas avec celui de l’utilisateur. Sans filtrage à la recherche, il restitue des documents que la personne n’aurait jamais dû lire.
Jusqu’où l’agent peut-il agir seul ?
La capacité technique précède toujours les garde-fous. L’écart entre ce que l’agent sait faire et ce qu’il a le droit de faire seul est, à lui seul, le risque.
Que reste-t-il de vérifiable après coup ?
Une alerte n’est pas un constat, un marquage n’est pas une preuve, et un essai sans trace n’est pas un résultat. Ce qui n’a pas été enregistré n’a pas eu lieu.
Les agents open source changent-ils le problème ?
Ils le déplacent : le code est lisible, donc la mémoire et les outils se vérifient, mais l’hébergement et les permissions deviennent entièrement votre responsabilité.
Comment ce travail s’inscrit-il dans un audit ?
La sécurité d’un agent n’est pas un chapitre séparé : elle se traite avec le périmètre, les données et la recette, dans le même audit.
Le cadre général est décrit sur la page audit IA, et les obligations de preuve dans le calendrier du règlement européen sur l’IA. Pour situer un agent avant d’en discuter, la grille de recette d’agent liste les essais à prévoir, et agent ou simple appel au modèle aide à trancher en amont, quand la question de sécurité ne se pose pas encore.
Questions fréquentes
Qu’est-ce qu’une injection de prompt indirecte ?
C’est une consigne cachée dans un contenu que l’agent lit, et non dans la demande de l’utilisateur : une page web, une pièce jointe, un ticket, un commentaire de code. L’agent traite ce contenu comme une instruction et exécute l’action demandée par l’attaquant. Elle est dite indirecte parce que l’attaquant ne parle jamais à l’agent : il lui laisse un message à lire.
Une consigne système suffit-elle à protéger un agent ?
Non. Une consigne système exprime une intention, elle ne contraint rien. Un modèle traite la consigne et le document avec le même mécanisme, et un contenu bien formulé peut l’emporter. La protection vient de ce qui entoure le modèle : outils aux permissions minimales, validation humaine sur les actions irréversibles, et vérification des effets, pas de l’intention déclarée.
Un RAG respecte-t-il automatiquement les droits d’accès ?
Non, et c’est la faille la plus fréquente. L’index est souvent construit avec un compte de service qui voit tout. Si le filtre d’autorisation n’est pas appliqué à la recherche elle-même, avec l’identité du demandeur, l’agent cite des documents que la personne n’a pas le droit de lire. Le cache et les révocations de droits sont deux pièges supplémentaires.
Comment tester la sécurité d’un agent sans prendre de risque ?
Avec des outils simulés et un corpus témoin. Les appels d’outils sont interceptés plutôt qu’exécutés, les documents hostiles sont fictifs, et l’on mesure deux choses à la fois : l’agent évite-t-il l’action interdite, et réussit-il encore la demande légitime ? Un agent qui refuse tout n’est pas un agent sécurisé.
Faut-il une certification de sécurité pour mettre un agent en production ?
Aucun référentiel ne certifie aujourd’hui la résistance d’un agent aux injections. Ce qui tient devant un auditeur est un dossier : périmètre écrit, permissions accordées, jeu de tests avec ses résultats, versions du modèle et des consignes, journal des actions et procédure d’arrêt. C’est le niveau de preuve attendu par le règlement européen sur l’IA.
Par où commencer quand un agent est déjà en service ?
Par l’inventaire des permissions réellement accordées, souvent plus larges que prévu, puis par la liste des actions irréversibles qu’il peut déclencher seul. Ces deux listes suffisent à classer le risque. Les essais d’injection viennent ensuite : ils n’ont de sens qu’une fois connu ce que l’agent peut faire d’une consigne détournée.
Faire le point sur votre agent
Quinze minutes suffisent pour dire si votre agent est bornable en l’état, quelles permissions il faut reprendre, et quels essais mener avant de l’ouvrir plus largement.
Prendre quinze minutesFaites un premier point en 3 minutes
Un diagnostic gratuit, en 3 minutes maximum. Répondez aux questions, consultez un aperçu, puis renseignez votre nom, votre e-mail et votre entreprise pour demander le résultat détaillé et sa copie par e-mail, avec des recommandations adaptées. Vous pouvez vous opposer au recontact professionnel sans perdre l’accès au résultat demandé.
- Quel audit choisir ? →
- Mon projet passera-t-il en production ? →
- Quel coût réel prévoir ? →
- Quels tests prévoir pour mon agent ? →
- Faut-il un agent ou un appel au modèle ? →
- Faut-il un RAG ou un fine-tuning ? →
Voir tous les outils · Utilisation de vos données et droit d’opposition