Intégration de l'IA opérante à TrueFoundry

‍Nous sommes ravis d'annoncer notre partenariat avec Operant AI, qui intègre la défense de l'IA à l'exécution et la rédaction des données en ligne directement dans le parcours du LLM et du trafic des agents.

Les équipes qui acheminent le trafic des modèles et des agents via la passerelle IA de TrueFoundry peuvent désormais connecter Operant AI Gatekeeper en tant que fournisseur de garde-corps de premier ordre pour bénéficier d'une détection des menaces en temps réel, d'une rédaction automatique en ligne et d'une application Zero Trust pour les invites et les réponses, les appels d'outils et les 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 moteur de défense d'exécution d'Operant s'intègre à ce modèle d'exécution et comment les équipes configurent des règles qui ciblent des modèles, des serveurs MCP et des populations d'utilisateurs spécifiques.

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.

IA opérante fournit la couche de défense à l'exécution. Son moteur 3D Runtime Defense découvre, détecte et défend les modèles d'attaque complets de l'OWASP LLM Top 10 et du MITRE ATLAS. AI Gatekeeper s'exécute de manière native dans la pile d'applications et applique une rédaction automatique en ligne pour les données PII, PCI et PHI, ainsi que pour les secrets et les clés d'API avant que les données ne franchissent les limites. Operant est le seul fournisseur cité parmi les cinq rapports les plus critiques de Gartner sur la sécurité de l'IA, qui concernent le TRisM et la protection des API, ainsi que les passerelles MCP et la sécurité des agents.

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. Operant gère l'inspection de l'exécution, la rédaction en ligne et l'application des menaces comportementales. Operant AI Gatekeeper 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 des données non inspecté et la boucle de raisonnement de l'agent n'est pas protégée.

Les questions auxquelles le périmètre ne peut pas répondre incluent les données qui circulent réellement dans le modèle et celles qui en sortent dans la réponse, ainsi que les outils que l'agent appelle et avec quels arguments. Si une injection rapide arrive par le biais d'un contexte récupéré, d'une réponse du 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. Si la sortie du modèle contient un e-mail client ou une clé secrète AWS, le périmètre ne peut pas arrêter la fuite avant qu'elle ne quitte l'environnement.

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 défense contre l'exécution. Avec Operant connecté à TrueFoundry AI Gateway, les équipes appliquent 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.

Operant AI Gatekeeper fonctionne en tant que couche de défense lors de l'exécution. Le moteur de défense se déploie de manière native dans l'environnement de l'application via une installation Helm en une seule étape et applique ses scanners et sa logique de rédaction en place. Comme le moteur fonctionne de manière native, aucun appel externe n'est requis pour prendre une décision et l'ensemble du flux de données reste dans l'environnement du client. C'est la base de ce que Operant appelle le mode privé, dans lequel les données sensibles sont expurgées à l'entrée et à la sortie avant même de quitter le cluster.

Operant expose les capacités de défense suivantes lors de l'exécution. Rédaction automatique en ligne identifie et masque plus de quarante catégories de données sensibles couvrant les PII, les clés PCI, PHI et API, les jetons et les informations d'identification avant que ces données n'atteignent le modèle ou ne quittent l'environnement. Détection rapide des injections couvre à la fois l'injection directe et indirecte via le contexte récupéré ou la sortie de l'outil. Détection de jailbreak identifie les tentatives visant à contourner la formation à la sécurité des modèles. Défense contre l'exfiltration de données surveille les flux sortants pour détecter tout mouvement non autorisé de données sensibles. Détection de l'empoisonnement des outils est spécialement conçu pour MCP et identifie les descriptions d'outils utilisés comme armes, les enregistrements d'outils malveillants et les fichiers binaires d'outils compromis. Détection des menaces comportementales signale les écarts par rapport à l'objectif commercial défini par chaque agent. Contrôles de l'identité non humaine appliquez l'application Zero Trust aux identités des agents et des services, aux outils d'appel et aux API.

Pour les systèmes agentiques, Operant évalue non seulement une seule paire d'invite et de réponse, mais aussi les invocations d'outils et les requêtes MCP, ainsi que le contexte d'exécution en plusieurs étapes. Les graphiques de sécurité de l'IA cartographient les flux de données en temps réel entre les charges de travail d'IA, les agents et les API afin que le moteur de défense dispose du contexte nécessaire pour signaler lorsqu'un agent dépasse sa limite de confiance autorisée.

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 à Operant. Si Operant renvoie un verdict de violation pour un détecteur configuré, la demande est bloquée et le LLM n'est jamais appelé. Si Operant s'exécute en mode mutation, la charge utile supprimée est renvoyée et la passerelle transmet la version masquée au modèle. 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 immédiatement annulé en cas de décision de blocage 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 la sortie du modèle et la soumet à Operant pour analyse avant de la livrer au client. Il s'agit du point d'application pour détecter les fuites d'informations personnelles et l'exposition à des secrets, ainsi que toute tentative d'exfiltration de données produite par le modèle. La rédaction de sortie d'Operant supprime les données sensibles de la réponse avant qu'elles ne quittent l'environnement.

mcp_tool_pre_invoke_guardrails se déclenche avant qu'un outil ne soit exécuté par l'agent. Operant évalue le nom de l'outil, les arguments et l'identité non humaine appelante. Si la description de l'outil contient des instructions injectées, si les arguments contiennent des données sensibles ou si l'identité de l'appelant fonctionne en dehors de sa limite de confiance autorisée, l'invocation de l'outil est bloquée avant qu'une action réelle ne se produise. Il s'agit du point d'application qui détecte l'empoisonnement de l'outil MCP lors de l'exécution.

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. Mutate est la façon dont la rédaction automatique en ligne d'Operant est intégrée. La passerelle transmet la demande à Operant et remplace la charge utile expurgée dans la demande avant de passer au modèle.

La surface d'intégration

Operant est configuré dans le plan de contrôle TrueFoundry en tant que garantie d'intégration avec le point de terminaison de l'API pour le service AI Gatekeeper et les informations d'identification pour le déploiement. Comme Operant se déploie de manière native dans le même environnement que la passerelle, le point de terminaison est généralement une URL de service local en cluster et l'appel de garde-corps réduit la latence réseau.

FieldValueProviderOperant AI Gatekeeper Endpointhttps://api.operant.ai/v1/gatekeeper (ou URL du service local du cluster) Jeton AuthenticationBearer via CLÉ_API OPÉRANTEDétecteursinjectation_rapide et jailbreak et pii et pci et phi et secrets et exfiltration_de_données et empoisonnement_outil et anomalie comportementaleModes de fonctionnement Validate and MutateMutate BehaviorInline : rédaction automatique pour les catégories de données sensibles

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 code YAML règles bloquer. Chaque règle utilise un quand bloc à deux conditions. cible matchs sur modèle ou Serveurs MCP ou Outils MCP ou demandez métadonnées. sujets correspond à l'identité de l'utilisateur ou de l'équipe avec dans et pas_dedans opérateurs. 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 Operant 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 : base de référence opérationnelle
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 opérant/éditeur-opérateur
llm_output_guardrails :
- profil opérant/éditeur-opérateur
mcp_tool_pre_invoke_guardrails : []
mcp_tool_post_invoke_guardrails : []


Une deuxième règle qui ajoute l'analyse opérante 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. Il s'agit de la configuration qui détecte l'empoisonnement des outils et l'exfiltration de données via la sortie de l'outil. 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, ainsi que le verdict et la latence de l'appel de sécurité et les catégories correspondantes. 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 d'Operant affiche les mêmes événements de son côté avec le graphique de sécurité AI montrant les flux de données en temps réel et la télémétrie bloquant les menaces.

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 à Operant en même temps que l'appel de modèle. Si Operant marque l'entrée, l'appel de modèle est annulé et une erreur structurée est renvoyée. Si Operant renvoie une charge utile rédigée, la passerelle transmet la version masquée au modèle. La réponse du modèle est ensuite soumise aux détecteurs de sortie d'Operant pour être rédigée 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 et aucun intergiciel de sécurité par service à gérer. La passerelle se trouve déjà dans le chemin de la demande et Operant s'attache à ce chemin de manière native dans le même environnement. Le code client compatible OpenAI existant continue de fonctionner sans modification. Les données sensibles sont masquées avant qu'elles n'atteignent le modèle et avant même qu'elles ne quittent le cluster.

Le principe architectural qui permet de remédier à cette situation est la consolidation de l'application des politiques au niveau de la couche passerelle, combinée à la rédaction des données en ligne au niveau de la couche d'exécution. 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. Le moteur de défense d'Operant fonctionne en ligne au même point et le modèle de crochet de la passerelle permet à Operant d'accéder aux quatre points d'application où les décisions d'exécution sont réellement importantes. Les données restent dans l'environnement car Operant fonctionne de manière native dans la pile au lieu de faire appel à un service d'analyse externe.

Commencez

En savoir plus sur Passerelle TrueFoundry AI et le Plateforme Operant AI Gatekeeper. Connectez Operant à 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.