Garde-fous pour applications et agents d'IA : ce qu'ils détectent, ce qu'ils coûtent et ce qui compte davantage

Dès que votre chatbot ou votre agent est face à des clients, des inconnus peuvent lui écrire n'importe quoi, et chaque page web, e-mail ou document qu'il lit peut apporter ses propres instructions. Les garde-fous sont les contrôles placés autour du modèle qui filtrent ce trafic. Ils valent la peine et peuvent coûter peu, mais aucun ne sauvera un agent à qui l'on a donné plus de pouvoir que sa tâche n'en demande.

Cet article porte sur les fonctions et agents d'IA que vous livrez à des utilisateurs. Si votre souci est un agent de programmation sur le poste d'un développeur, notre guide pour sécuriser les agents de programmation couvre les sandboxes, les gardiens de commandes et les barrières en CI pour ce cas. Chaque chiffre provient de nos tests critiques ou des documents de fournisseurs et de recherche qu'ils citent ; nous n'avons pas exécuté ces outils nous-mêmes.

Ce qu'un garde-fou détecte réellement

Quatre problèmes expliquent l'essentiel de ce contre quoi ces produits sont vendus. L'OWASP Top 10 for LLM Applications est une liste de contrôle utile, et les garde-fous traitent le plus directement trois de ses entrées : l'injection de prompt (LLM01), la divulgation d'informations sensibles (LLM02) et l'autonomie excessive (LLM06).

• Injection de prompt. Un texte qui tente de remplacer vos instructions par celles de quelqu'un d'autre. La forme directe vient de l'utilisateur. La forme indirecte se cache dans une page récupérée, un e-mail ou le résultat d'un outil, et c'est elle qui nuit aux agents, car le modèle la lit comme une partie de son travail.
• Jailbreaks. Des tentatives pour convaincre le modèle d'abandonner ses règles de sécurité, souvent réparties sur plusieurs tours de conversation.
• Sorties dangereuses. Des réponses nuisibles ou contraires à votre politique, et des réponses qui affirment des choses que les documents récupérés n'étayent pas.
• Fuite de données. Des données personnelles, des secrets ou votre prompt système qui sortent dans une réponse, ou un lien dans une réponse qui pointe là où il ne devrait pas.

Aucun produit ne couvre les quatre aussi bien. Un détecteur d'injection signale le texte qui ressemble à une instruction, pas le danger : la fiche de Meta pour Llama Prompt Guard 2 note qu'une documentation citant "ignore previous instructions" le déclenchera. Un modèle de modération qui note la violence ne remarquera pas une instruction polie cachée dans le PDF d'un fournisseur. Associez chaque contrôle à un risque avant d'acheter quoi que ce soit.

Trois sortes de garde-fous

Les modèles de sécurité que vous hébergez

Ce sont des modèles à poids ouverts que vous faites tourner à côté du vôtre. Le texte ne quitte jamais vos machines et il n'y a pas de frais par contrôle ; en échange, le GPU, les mises à jour et le réglage sont pour vous.

• Llama Prompt Guard 2 (4.2) est le filtre d'injection bon marché. Son modèle de 86M détecte 97.5% des attaques du jeu privé de jailbreaks de Meta avec un taux de faux positifs de 1%. Sur AgentDojo, un banc d'essai où des attaquants placent des instructions dans les outils d'un agent, il en arrête 81.2% pour un coût de 3% en tâches accomplies. Il lit 512 tokens à la fois, donc les longues pages doivent être découpées, et le téléchargement est soumis à la Llama 4 Community License.
• Qwen3Guard (4.3) est le modèle de modération multilingue : 119 langues et dialectes, des tailles de 0.6B à 8B, sous Apache 2.0. Il classe le texte comme sûr, controversé ou dangereux, si bien qu'une application pour enfants et une plateforme de fiction pour adultes peuvent partager un modèle et ne différer que sur le sens de "controversial". Une variante Stream vérifie la réponse token par token pendant qu'elle s'écrit.
• Granite Guardian 4.1 (4.0) est le juge de 8B d'IBM. Au-delà du danger, il vérifie si une réponse s'appuie sur le texte récupéré et si l'appel de fonction d'un agent correspond aux outils qu'on lui a fournis. Il ne fonctionne qu'en anglais, et IBM le destine à la surveillance et aux contrôles ponctuels plutôt qu'à chaque message.
• gpt-oss-safeguard (4.0) prend une politique écrite en langage courant et renvoie une décision avec son raisonnement, si bien qu'une équipe confiance et sécurité peut changer une règle sans étiqueter de nouvelles données d'entraînement. Il est plus lent et plus lourd qu'un classifieur, le 20b demande un GPU de 16 Go, et OpenAI prévient que le raisonnement affiché peut être halluciné.

Les API de garde-fous dans le cloud

Un service hébergé fait tourner et met à jour les détecteurs. Vous envoyez chaque prompt et chaque réponse sur le réseau et recevez un verdict, au prix d'un nouveau sous-traitant de données et d'un aller-retour réseau, mais sans faire tourner de modèles vous-même.

• Google Model Armor (4.2) filtre les injections, les contenus nuisibles, les données sensibles et les liens douteux pour $0.10 par million de tokens, les 2 premiers millions de chaque mois étant gratuits. Il fonctionne avec des modèles hors de Google Cloud. Il juge chaque requête isolément, sans mémoire de la conversation, et ne décode pas le Base64.
• Azure AI Content Safety (4.1) note le danger dans le texte et les images, et ses Prompt Shields examinent à la fois les prompts des utilisateurs et les documents à la recherche de commandes injectées. Le niveau standard coûte $0.375 pour 1,000 enregistrements de texte d'au plus 1,000 caractères. Microsoft indique que les entrées ne sont ni stockées ni utilisées pour l'entraînement ; Prompt Shields est entraîné surtout en anglais.
• Lakera Guard (4.0), désormais vendu par Check Point, accepte une conversation entière au format OpenAI, appels d'outils compris, et filtre le dernier échange. L'offre gratuite couvre 10,000 requêtes par mois ; au-delà, aucun prix n'est publié.

Les frameworks de garde-fous

Un framework n'est pas un détecteur. C'est la tuyauterie qui exécute des contrôles à chaque point de votre application et décide quoi faire du résultat ; vous y branchez des modèles ou des API.

• NVIDIA NeMo Guardrails (4.0) dispose de rails distincts pour l'entrée, la sortie, la récupération et l'exécution des outils, et accueille Llama Guard, les modèles NemoGuard de NVIDIA, Presidio et des détecteurs commerciaux. Il exige une vraie configuration en YAML et dans son propre langage, Colang, sa version 0.24.0 comptait six changements incompatibles, et une télémétrie anonyme vers NVIDIA est activée par défaut.
• LlamaFirewall (3.8) est la conception en couches de Meta : Prompt Guard 2 sur les entrées et les sorties d'outils, AlignmentCheck qui lit le raisonnement de l'agent à la recherche de signes de détournement, et CodeShield qui analyse le code généré. Son article est la meilleure preuve publique que les couches fonctionnent ; le paquet lui-même n'a connu aucune version depuis mai 2025.
• Guardrails AI (3.2) est le contre-exemple. Son Hub hébergé a fermé le 25 août 2026, l'équipe a rejoint Harvey, rien n'a été fusionné depuis, et une version malveillante 0.10.1 a atteint PyPI en mai. Ses validateurs hors ligne pour les regex, les schémas et la longueur fonctionnent toujours ; un nouveau projet a de meilleures options.

Ce que rapportent les couches

Les chiffres les plus clairs viennent de l'article de Meta sur LlamaFirewall, mesurés sur AgentDojo. Sans garde-fou, 17.6% des attaques ont réussi. Prompt Guard 2 seul a ramené ce taux à 7.5%. AlignmentCheck, qui demande à un grand modèle si l'agent fait toujours ce que l'utilisateur a demandé, l'a abaissé à 2.89%. Les deux ensemble ont atteint 1.75%, tandis que la part des tâches accomplies par l'agent passait de 47.7% à 42.7%.

Deux leçons en découlent. Un filtre rapide et un contrôle par raisonnement plus lent laissent passer des attaques différentes, donc leurs effets s'additionnent. Et la protection coûte de l'utilité autant que de l'argent : selon notre calcul, environ une tâche sur dix qui réussissait auparavant a échoué.

Latence et coût sur le chemin de la requête

Chaque contrôle placé avant la réponse ajoute du temps, et un agent peut en lancer plusieurs par tour : le message de l'utilisateur, chaque document récupéré, chaque résultat d'outil et la réponse finale. Comptez les contrôles par tour, pas par conversation.

Contrôle	Latence publiée	Coût
Prompt Guard 2, 22M	19.3 ms pour 512 tokens sur une A100	Votre GPU
Prompt Guard 2, 86M	92.4 ms pour 512 tokens sur une A100	Votre GPU
Premier passage de CodeShield	Environ 60 ms	Votre CPU ou GPU
AlignmentCheck	Environ 860 à 1,490 ms par étape dans la trace de l'article	Un appel à un grand modèle par étape auditée
Lakera Guard	Moins de 50 ms (selon le fournisseur)	Gratuit jusqu'à 10,000 requêtes par mois, puis sur devis
Google Model Armor	Non indiquée dans nos sources	$0.10 par million de tokens
Azure AI Content Safety	Non indiquée dans nos sources	$0.375 pour 1,000 enregistrements de texte

À ces prix, filtrer un million de courts messages de chat coûte quelques dollars avec Model Armor et $375 avec Azure. Un milliard de tokens par mois sur Model Armor revient à environ $100, ou à rien dans les 3 milliards inclus dans un abonnement Security Command Center Enterprise ou Premium. Lakera compte chaque élément filtré comme une requête : un agent qui vérifie le prompt, deux documents et la réponse en consomme quatre par tour et épuise l'offre gratuite en 2,500 tours.

L'auto-hébergement déplace la facture vers le matériel. Les modèles ouverts n'ont pas de frais, mais quelqu'un paie les GPU, et NVIDIA AI Enterprise, qui couvre le microservice de NeMo Guardrails, est affiché à $4,500 par GPU et par an.

Trois habitudes limitent le délai. Faites passer le classifieur bon marché sur tout et n'envoyez aux juges lents que les étapes risquées ; OpenAI décrit le même schéma pour gpt-oss-safeguard, avec des classifieurs rapides d'abord et une partie du trafic envoyée au modèle de raisonnement. Exécutez en parallèle les contrôles indépendants, comme le fait le moteur IORails de NeMo pour les contrôles NemoGuard. Et pour les réponses en streaming, vérifiez le texte au fil de son arrivée : la variante Stream de Qwen3Guard note chaque token, et Lakera demande des segments d'au moins 10 tokens.

Les faux positifs sont le vrai travail de réglage

Chaque détecteur arbitre entre attaques manquées et clients bloqués, et les chiffres de précision des fournisseurs viennent de leurs propres jeux de test. Lakera livre chaque détecteur au niveau L4, le plus strict, et qualifie sa politique par défaut de "intentionally strict". Meta indique que la précision de Prompt Guard 2 dépend de ce à quoi ressemble le trafic normal de votre application et recommande un affinage sur vos propres données.

Avant de bloquer quoi que ce soit, faites passer quelques centaines de requêtes réelles et inoffensives et un ensemble d'attaques connues dans le garde-fou, et notez le taux de blocage et le taux d'échec à chaque seuil. Passez ensuite en production en mode journalisation seule, que Lakera appelle mode Detect, et lisez ce qu'il signale pendant une ou deux semaines. Décidez à l'avance ce que voit l'utilisateur en cas de blocage : un refus clair avec un moyen de joindre une personne vaut mieux qu'un échec silencieux. L'étiquette controversé de Qwen3Guard offre une troisième voie entre autoriser et bloquer : envoyer le cas dans une file de relecture.

Où se placent le red teaming et l'analyse de la chaîne d'approvisionnement

Les garde-fous agissent sur le trafic réel. Le red teaming attaque votre application avant les utilisateurs et vous dit si les garde-fous fonctionnent ; l'analyse de la chaîne d'approvisionnement vérifie le code et les outils auxquels votre application fait confiance. Il vous faut les trois, à des moments différents.

• Au choix du modèle. CyberSecEval (3.9) mesure à quelle fréquence un modèle nu écrit du code vulnérable ou obéit à un texte injecté. Il ne voit ni vos prompts, ni vos outils, ni votre récupération, sa place est donc à côté de la fiche du modèle, pas à la place d'un test de l'application.
• Avant le lancement et après chaque changement. garak (4.3) lance une bibliothèque d'attaques publiées contre un point d'accès ; dirigez-le vers l'application déployée avec ses garde-fous devant, car le prompt système et les filtres changent le résultat. promptfoo (4.5) met les tests de red team dans un fichier YAML exécuté en CI. DeepTeam (3.9) couvre des risques propres aux agents comme le contournement d'autorisation et les descriptions d'outils empoisonnées.
• Les attaquants patients. PyRIT (4.2) mène des attaques sur plusieurs tours comme Crescendo, où un modèle attaquant fait monter la pression peu à peu. C'est précisément le cas qu'un filtre jugeant une requête à la fois est conçu pour manquer.

Ce que trouve le red team doit revenir dans les seuils du garde-fou et, plus souvent, dans les droits des outils.

Les garde-fous eux-mêmes font partie de votre chaîne d'approvisionnement. La version malveillante 0.10.1 de Guardrails AI en est un exemple ; en mars 2026, des attaquants ont aussi publié deux versions piégées de LiteLLM sur PyPI à l'aide d'identifiants de mainteneur volés. Figez les versions et les empreintes exactes des bibliothèques de garde-fous, des passerelles et des SDK, et analysez-les avec le reste de votre code : Semgrep (4.3) comme contrôle obligatoire sur les pull requests, et Snyk (4.0) pour les dépendances et les conteneurs, dont l'offre gratuite s'arrête à 100 tests Snyk Code par mois. Pour les serveurs MCP et les skills que charge votre agent, Snyk Agent Scan (3.8) cherche des instructions cachées dans les descriptions d'outils, et envoie pour cela ces descriptions à Snyk.

Le moindre privilège compte plus que n'importe quel filtre

Le meilleur résultat en couches ci-dessus laissait encore passer 1.75% des attaques, sur un banc d'essai dont les attaques étaient connues d'avance, et Meta prévient que les attaquants s'adaptent aux classifieurs. Prévoyez l'injection qui franchit tous les filtres et demandez-vous ce qu'elle peut faire ensuite. La réponse dépend des outils que vous avez donnés à l'agent, pas du garde-fou.

• Agir en tant qu'utilisateur, pas avec un compte de service. Quand un appel d'outil porte l'identité de l'utilisateur connecté, une instruction injectée ne peut pas obtenir de données que cet utilisateur ne pourrait pas voir. Vérifiez l'autorisation dans votre code, jamais dans le prompt.
• Donner à chaque outil l'accès le plus étroit. Un agent qui répond à des questions sur des commandes a besoin d'une vue en lecture seule des commandes d'un client, pas de la base de données.
• Placer une personne devant l'irréversible. Paiements, suppressions et messages vers des adresses externes doivent attendre une confirmation que le modèle ne peut pas se donner lui-même.
• Limiter où les données peuvent aller. Un agent qui peut ouvrir n'importe quelle URL peut envoyer vos données à n'importe quelle URL.
• Isoler les outils. ToolHive (4.1) fait tourner chaque serveur MCP dans son propre conteneur sans aucun de vos identifiants locaux, ajoute une politique d'accès fondée sur l'identité pour chaque requête et tient des journaux d'audit. Son test critique est clair : le confinement n'empêche pas un serveur d'abuser de l'accès que vous lui accordez délibérément. Quand un agent exécute du code, OpenSandbox (4.1) lui fournit une sandbox jetable via une API, mais c'est un conteneur ordinaire tant que vous ne configurez pas gVisor, Kata ou Firecracker, et il tourne sans authentification si aucune clé d'API n'est définie.
• Journaliser chaque appel d'outil avec l'utilisateur, l'entrée et le résultat, pour pouvoir retracer un incident.

Une configuration de départ pour une petite équipe

Imaginez cinq personnes qui livrent un chatbot de support ou un petit agent sur un seul cloud, sans personne dont l'intitulé de poste mentionne la sécurité.

1. D'abord les droits. Listez chaque outil, donnez à chacun l'accès le plus étroit et ajoutez une étape de confirmation avant tout ce qui envoie, paie ou supprime. Cela prend un après-midi et fait plus que n'importe quel produit ci-dessous.
2. Un filtre hébergé sur les saisies des utilisateurs, les documents récupérés et les réponses : Model Armor si vous êtes sur Google Cloud ou sur aucun cloud en particulier, Azure AI Content Safety si vous travaillez déjà sur Azure. L'offre gratuite de Lakera convient à un prototype. Si vous faites déjà tourner des GPU, Prompt Guard 2 22M sur les sorties d'outils est presque gratuit, et Qwen3Guard 0.6B est le modèle de modération multilingue le moins cher à servir.
3. Deux semaines en journalisation seule, puis activez le blocage avec des seuils vérifiés sur votre propre trafic.
4. Un fichier de red team en CI. Une configuration promptfoo lancée à chaque changement de prompt ou de modèle, et une analyse garak ciblée après un changement de modèle.
5. Des dépendances figées et Semgrep comme contrôle obligatoire sur les pull requests.

Les logiciels de cette liste sont gratuits ou presque. Les factures viennent du filtrage par requête et des tokens de modèle consommés par les campagnes de red team.

Une configuration de départ pour une entreprise réglementée

Une banque, un assureur ou un établissement de santé a les mêmes risques, plus des auditeurs, des règles de résidence des données et une revue fournisseur pour chaque nouveau sous-traitant.

1. Des outils liés à l'identité. Les agents agissent avec l'identité de l'utilisateur. Les serveurs MCP tournent derrière ToolHive pour la politique par requête, l'isolation et les journaux d'audit, et le code généré s'exécute dans OpenSandbox avec un runtime sécurisé et une clé d'API configurés.
2. Un point de contrôle unique. NeMo Guardrails avec des rails sur l'entrée, la récupération, l'exécution des outils et la sortie, une version figée, la télémétrie coupée via DO_NOT_TRACK=1, et require_iorails=True pour que les configurations que le moteur rapide ne sait pas exécuter échouent de façon visible au lieu de revenir en silence à l'ancien.
3. Des détecteurs conformes à vos règles de données. Prompt Guard 2 auto-hébergé sur chaque entrée et chaque résultat d'outil ; Qwen3Guard pour la modération multilingue, ou Granite Guardian si l'anglais suffit et que vous voulez des contrôles d'ancrage et d'appels de fonction sous Apache 2.0. Si une API cloud est autorisée, préférez celle qui est déjà approuvée : Azure garde le traitement dans la région choisie pour la plupart des contrôles et accepte les clés gérées par le client, et Google indique que Model Armor efface le contenu après chaque contrôle sauf si la journalisation est activée. Lakera propose un auto-hébergement isolé du réseau en Enterprise. Notez que plusieurs fonctions Azure en préversion, dont la détection d'ancrage, seront retirées le 30 avril 2027.
4. Des juges lents là où ils paient. gpt-oss-safeguard pour les décisions de politique et les recours qui exigent une justification écrite, et un audit à la manière d'AlignmentCheck sur les étapes à haut risque de l'agent, avec un grand modèle pour lequel vous avez déjà un contrat.
5. Des preuves de test. CyberSecEval au choix du modèle, les préréglages OWASP de DeepTeam pour montrer à un auditeur ce qui a été testé, et PyRIT entre les mains d'un spécialiste du red teaming pour les attaques sur plusieurs tours. Recommencez après chaque changement de modèle, de prompt, de garde-fou ou d'outil, et conservez les transcriptions.
6. Chaîne d'approvisionnement et propriété. Empreintes figées, Semgrep et Snyk en CI, Snyk Agent Scan sur les nouveaux serveurs MCP une fois que votre délégué à la protection des données a validé l'envoi des descriptions d'outils à Snyk. Ce marché change vite de mains : Lakera appartient désormais à Check Point, promptfoo à OpenAI, et le service hébergé de Guardrails AI a disparu. Gardez chaque garde-fou derrière votre propre interface pour pouvoir le remplacer.

Le hic : la plupart des garde-fous voient le texte morceau par morceau, et les attaquants le savent. Model Armor n'a aucune mémoire de la conversation, ne décode pas le Base64 et ignore les entrées trop volumineuses au lieu de les signaler. Prompt Guard 2 lit 512 tokens, donc une attaque répartie sur plusieurs segments peut passer. Les Prompt Shields d'Azure s'arrêtent à 10,000 caractères pour le prompt et 10,000 sur cinq documents au plus. Hors de l'anglais, la plupart perdent du terrain. Jugez un filtre sur ce qu'il coûte et sur la fréquence de ses erreurs, jamais sur son exhaustivité.

Notre avis : les garde-fous sont le videur, les droits sont les serrures des pièces. Un videur écarte la plupart des ennuis et parfois un habitué, tandis que les serrures décident des dégâts que peut causer celui qui passe quand même. Posez d'abord les serrures, engagez le videur le moins cher qui parle les langues de vos clients, et n'envoyez les juges coûteux qu'aux portes qui comptent.