Les barrières de sécurité (Guardrails) de l'AI Gateway expliquées : Hooks, application et sémantique des échecs

Un garde-fou n'est pas un simple interrupteur de sécurité. Son hook, son mode de fonctionnement, sa stratégie d'application, sa portée, son comportement en cas d'échec et ses preuves déterminent ce que le système garantit réellement.

TrueFoundry19 septembre 20269 min de lecture

Cadrage de la source. Cette explication est basée sur la documentation « AI Gateway Guardrails Overview » et « Configure Guardrail Policies » de TrueFoundry, telle que révisée le 19 septembre 2026. Elle reflète les hooks d'entrée/sortie LLM et pré/post MCP documentés ; les modes de validation et de mutation ; les trois stratégies d'application ; l'union des politiques correspondantes ; la validation asynchrone des entrées LLM ; la mutation synchrone, les contrôles de sortie et MCP ; la limitation du streaming pour les garde-fous de sortie LLM ; et les spans de trace. Les modèles de menaces, les portes de déploiement et les modèles d'autorisation d'application sont des pratiques d'ingénierie recommandées.

Commencez par le hook, pas par le détecteur

« Nous avons un détecteur de données personnelles (PII) » ne dit pas grand-chose sur le comportement du système. Où s'exécute-t-il ? Voit-il l'invite avant le modèle, la réponse complète, les arguments de l'outil ou les résultats de l'outil ? Peut-il réécrire les données, seulement les bloquer ou simplement les journaliser ? Que se passe-t-il si le détecteur expire ? Le streaming libère-t-il du contenu avant qu'une réponse complète n'existe ?

La passerelle IA de TrueFoundry expose quatre hooks de garde-fous : Entrée LLM, Sortie LLM, Pré-invocation d'outil MCP et Post-invocation d'outil MCP. Cette topologie est le fondement. Une mutation d'entrée peut masquer des données avant l'exposition au modèle. Un contrôle de sortie peut retenir une réponse complète. Un contrôle pré-outil peut arrêter une opération avant son exécution. Un contrôle post-outil peut empêcher un résultat sensible d'atteindre le modèle, mais ne peut pas annuler un effet secondaire déjà produit par l'outil.

Le diagramme des hooks souligne la portée temporelle. Un contrôle placé après une opération peut régir la divulgation de son résultat, mais ne peut pas empêcher rétroactivement l'opération elle-même.

La validation et la mutation font des promesses différentes

En mode Validation, un garde-fou inspecte les données et peut bloquer sans les réécrire. En mode Mutation, il peut transformer les données et peut également bloquer. Les garde-fous de mutation s'exécutent séquentiellement par priorité, car la sortie de l'un devient l'entrée du suivant.

L'ordre a donc son importance. Une étape de masquage peut supprimer des preuves dont un détecteur ultérieur a besoin, tandis qu'une étape de normalisation peut rendre une politique ultérieure plus fiable. Versionnez et testez la chaîne ordonnée complète. N'interprétez pas « tous les garde-fous ont réussi » sans savoir quelle représentation chacun a évaluée.

Pour les appels MCP, la mutation ou la validation pré-outil voit les arguments avant l'opération. Les contrôles post-outil voient le résultat après l'exécution. Si un outil SQL a déjà modifié une base de données, bloquer sa réponse protège le contexte en aval, mais pas la base de données. La sécurité des effets secondaires nécessite une autorisation, des contrats d'outils contraints, l'idempotence et une réconciliation en plus des garde-fous de contenu.

La stratégie d'application définit le comportement en cas d'échec (fail-open ou fail-closed)

TrueFoundry documente trois stratégies. « Enforce » bloque en cas de violation et bloque également lorsque le garde-fou lui-même rencontre une erreur. « Enforce But Ignore On Error » bloque les violations détectées mais laisse passer le trafic si le garde-fou échoue. « Audit » laisse passer le trafic et enregistre à la fois les résultats et les erreurs du garde-fou.

Ces choix doivent être faits par hook et par risque, et non comme une préférence organisationnelle universelle. Un contrôle d'autorisation pré-outil strict pour une opération de production destructrice peut nécessiter un comportement « fail-closed ». Un scoreur de pertinence auxiliaire sur un assistant interne à faible risque peut être autorisé à se dégrader. La décision doit identifier le préjudice d'un faux négatif, le préjudice d'un faux positif, la fiabilité du détecteur et le repli disponible.

Le mode de fonctionnement et la stratégie d'application sont orthogonaux. Les équipes ont besoin de ces deux axes pour savoir si les données sont réécrites, bloquées, autorisées en cas d'erreur ou simplement observées.

L'ordre d'exécution influe sur la latence et les coûts

TrueFoundry documente la mutation des entrées comme étant synchrone avant la requête au modèle. La validation des entrées peut s'exécuter en parallèle de l'appel au modèle. Si la validation échoue pendant que le modèle tourne, la passerelle annule cette requête. La mutation et la validation des sorties interviennent après la réponse du modèle ; leur latence se situe donc sur le chemin de retour et le coût du modèle a déjà été engagé.

Les garde-fous MCP avant et après l'outil s'exécutent de manière synchrone. La latence avant l'outil retarde l'exécution mais peut éviter le coût et les effets secondaires d'un appel inapproprié. La latence après l'outil retarde la livraison du résultat et peut permettre de le masquer ou de le retenir, mais l'invocation de l'outil a déjà eu lieu.

Moment du hookCe que le blocage empêcheCe qu'il ne peut pas annulerEntrée LLMMutation avant le modèle ; la validation peut chevaucher l'exécution du modèle.Un prompt non sécurisé atteignant ou s'exécutant sur le modèle, selon le mode.Travail déjà effectué avant une annulation tardive par validation.Sortie LLMAprès la réponse complète du modèle.Contenu rejeté atteignant le client.Coût du modèle déjà engagé.Pré-invocation MCPAvant chaque appel d'outil.L'appel d'outil et son effet secondaire.Effets des appels précédents dans la trajectoire.Post-invocation MCPAprès le retour de l'outil.Résultat non sécurisé atteignant le modèle.L'effet déjà produit par l'outil.

Le streaming modifie la garantie de sortie

La documentation actuelle de TrueFoundry indique que les garde-fous de sortie LLM sont ignorés pour les réponses en streaming, car la passerelle ne dispose pas d'une réponse complète à évaluer avant que les segments ne soient transmis. Les garde-fous d'entrée restent applicables. Si un cas d'usage nécessite des contrôles de sortie côté passerelle, la requête ne doit pas être en streaming.

Il s'agit d'une décision architecturale majeure, pas d'une simple note de bas de page. Un client qui assemble une sortie en streaming et la valide ensuite peut détecter un problème, mais il ne peut pas rétracter un contenu déjà affiché ou utilisé. Les applications doivent choisir entre une livraison immédiate des jetons et une application des règles sur la réponse complète, ou concevoir un tampon intermédiaire qui retarde la diffusion.

La portée détermine les éléments visibles par le détecteur

Pour les messages LLM, TrueFoundry documente un contrôle de portée couvrant l'intégralité de la conversation, le dernier message ou les N derniers messages. Une fenêtre étroite réduit les coûts et l'exposition, mais peut laisser passer des attaques réparties sur plusieurs échanges. Un contrôle sur l'historique complet peut être coûteux et risque d'envoyer davantage de données sensibles à un fournisseur de garde-fous externe.

Les prompts système sont exclus des garde-fous par défaut dans la documentation actuelle, avec une exception nommée pour l'analyse CrowdStrike AIDR. Les contrôles MCP avant/après analysent l'intégralité des arguments ou des résultats de l'outil plutôt que d'utiliser la portée des messages LLM. Les équipes doivent documenter explicitement ces limites de visibilité afin que l'affirmation « la conversation est protégée » n'implique pas que chaque instruction et chaque champ ont été inspectés.

La correspondance des politiques se compose par union

Les garde-fous peuvent être associés à chaque requête via un en-tête ou des politiques de passerelle. Les politiques correspondent aux modèles, aux serveurs et outils MCP, aux utilisateurs, aux équipes, aux comptes virtuels et aux métadonnées de requête. TrueFoundry documente que toutes les règles sont évaluées ; les garde-fous issus de chaque règle correspondante sont combinés par hook.

Ce modèle d'union est additif. Une base de référence large peut appliquer la détection de données personnelles (PII), tandis qu'une règle de métadonnées de production ajoute un détecteur d'injection plus strict et qu'une règle spécifique à un outil MCP ajoute une politique SQL. Les conditions de cible ou de sujet omises correspondent largement ; une règle accidentellement incomplète peut donc s'appliquer plus largement que prévu.

Les en-têtes de garde-fous par requête contournent les politiques, selon la documentation de configuration. Contrôlez qui peut envoyer ces en-têtes et déterminez si les garde-fous choisis par l'application sont acceptables pour la charge de travail. Une requête ne devrait pas pouvoir sélectionner une politique plus faible simplement parce qu'elle connaît le nom d'une intégration.

Les règles de politique se composent de manière additive. Le contrôle effectif est l'union résolue pour ce sujet, cette cible, cet outil, ces métadonnées et ce hook — et non une règle isolée prise individuellement.

Les traces sont la preuve d'une exécution, pas la preuve de la sécurité

TrueFoundry enregistre l'exécution des garde-fous sous forme de segments dans les traces de requêtes, incluant les temps de réponse et les résultats. Les requêtes bloquées sont également tracées. Cela permet d'inspecter la latence, les résultats, les mutations et les conséquences de l'application des règles.

Un segment prouve qu'un garde-fou configuré a été exécuté et a rapporté un résultat dans le cadre d'une configuration versionnée. Il ne prouve pas que le détecteur offrait une couverture parfaite ou que l'action métier finale était sécurisée. Conservez la version du détecteur, la version de la politique, le hook, la portée, l'empreinte de l'entrée, l'empreinte de la mutation, le résultat de l'application, l'erreur et la latence. Associez ces enregistrements aux tentatives d'outils et aux résultats faisant autorité.

Les fournisseurs de garde-fous créent un chemin de traitement des données

Certains garde-fous s'exécutent sur l'infrastructure gérée par TrueFoundry ; d'autres font appel à des fournisseurs externes ou à des services personnalisés. Le hook sélectionné et la portée du message déterminent les données que ce processeur peut recevoir. Avant d'activer un fournisseur, documentez les champs, les régions, la rétention, le chiffrement, les sous-traitants, les identifiants, le comportement en cas de délai d'attente et si le service utilise les entrées pour l'entraînement.

Réduisez les données avant qu'elles ne quittent la passerelle lorsque cela est possible. Une étape de mutation locale peut supprimer les secrets avant l'exécution d'un classificateur externe plus large, mais l'ordre doit être testé afin que la rédaction ne détruise pas le signal nécessaire à la détection. Adaptez la sélection du fournisseur à l'environnement : la documentation de TrueFoundry indique que plusieurs outils intégrés gérés sont réservés au mode SaaS et oriente les déploiements auto-hébergés vers des alternatives.

Versionnez le plan de contrôle résolu

Une requête peut correspondre à plusieurs règles de politique, et chaque règle peut associer plusieurs garde-fous à plusieurs hooks. Le plan effectif est donc un ensemble résolu, et non simplement un nom de politique. Enregistrez les identifiants de règle, la version de la politique, les versions d'intégration, les priorités, les stratégies d'application, la portée et le comportement d'erreur personnalisé qui s'appliquaient à la requête.

Promouvez les changements de garde-fous comme des versions logicielles. Testez un plan candidat en mode audit ou analyse fantôme, comparez-le avec le plan actuel sur des entrées représentatives capturées, examinez les faux positifs et les faux négatifs, puis déployez-le sur un trafic limité. Une restauration doit rétablir la configuration résolue complète, y compris l'ordre et la sémantique en cas d'échec.

Les métriques opérationnelles nécessitent des dénominateurs

Comptez les requêtes évaluées, les hooks ignorés, les erreurs de garde-fous, les délais d'attente, les violations, les mutations, les blocages, les annulations et la latence par intégration et par version de politique. Rapportez les taux sur le trafic éligible plutôt que sur le nombre brut de blocages. Un détecteur affichant zéro résultat n'est sain que s'il a réellement été exécuté sur la portée prévue.

Pour les contrôles MCP, associez les blocages pré-outil aux appels d'outils tentés et les résultats post-outil aux résultats des outils. Pour les contrôles LLM, distinguez les annulations d'entrées, les rejets de sorties et les réponses en flux où les vérifications de sortie ont été ignorées. Échantillonnez le trafic autorisé pour une révision humaine afin que les faux négatifs silencieux puissent être détectés.

Passez de l'observation à l'application

Le mode audit est utile pour le calibrage car il montre les résultats potentiels sans bloquer. Avant la promotion, étiquetez le trafic échantillonné, mesurez les faux positifs et les faux négatifs, testez les délais d'attente des fournisseurs et estimez la latence et le coût. Passez à une stratégie d'application uniquement après que l'organisation a choisi le comportement en cas d'échec et qu'un opérateur peut interpréter les preuves.

Ne supposez pas qu'une baisse du taux de blocage signifie que le système s'est amélioré. Cela peut aussi signifier qu'un détecteur a cessé de fonctionner, que la portée a été réduite, que le trafic a changé ou que les utilisateurs ont appris à contourner le contrôle. Surveillez la couverture et les taux d'erreur parallèlement aux violations.

Tests d'échec exposant de réelles lacunes

• Diffusez une réponse avec un garde-fou de sortie configuré et vérifiez que l'omission documentée est visible par les opérateurs.
• Appliquez un délai d'attente à chaque garde-fou pour chaque stratégie d'application.
• Appliquez plusieurs politiques correspondantes et confirmez que leurs garde-fous sont réunis par hook.
• Omettez les filtres de cible et de sujet ; vérifiez que la correspondance large de la règle est comprise.
• Distribuez une injection de prompt sur plusieurs messages et comparez la portée du dernier message, des N derniers messages et de tous les messages.
• Bloquez le résultat d'un outil post-traitement après la réussite d'un outil de mutation ; vérifiez que l'effet externe est toujours réconcilié.
• Modifiez la priorité de mutation et testez si les détecteurs en aval perçoivent un contenu sensiblement différent.

La règle opérationnelle

Le véritable contrat d'une barrière de sécurité (guardrail) repose sur la combinaison du hook, de la visibilité, du mode, de l'ordre, de la stratégie d'application, de la correspondance des politiques et du comportement en cas d'échec. Ne nommer que le détecteur laisse la majeure partie du système indéfinie.

TrueFoundry AI Gateway rend ces décisions explicites pour le trafic des modèles comme pour celui des MCP, et enregistre leur exécution dans des traces. L'application conserve la responsabilité de l'autorisation métier, de la correction des effets secondaires et de la preuve des résultats. Cette limite n'est pas une faiblesse ; c'est ce qui empêche de confondre l'inspection de contenu avec une sécurité complète des agents.

Références

1. TrueFoundry — Présentation des barrières de sécurité (Guardrails) de l'AI Gateway.
2. TrueFoundry — Configurer les politiques de barrières de sécurité.
3. TrueFoundry — Journaux de requêtes : Inspection des traces.

Note éditoriale. Cet article reflète l'interprétation technique de TrueFoundry concernant les documents publics cités au 19 septembre 2026. Les fonctionnalités du produit sont limitées à la documentation liée. Les exemples et les paramètres par défaut sont fournis à titre illustratif ; ils ne constituent ni un conseil juridique, ni un avis d'audit, ni une référence indépendante, ni une garantie de sécurité, de sûreté ou de conformité.

‍