Sécuriser un agent IA : injections de prompt et garde-fous

La sécurité d’un agent IA repose sur une idée simple : partir du principe que l’agent peut être trompé, et limiter ce qu’il peut faire dans ce cas. Aucune protection n’arrête à elle seule l’injection de prompt, mais une défense en plusieurs couches (droits minimaux, isolement, garde-fous, validation humaine et tests réguliers) réduit fortement les dégâts possibles.

Pourquoi un agent est plus exposé qu’un chatbot

Un chatbot répond par du texte. Si on le pousse à dire une bêtise, le dommage se limite en général à une réponse fausse ou déplacée. Un agent, lui, agit. Il lit vos courriels, consulte des pages web, ouvre des fichiers et se sert d’outils grâce à l’appel d’outils, c’est-à-dire en déclenchant des fonctions concrètes : envoyer un message, écrire dans une base de données, passer une commande.

Trois ingrédients rendent la situation délicate quand ils sont réunis :

1. L’accès à des données privées : boîte mail, documents internes, fichier clients.
2. L’exposition à des contenus non fiables : pages web, pièces jointes, tickets de support, avis en ligne, bref tout ce qu’un inconnu peut écrire.
3. La capacité d’agir ou de communiquer vers l’extérieur : envoyer un message, appeler un service, publier.

Un agent qui cumule les trois peut, s’il est manipulé, faire sortir des informations ou déclencher une action que personne n’a voulue. Si vous débutez dans la construction d’agents, notre guide complet pour créer un agent IA pose d’abord les bases. Cet article se concentre sur la protection.

L’injection de prompt, expliquée simplement

L’injection de prompt consiste à glisser des instructions dans un texte que l’IA va lire, pour qu’elle les suive à la place des consignes prévues. Elle fonctionne parce qu’un modèle de langage reçoit tout sous forme de texte. Les consignes du développeur, la demande de l’utilisateur et les contenus consultés arrivent dans le même flux, sans frontière étanche entre « ordres » et « données ».

On distingue deux familles :

• L’injection directe vient de la personne qui écrit à l’agent et tente de lui faire ignorer ses règles.
• L’injection indirecte est cachée dans un contenu externe que l’agent traite : une page, un PDF, un courriel. C’est la plus préoccupante, car l’utilisateur légitime ne la voit souvent pas et la déclenche sans le savoir.

Nous ne détaillons pas ici la façon dont ces attaques sont construites. Ce qui compte pour vous, c’est de concevoir l’agent pour qu’une instruction malveillante, même suivie, ne puisse pas faire grand mal.

Les couches de défense à mettre en place

Aucune de ces mesures ne suffit seule. Leur force vient de leur empilement : si une couche cède, la suivante limite les conséquences.

1. Donner le moins de droits possible

C’est le principe du moindre privilège. Chaque outil confié à l’agent doit avoir le périmètre le plus étroit possible : lecture seule quand la lecture suffit, un seul dossier plutôt que tout le disque, une boîte de test plutôt que la messagerie principale. Créez des accès dédiés à l’agent, révocables et limités dans le temps, et n’utilisez jamais vos propres identifiants. Les clés d’accès se stockent côté serveur, jamais dans le texte que lit le modèle.

L’OWASP conseille aussi de traiter les fonctions sensibles dans le code plutôt que de les confier au prompt. Exemple : plutôt que de dire à l’agent « ne rembourse jamais plus de 50 euros », faites en sorte que l’outil de remboursement refuse lui-même tout montant supérieur. Si vous exposez vos outils par le protocole MCP, chaque outil est une porte d’entrée : notre tutoriel pour créer un serveur MCP montre comment les découper finement.

2. Isoler l’agent dans un bac à sable

Le bac à sable fait travailler l’agent dans un environnement fermé. Deux barrières sont essentielles : l’isolement du système de fichiers (l’agent ne voit qu’un dossier de travail) et l’isolement du réseau (il ne peut joindre que des adresses approuvées). Dans un article d’octobre 2025 sur l’isolement de son outil Claude Code, Anthropic insiste sur le fait que les deux sont nécessaires : un agent qui peut lire des données sensibles et contacter n’importe quel serveur peut les faire sortir.

Pour les agents qui pilotent un navigateur ou un ordinateur, une machine virtuelle dédiée, réinitialisée après chaque tâche, est une bonne pratique.

3. Séparer et signaler les contenus externes

Tout ce qui vient de l’extérieur doit être identifié comme tel et traité comme une donnée, pas comme un ordre. Une architecture prudente sépare les rôles : un composant lit les contenus non fiables mais n’a accès à aucun outil sensible ; un autre agit, mais ne reçoit qu’un résumé structuré du premier. Des consignes claires dans le prompt système aident l’agent à rester dans son rôle, mais elles ne garantissent rien face à un texte malveillant bien conçu.

4. Filtrer les entrées et les sorties

Les garde-fous sont des contrôles placés autour du modèle. En entrée, ils repèrent les demandes hors cadre ou les données sensibles. En sortie, ils vérifient la réponse ou l’action avant qu’elle ne parte. Imposer un format de sortie précis facilite beaucoup ce travail : si l’agent doit renvoyer un montant et une référence de commande, votre code peut vérifier de façon certaine que le montant reste dans une fourchette et que la référence existe. Parmi les projets connus figurent NeMo Guardrails, une boîte à outils open source de NVIDIA, et Llama Guard, un modèle de classement des risques publié par Meta.

5. Garder un humain pour les actions irréversibles

L’humain dans la boucle signifie qu’une personne valide certaines actions avant leur exécution : paiement, envoi vers l’extérieur, suppression, modification de droits. Montrez à cette personne l’action exacte, avec ses paramètres, et non un résumé rédigé par l’agent. Attention à la lassitude : si l’on demande une validation pour tout, on finit par tout accepter sans lire. Réservez-la aux actions qui comptent, et laissez le reste se dérouler dans le bac à sable.

6. Tout journaliser et pouvoir tout arrêter

Enregistrez chaque appel d’outil, ses paramètres et l’origine des contenus lus. Ces traces servent à repérer un comportement inhabituel (un volume d’envois anormal, une adresse jamais vue) et à comprendre un incident après coup. Prévoyez un arrêt d’urgence : couper l’agent et révoquer ses accès doit prendre quelques secondes, pas une réunion.

7. Tester comme un adversaire, régulièrement

Le red teaming consiste à faire tenter le détournement de l’agent par une équipe ou un outil, dans un environnement de test, pour trouver les failles avant les autres. Ajoutez des scénarios de sécurité à vos jeux de tests, à côté des tests de qualité décrits dans notre guide pour évaluer un agent IA. Recommencez après chaque changement de modèle, d’outil ou de consignes : un agent sûr hier peut ne plus l’être demain.

Les sept couches en un coup d’œil

Couche	Ce qu’elle limite	Exemple concret
Moindre privilège	L’ampleur des dégâts possibles	Accès en lecture seule à un seul dossier
Bac à sable	Les fuites et les effets hors périmètre	Réseau limité à une liste d’adresses
Séparation des contenus	L’influence des textes non fiables	Le lecteur de pages n’a aucun outil d’envoi
Garde-fous	Les demandes et réponses hors cadre	Contrôle automatique du montant renvoyé
Humain dans la boucle	Les actions irréversibles	Confirmation avant tout paiement
Journalisation	Les incidents invisibles	Alerte sur une adresse de destination inconnue
Tests adverses	Les failles non découvertes	Campagne de tests après chaque mise à jour

Ce que font les éditeurs et les frameworks

Les éditeurs de produits agentiques communiquent de plus en plus sur leurs protections. Perplexity, par exemple, décrit pour son navigateur Comet une défense en plusieurs couches contre l’injection de prompt, avec classifieurs, demandes de confirmation et audit externe. Ces mesures réduisent le risque, elles ne le suppriment pas, et aucun éditeur ne promet une protection totale.

Côté développement, les frameworks d’agents proposent souvent des briques utiles : validation humaine, traçage des appels, intégration de garde-fous. Mais ils ne prennent pas les décisions de conception à votre place. Notre comparatif des frameworks d’agents IA vous aide à choisir l’outil, et notre outil Puis-je confier ça à un agent ? vous aide à évaluer le risque d’une tâche avant de l’automatiser.

La check-list avant la mise en production

• L’agent a-t-il uniquement les droits dont il a besoin, avec des accès dédiés et révocables ?
• Tourne-t-il dans un environnement isolé, réseau compris ?
• Les contenus externes sont-ils séparés des consignes et des outils sensibles ?
• Les sorties sont-elles vérifiées par du code avant d’être exécutées ?
• Les actions irréversibles exigent-elles une confirmation humaine claire ?
• Chaque action est-elle journalisée, avec un arrêt d’urgence prêt ?
• Avez-vous mené des tests adverses, et prévu de les refaire à chaque mise à jour ?

Vérifiez-vous Votre agent de support lit les tickets des clients et peut déclencher des remboursements. Quelle mesure réduit le plus le risque ?

Plafonner les remboursements directement dans l’outil, et exiger une validation humaine au-delà d’un seuil. Les tickets sont des contenus non fiables : n’importe qui peut y écrire. Une consigne du type « ne rembourse jamais sans raison » peut être contournée, alors qu’une limite codée dans l’outil s’applique quoi que le modèle décide.