Comment configurer les barrières de protection sur l'AI Gateway

Pourquoi intégrer des garde-fous à la passerelle

Un point de terminaison de modèle brut peut facilement renvoyer des données personnelles, accepter une charge utile d'injection de requête ou fournir une réponse non sécurisée. Les garde-fous corrigent cela en inspectant et, si nécessaire, en réécrivant le trafic avant qu'il n'atteigne le modèle et avant que la réponse ne parvienne à l'utilisateur.

L'intégration de garde-fous sur l'AI Gateway garantit que chaque application bénéficie automatiquement de la même protection, sans que chaque équipe n'ait à réimplémenter des mesures de sécurité. TrueFoundry propose des garde-fous intégrés pour la rédaction des PII et la détection des injections de requêtes, entièrement gérés et sans clé tierce à configurer.

Le modèle en deux étapes : enregistrement, puis politique

Comme l'indique la documentation sur les garde-fous , l'application de garde-fous sur l'AI Gateway se fait en deux étapes.

• Enregistrez les garde-fous. Accédez à AI Gateway, puis à Guardrails, créez un groupe de garde-fous et ajoutez les intégrations souhaitées, qu'il s'agisse de solutions intégrées TrueFoundry, de fournisseurs externes ou de garde-fous personnalisés.
  

• Configurez les politiques. Accédez à AI Gateway, puis à Policies, puis à Guardrails, et créez des règles déterminant quels garde-fous appliquer et sur quels points d'ancrage (hooks) ils doivent s'exécuter.

Création d'une règle de garde-fou

Dans Policies, puis Guardrails, cliquez sur Add Rule. Chaque règle possède un identifiant unique et plusieurs sections déterminant à qui elle s'applique et où elle s'exécute.

• Lorsque la requête est adressée à (cibles). Faites correspondre un ou plusieurs modèles, ou des serveurs MCP, voire des outils spécifiques. Les conditions de ciblage multiples sont combinées par un OU logique ; la règle s'applique donc si la requête est adressée à l'un des modèles ou serveurs MCP listés. L'absence de cible signifie que la règle s'applique à tous les modèles.
  

• Depuis les sujets. Filtrez par utilisateurs, équipes ou comptes virtuels avec les conditions IN ou NOT IN. L'absence de filtre sur le sujet signifie que la règle s'applique à tous les appelants.
  

• Avec métadonnées. Faites correspondre les paires clé-valeur envoyées dans l'en-tête X-TFY-METADATA, par exemple environment production.
  

• Appliquer sur les hooks. Choisissez le hook et sélectionnez les garde-fous à exécuter dessus. Vous pouvez associer plusieurs garde-fous au même hook, et ils seront tous exécutés pour les requêtes correspondantes.

Les quatre hooks

• Entrée LLM s'exécute avant que le prompt ne soit envoyé au modèle.
  

• Sortie LLM s'exécute après la réponse du modèle, avant que celle-ci ne soit renvoyée.
  

• Pré-invocation d'outil MCP s'exécute avant l'exécution d'un outil MCP.
  

• Post-invocation d'outil MCP s'exécute après le retour d'un outil MCP, avant que le résultat n'atteigne le modèle.

Toutes les règles sont évaluées pour chaque requête, et les garde-fous de toutes les règles correspondantes sont combinés et appliqués ensemble. Si une règle applique la détection d'informations personnelles (PII) sur l'entrée LLM et qu'une autre applique la détection d'injection de prompt sur l'entrée LLM, les deux seront exécutées.

Want the same safety on every LLM and tool call?

We will configure PII redaction and prompt-injection defense on your gateway, live.

Book a demo

Configuration de la rédaction des PII et PHI

LaGarde-fou de détection des PII et PHI est un garde-fou intégré à TrueFoundry qui identifie et occulte les informations personnellement identifiables (PII) et les informations de santé protégées (PHI). Il est alimenté par la détection PII d'Azure AI Language et est entièrement géré, il n'y a donc aucune clé API tierce à fournir.

Il ne prend en charge que le mode de mutation, ce qui signifie qu'il occulte toujours les entités détectées. Dans le formulaire de configuration, vous définissez un nom, choisissez les catégories de PII ou conservez la valeur par défaut (toutes les catégories), et sélectionnez une stratégie d'application. Les valeurs détectées sont remplacées par des astérisques ; ainsi, un numéro de téléphone et une adresse e-mail dans un message sont masqués avant même que le modèle ne puisse les voir.

Une configuration courante applique la rédaction des PII sur l'entrée LLM pour nettoyer les messages des utilisateurs, sur la sortie LLM pour nettoyer les réponses, et sur les hooks MCP pour supprimer les PII des paramètres et des résultats d'outils, tels que les lignes de base de données.

Configuration de la défense contre l'injection de prompts

Labarrière de protection contre l'injection de prompts est une barrière de protection intégrée basée sur Azure Prompt Shield. Elle détecte les injections directes de prompts, les attaques de type « jailbreak » comme le modèle « do anything now », ainsi que les injections indirectes dissimulées dans des documents ou du contenu contextuel. Elle analyse séparément le prompt de l'utilisateur et le contenu du document.

Elle ne prend en charge que le mode de validation, ce qui signifie qu'elle détecte et bloque les attaques sans modifier le contenu. La configuration ne requiert qu'un nom et une stratégie d'application. La documentation recommande de commencer par la stratégie d'audit pour surveiller les détections dans les traces de requêtes, puis de passer au mode « enforce » une fois que vous avez confiance dans le système.

Comment la passerelle exécute les barrières de protection sur une requête

Lors d'une requête LLM, les barrières de protection de mutation d'entrée s'exécutent en premier et bloquent le processus jusqu'à leur achèvement, par exemple pour masquer les PII dans le prompt. La validation d'entrée, telle que celle contre l'injection de prompts, s'exécute ensuite en arrière-plan pendant que la requête au modèle est en cours. Si la validation d'entrée échoue alors que le modèle est toujours en cours d'exécution, la passerelle annule immédiatement la requête au modèle afin que vous n'ayez pas à la payer.

Une fois que le modèle a répondu, la mutation de sortie peut supprimer les secrets, et la validation de sortie vérifie le résultat final avant qu'il n'atteigne le client. Pour les outils MCP, toutes les barrières de protection préalables à l'outil s'exécutent avant l'appel de l'outil ; si l'une d'elles échoue, l'outil n'est jamais exécuté. Les barrières de protection s'exécutent séparément pour chaque appel d'outil.

Make guardrails standard across every team

See centralized PII and injection policies applied to all apps, with full tracing, on your infrastructure.

Talk to an Expert