Intégration de Pillar Security à TrueFoundry

‍Nous sommes ravis d'annoncer notre partenariat avec Pillar Security, qui intègre des barrières d'exécution adaptatives directement au trafic des agents d'IA et du LLM.

Les équipes qui acheminent le trafic des modèles et des agents via la passerelle IA de TrueFoundry peuvent désormais connecter Pillar Security en tant que fournisseur de garde-corps de premier ordre pour bénéficier d'une analyse en temps réel et de l'application des politiques en matière de demandes et de réponses, d'appels d'outils et d'interactions MCP en production. L'intégration s'exécute au niveau des quatre crochets de sécurité exposés par la passerelle et ne nécessite aucune modification du code de l'agent ou de l'application.

Cet article traite de l'architecture de l'intégration. Il explique comment TrueFoundry AI Gateway exécute des garde-fous lors de l'exécution, comment le pipeline de scanners de Pillar s'intègre à ce modèle d'exécution et comment les équipes configurent des règles qui ciblent des modèles spécifiques, des serveurs MCP et des populations d'utilisateurs.

Pourquoi l'IA agentique d'entreprise a besoin de deux couches

True Foundry fournit la couche de contrôle pour les systèmes d'IA de production. Grâce à AI Gateway, les équipes centralisent le routage des modèles et la gestion des clés, ainsi que le contrôle d'accès, l'observabilité et la gouvernance des LLM, des outils et des flux de travail connectés au MCP. Chaque demande passe par une couche proxy unique où l'identité est vérifiée, les limites de débit sont appliquées et les traces sont capturées.

Sécurité des piliers fournit la couche de sécurité d'exécution. Ses modèles de détection analysent les invites et les réponses pour détecter les tentatives de jailbreak et les injections rapides, les données PII et PCI, les secrets, le langage toxique et les attaques de personnages invisibles. Les garde-fous adaptatifs de Pillar s'appuient sur des exercices de collaboration exécutés sur la même application et s'adaptent à l'objectif commercial défini par l'agent afin de réduire les faux positifs.

Ensemble, les deux solutions offrent aux équipes une architecture de production propre. TrueFoundry gère le déploiement, le routage et le contrôle opérationnel. Pillar gère l'inspection de l'exécution, la détection des menaces et l'application des politiques. Pillar Security est pris en charge en tant que fournisseur de garde-corps de première classe au sein de la passerelle TrueFoundry avec des crochets à llm_input_guardrails et llm_output_guardrails et mcp_tool_pre_invoke_guardrails et mcp_tool_post_invoke_guardrails.

L'écart entre les déploiements d'agents de production

La plupart des équipes qui créent des agents d'IA se concentrent sur le bon déploiement et la fiabilité. L'agent doit utiliser les bons outils, gérer le contexte des longues conversations, gérer les nouvelles tentatives et s'adapter à tous les utilisateurs. Ce travail est nécessaire mais ne répond pas à la question de sécurité de l'exécution.

Dans de nombreux déploiements d'IA agentiques, la sécurité s'arrête au périmètre. Les contrôles d'accès à la plateforme, les listes d'autorisation des serveurs MCP, les autorisations au niveau des outils et les informations d'identification étendues pour les systèmes en aval sont tous en place. Ces contrôles sont importants, mais ils laissent le chemin d'exécution non inspecté.

Les questions auxquelles le périmètre ne peut pas répondre incluent ce que fait réellement l'agent une fois qu'il commence à s'exécuter, quels outils il appelle, dans quel ordre et avec quelles données. Si une injection rapide se produit par le biais d'un contexte récupéré, d'une réponse d'un serveur MCP ou d'un résultat d'API externe, le périmètre n'a aucune visibilité quant à savoir si l'agent est sur le point d'agir en conséquence.

Gardes-corps d'exécution sur le chemin de la passerelle

L'idée architecturale qui sous-tend cette intégration est directe. Si tout le trafic des modèles, des outils et du MCP passe déjà par la passerelle, celle-ci est le bon endroit pour appliquer la sécurité d'exécution. En connectant Pillar à TrueFoundry AI Gateway, les équipes peuvent appliquer des garde-fous sur le même chemin que celui où le trafic des agents est déjà acheminé et régi. L'évaluation se fait sur le trafic en temps réel et non sur les traces examinées après l'exécution.

Pillar Argus fonctionne en tant que couche d'exécution adaptative. Pillar applique ses scanners à chaque interaction en production afin que les équipes chargées de la plateforme et de la sécurité puissent surveiller, évaluer et appliquer la politique sur le comportement des agents pendant qu'elle se produit. Les sorties du scanner comprennent un identifiant de session et un booléen marqué, les déclencheurs par catégorie et un tableau de preuves avec le texte incriminé et sa position dans l'entrée.

Pillar expose les catégories de détection suivantes lors de l'exécution. Détection de jailbreak identifie les tentatives visant à contourner la formation à la sécurité du modèle. Injection rapide la détection couvre à la fois l'injection directe et indirecte via le contexte récupéré ou la sortie de l'outil. Détection PII et PCI couvre plus de quarante catégories de données personnelles et de cartes de paiement et prend en charge le masquage avant que les données n'atteignent le modèle. Détection secrète identifie les clés, les jetons et les informations d'identification d'API dans les invites ou dans la sortie du modèle. Modération du contenu et langage toxique la détection couvre les contenus dangereux et violant les politiques. Personnage invisible la détection détecte les charges utiles Unicode dissimulées utilisées pour faire passer des instructions en contrebande après examen humain.

Pour les systèmes agentiques, Pillar évalue non seulement une seule paire d'invite et de réponse, mais aussi les appels d'outils, les requêtes MCP et le contexte d'exécution en plusieurs étapes. De nombreuses défaillances de l'IA agentique apparaissent tout au long de la chaîne d'actions et non pas dans le cadre d'un seul modèle.

Comment la passerelle exécute les garde-corps

La passerelle TrueFoundry AI s'exécute sur le framework Hono et un seul pod de passerelle gère plus de 250 demandes par seconde sur 1 processeur virtuel et 1 Go de RAM avec environ 3 ms de latence supplémentaire. Les pods de passerelle sont sans état et liés au processeur et s'adaptent horizontalement à des dizaines de milliers de RPS via des pods supplémentaires. Le plan de contrôle et le plan de passerelle sont séparés. La configuration, y compris les règles de garde-corps, les définitions de modèles et les limites de débit, se trouve dans le plan de contrôle et se synchronise avec les modules de passerelle via le NATS. Le chemin de demande réel reste en mémoire sans appel externe au-delà du fournisseur LLM.

Les garde-corps s'exécutent au niveau de quatre crochets distincts au cours du cycle de vie de la demande.

llm_input_guardrails intercepte une invite avant qu'elle n'atteigne le modèle. La passerelle envoie d'abord la charge utile d'entrée à Pillar. Si Pillar revient marqué : vrai pour tout scanner configuré, la demande est bloquée et le LLM n'est jamais appelé. L'appel de sécurité en entrée est exécuté en même temps que la demande de modèle afin d'optimiser le délai jusqu'au premier jeton et l'appel modèle est annulé immédiatement en cas de violation afin d'éviter des frais pour le fournisseur.

llm_output_guardrails se déclenche une fois que le LLM a répondu mais avant que la réponse ne soit renvoyée à l'appelant. Les garde-corps de sortie sont séquentiels. La passerelle attend le résultat du modèle et le soumet à Pillar pour numérisation avant de le livrer au client. Il s'agit du point d'application pour détecter les fuites d'informations personnelles, l'exposition à des secrets, la génération de substances toxiques et tout contenu dangereux produit par le modèle.

mcp_tool_pre_invoke_guardrails se déclenche avant qu'un outil ne soit exécuté par l'agent. Pillar évalue le nom de l'outil, les arguments et le contexte d'appel. Si les arguments contiennent des données sensibles ou indiquent un accès aux ressources hors champ, l'invocation de l'outil est bloquée avant qu'une action réelle ne se produise.

mcp_tool_post_invoke_guardrails se déclenche une fois que l'outil a renvoyé son résultat et avant que ce résultat ne soit renvoyé dans la boucle de raisonnement de l'agent. Il s'agit du point d'application permettant de détecter les injections rapides indirectes dans la sortie de l'outil et les fuites d'informations d'identification provenant des serveurs MCP et des informations d'identification personnelles renvoyées par les API en amont. L'arrêter ici empêche l'agent d'agir dans un contexte empoisonné.

Chaque hameçon prend en charge trois stratégies d'application. Faire appliquer bloque en cas de violation ou d'erreur de service de garde-corps. Appliquer mais ignorer en cas d'erreur bloque en cas de violation mais autorise le traitement de la demande si le service de garde-corps lui-même est inaccessible. Audit enregistre le verdict et ne bloque jamais. Chaque garde-corps prend également en charge deux modes de fonctionnement. Valider le mode produit une décision de blocage ou de passage. Muter le mode permet au service de garde-corps de modifier le contenu en vol, c'est ainsi que la capacité de masquage de Pillar est intégrée. Le mode Masque est configuré du côté du pilier et affiche les valeurs expurgées pour les informations personnelles et les secrets correspondants avant que l'invite n'atteigne le modèle.

La surface d'intégration

Pillar est configuré dans le plan de contrôle TrueFoundry comme une intégration de garde-corps avec deux entrées. La première est la clé API émise par la console Pillar. La seconde est la configuration du scanner qui sélectionne les catégories de détection à exécuter pour cette intégration.

FieldValue ProviderPillar Security Endpointhttps://api.pillar.security/api/v1/integrations/truefoundryJeton AuthenticationBearer via PILLAR_API_KEYScanneursjailbreak et injectation_rapide et pii et secret et langage_toxique et modération du contenu et personnage_invisibleModes de fonctionnement Valider et modifier le format de réponse{session_id, marqué, scanners, preuves}

Une fois l'intégration enregistrée, la passerelle l'expose sous la forme d'un sélecteur qui peut être référencé à partir de n'importe quelle règle de sécurité. Les règles sont configurées via un bloc de règles YAML. Chaque règle utilise un bloc when avec deux conditions. cible correspond au modèle, aux serveurs MCP ou aux outils MCP ou demande des métadonnées. sujets correspond à l'identité de l'utilisateur ou de l'équipe avec les opérateurs in et not_in. La règle déclare ensuite quelles intégrations de garde-corps doivent être exécutées sur lequel des quatre crochets.

Voici une règle de base qui exécute Pillar en entrée et en sortie pour un modèle OpenAI utilisé par toutes les équipes.

nom : guardrails-control
type : gateway-guardrails-config
règles :
- identifiant : pillar-baseline
quand :
cible :
opérateur : ou
conditions :
modèle :
valeurs :
- openai-main/gpt-4o
État : en
sujets :
opérateur : et
conditions :
dans :
- équipe : tout le monde
llm_input_guardrails :
- profil par défaut du pilier ou du pilier
llm_output_guardrails :
- profil par défaut du pilier ou du pilier
mcp_tool_pre_invoke_guardrails : []
mcp_tool_post_invoke_guardrails : []


Une deuxième règle qui ajoute l'analyse Pillar autour d'un serveur MCP utilisé par une équipe d'agents ciblerait le serveur MCP et appliquerait l'intégration aux hooks d'invocation de l'outil avant et après son invocation. Toutes les règles correspondantes sont évaluées ensemble et leurs ensembles de garde-corps sont regroupés par crochet. Deux règles qui visent toutes deux llm_input_guardrails s'exécuteront tous les deux sur l'entrée.

Les dérogations par demande sont prises en charge via GARDE-CORPS X-TFY en-tête. L'en-tête contient un objet JSON spécifiant des sélecteurs de garde-corps pour n'importe quelle combinaison des quatre crochets. Cela permet aux équipes d'application de définir une politique plus stricte ou plus permissive pour un appel spécifique sans modifier la configuration globale.

Chaque décision de sauvegarde est enregistrée dans la trace des demandes. Le span inclut le hook qui s'est déclenché et le sélecteur d'intégration, le verdict et la latence de l'appel de sécurité et les preuves renvoyées par Pillar. Les traces sont émises de manière asynchrone via NATS et exportées via OTEL vers le backend d'observabilité configuré par l'équipe. Le tableau de bord de Pillar affiche les mêmes événements de son côté, avec des transcriptions complètes des attaques et des ventilations par catégories pour l'examen de la conformité.

Résumé de l'architecture

Le flux de requêtes de bout en bout ressemble à ceci. Un client envoie une fin de discussion ou une demande d'agent à la passerelle. La passerelle authentifie l'appelant à l'aide des clés IdP mises en cache et résout l'identifiant du modèle via le routage du modèle virtuel. Les règles de garde-corps correspondantes sont évaluées en mémoire et la charge utile d'entrée est envoyée à Pillar en même temps que l'appel de modèle. Si Pillar signale l'entrée, l'appel de modèle est annulé et une erreur structurée est renvoyée. Si l'entrée est propre, la réponse du modèle est attendue et soumise aux scanners de sortie de Pillar avant la livraison. Pour le trafic des agents, la même logique s'applique à chaque appel d'outil MCP et à chaque réponse de l'outil avant qu'il ne rentre dans le contexte de l'agent. Chaque étape est enregistrée dans un traçage avec le verdict du garde-corps joint.

Rien d'autre ne doit changer dans l'application. Il n'y a aucun SDK à installer sur le client, aucun side-car à déployer parallèlement à l'agent et aucun middleware de sécurité par service à gérer. La passerelle se trouve déjà dans le chemin de demande et Pillar s'y connecte via son API. Le code client compatible OpenAI existant continue de fonctionner sans modification.

Le principe architectural qui permet de remédier à cette situation est la consolidation de l'application des politiques au niveau de la passerelle. Lorsque le trafic des modèles, le trafic des outils et le trafic MCP convergent tous vers un seul proxy, les barrières configurées sur ce proxy s'appliquent de manière uniforme à chaque modèle, à chaque équipe et à chaque agent, sans code par application. Les scanners de Pillar fonctionnent en ligne au même point et le modèle de crochet de la passerelle permet à Pillar d'accéder aux quatre points d'application où les décisions d'exécution sont réellement importantes.

Commencez

En savoir plus sur Passerelle TrueFoundry AI et le Plateforme Pillar Security. Connectez Pillar à la configuration TrueFoundry Guardrails et référencez le sélecteur d'intégration à partir de n'importe quelle règle qui cible vos modèles ou serveurs MCP.