Integración de Pillar Security con TrueFoundry

‍Nos complace anunciar nuestra asociación con Pillar Security, que incorpora barreras de tiempo de ejecución adaptables directamente al tráfico de agentes de IA y LLM.

Los equipos que dirigen el tráfico de modelos y agentes a través de AI Gateway de TrueFoundry ahora pueden conectar a Pillar Security como un proveedor de protección de primera clase para analizar y aplicar políticas en tiempo real mediante indicaciones y respuestas, llamadas de herramientas e interacciones de MCP en producción. La integración se ejecuta en los cuatro ganchos de protección expuestos por la puerta de enlace y no requiere ningún cambio en el código del agente o de la aplicación.

Esta publicación cubre la arquitectura de la integración. En él se explica cómo el portal de IA de TrueFoundry ejecuta las barreras de protección durante el tiempo de ejecución, cómo los escáneres de Pillar se adaptan a ese modelo de ejecución y cómo los equipos configuran las reglas dirigidas a modelos y poblaciones de usuarios de MCP específicos.

Por qué la IA de las agencias empresariales necesita dos capas

True Foundry proporciona la capa de control para los sistemas de IA de producción. A través de AI Gateway, los equipos centralizan el enrutamiento de modelos y la gestión de claves, así como el control de acceso, la observabilidad y la gobernanza en todos los flujos de trabajo relacionados con las LLM y las herramientas y los MCP. Cada solicitud fluye a través de una única capa de proxy donde se verifica la identidad, se aplican los límites de velocidad y se capturan los rastros.

Seguridad de pilares proporciona la capa de seguridad del tiempo de ejecución. Sus modelos de detección escanean las solicitudes y respuestas en busca de intentos de jailbreak e introducen rápidamente datos y secretos de PII y PCI, así como ataques con lenguaje tóxico y personajes invisibles. Los sistemas de protección adaptativos de Pillar se basan en ejercicios de trabajo en equipo en rojo que se ejecutan en la misma aplicación y se adaptan al objetivo empresarial definido por el agente para reducir los falsos positivos.

Juntas, las dos soluciones brindan a los equipos una arquitectura de producción limpia. TrueFoundry se encarga de la implementación, el enrutamiento y el control operativo. Pillar se encarga de la inspección del tiempo de ejecución, la detección de amenazas y la aplicación de políticas. Pillar Security es un proveedor de barandas de primera clase dentro de la puerta de enlace de TrueFoundry con enlaces en barandas llm_input_ y barandales llm_output_ y guardarraíles mcp_tool_pre_invoke_ y guardarraíles mcp_tool_post_invoke_.

La brecha en las implementaciones de agentes de producción

La mayoría de los equipos que crean agentes de IA se centran en lograr la implementación y la confiabilidad correctas. El agente tiene que utilizar las herramientas adecuadas y gestionar el contexto de las conversaciones largas, gestionar los reintentos y escalar entre los usuarios. Este trabajo es necesario, pero no responde a la pregunta de seguridad del tiempo de ejecución.

La seguridad en muchos despliegues de IA de agencias se detiene en el perímetro. Los controles de acceso a la plataforma y las listas de permisos de los servidores MCP, así como los permisos a nivel de herramienta y las credenciales específicas para los sistemas posteriores, están en su lugar. Estos controles son importantes, pero no inspeccionan la ruta de ejecución.

Las preguntas a las que el perímetro no puede responder incluyen qué está haciendo realmente el agente una vez que comienza a ejecutarse y a qué herramientas llama, en qué secuencia y con qué datos. Si aparece un mensaje a través del contexto recuperado, de la respuesta de un servidor MCP o de un resultado de una API externa, el perímetro no puede determinar si el agente está a punto de actuar en consecuencia.

Barandillas de tiempo de ejecución en la ruta de la puerta de enlace

La idea arquitectónica detrás de esta integración es directa. Si todo el tráfico de modelos, herramientas y MCP ya pasa por la puerta de enlace, entonces la puerta de enlace es el lugar adecuado para aplicar la seguridad del tiempo de ejecución. Con Pillar conectado al TrueFoundry AI Gateway, los equipos pueden establecer barreras en la misma ruta por la que el tráfico de agentes ya está siendo dirigido y controlado. La evaluación se realiza con el tráfico en tiempo real y no con los rastros revisados después de la ejecución.

Pillar Argus se ejecuta como la capa de ejecución adaptativa. Pillar aplica sus escáneres a todas las interacciones de la producción para que los equipos de plataforma y seguridad puedan supervisar, evaluar y hacer cumplir las políticas sobre el comportamiento de los agentes mientras se produce. Los resultados del escáner incluyen un identificador de sesión y un booleano marcado, así como los activadores por categoría y una matriz de pruebas con el texto infractor y su posición en la entrada.

Pillar expone las siguientes categorías de detección durante el tiempo de ejecución. Detección de jailbreak identifica los intentos de eludir la formación de seguridad del modelo. Inyección inmediata la detección cubre la inyección directa e indirecta a través del contexto recuperado o la salida de la herramienta. Detección de PII y PCI cubre más de cuarenta categorías de datos personales y de tarjetas de pago y admite el enmascaramiento antes de que los datos lleguen al modelo. Detección de secretos identifica las claves, los tokens y las credenciales de la API en las solicitudes o en la salida del modelo. Moderación de contenido y lenguaje tóxico la detección cubre contenido inseguro y que infringe las políticas. Personaje invisible la detección captura cargas útiles Unicode ocultas que se utilizan para pasar de contrabando instrucciones más allá de la revisión humana.

Para los sistemas de agencia, Pillar evalúa no solo un único par de mensajes y respuestas, sino también las invocaciones de la herramienta y las solicitudes de MCP y el contexto de ejecución de varios pasos. Muchos fallos de inteligencia artificial entre las agencias se producen a lo largo de toda la cadena de acciones y no en una sola llamada modelo.

Cómo ejecuta la puerta de enlace las barandillas

La puerta de enlace de IA de TrueFoundry se ejecuta en el marco Hono y un solo pod de puerta de enlace gestiona más de 250 solicitudes por segundo en 1 vCPU y 1 GB de RAM con aproximadamente 3 ms de latencia adicional. Los pods Gateway no tienen estado y están vinculados a la CPU, y se escalan horizontalmente hasta alcanzar decenas de miles de RPS mediante pods adicionales. El plano de control y el plano de puerta de enlace están divididos. La configuración, incluidas las reglas de protección, las definiciones de modelos y los límites de velocidad, reside en el plano de control y se sincroniza con los módulos de puerta de enlace a través de NATS. La ruta de solicitud real permanece en la memoria sin llamadas externas más allá del proveedor de LLM.

Las barandillas se ejecutan en cuatro enlaces discretos en el ciclo de vida de la solicitud.

barandas llm_input_ intercepta un mensaje antes de que llegue al modelo. La pasarela envía primero la carga útil de entrada a Pillar. Si Pillar regresa marcado: verdadero para cualquier escáner configurado, la solicitud se bloquea y nunca se llama al LLM. La llamada de protección de entrada se ejecuta al mismo tiempo que la solicitud modelo para optimizar el tiempo necesario para obtener el primer token, y la llamada modelo se cancela inmediatamente si se produce una infracción para evitar que el proveedor incurra en gastos.

barandales llm_output_ se activa después de que el LLM haya respondido, pero antes de que la respuesta se devuelva a la persona que llama. Las barandillas de salida son secuenciales. La pasarela espera el resultado del modelo y lo envía a Pillar para que lo escanee antes de entregarlo al cliente. Este es el punto de control para detectar las filtraciones de información de identificación personal, la exposición secreta y la generación de sustancias tóxicas, así como cualquier contenido inseguro producido por el modelo.

guardarraíles mcp_tool_pre_invoke_ se activa antes de que el agente ejecute una herramienta. Pillar evalúa el nombre de la herramienta, los argumentos y el contexto de la llamada. Si los argumentos contienen datos confidenciales o indican que el acceso a los recursos está fuera del alcance, la invocación de la herramienta se bloquea antes de que se produzca cualquier acción en el mundo real.

guardarraíles mcp_tool_post_invoke_ se activa después de que la herramienta devuelva su resultado y antes de que ese resultado vuelva al ciclo de razonamiento del agente. Este es el punto de referencia para detectar la inyección rápida e indirecta en los resultados de la herramienta y la fuga de credenciales de los servidores MCP y la información de identificación personal devuelta por las API de nivel superior. Detenerlo aquí evita que el agente actúe en un contexto contaminado.

Cada gancho admite tres estrategias de aplicación. Hacer cumplir bloquea en caso de infracción o error del servicio de barandilla. Aplicar pero ignorar en caso de error bloquea en caso de infracción, pero permite que la solicitud continúe si no se puede acceder al propio servicio de barandilla. Auditoría registra el veredicto y nunca lo bloquea. Cada barandilla también admite dos modos de funcionamiento. Validar el modo produce una decisión de bloqueo o aprobación. Mutar El modo permite al servicio de barandilla modificar el contenido durante el vuelo, que es la forma en que se conecta la capacidad de enmascaramiento de Pillar. El modo máscara se configura en el lado del pilar y muestra los valores censurados de información personal y secretos coincidentes antes de que la solicitud llegue al modelo.

La superficie de integración

Pillar está configurado en el plano de control de TrueFoundry como una integración de barandilla con dos entradas. La primera es la clave de API que emite la consola de Pillar. La segunda es la configuración del escáner, que selecciona las categorías de detección que deben ejecutarse para esta integración.

Terminal de seguridad Pillar de FieldValueProviderhttps://api.pillar.security/api/v1/integrations/truefoundryToken AuthenticationBearer mediante PILLAR_API_KEYEscáneresfuga de la cárcel y inyección_inmediata y pii y secreto y lenguaje_tóxico y moderación_contenido y carácter_invisibleModos de operaciónFormato de validación y mutación de respuesta{session_id, marcado, escáneres, evidencia}

Una vez que se registra la integración, la puerta de enlace la expone como un selector al que se puede hacer referencia desde cualquier regla de barandilla. Las reglas se configuran mediante un bloque de reglas de YAML. Cada regla usa un bloque when con dos condiciones. objetivo coincidencias en modelos o servidores MCP o herramientas MCPtools o solicita metadatos. temas coincide en la identidad del usuario o del equipo con los operadores in y not_in. A continuación, la regla declara qué integraciones de barandillas deben ejecutarse en cada uno de los cuatro ganchos.

Una regla básica que ejecuta Pillar en la entrada y la salida para un modelo de OpenAI utilizado por todos los equipos tiene este aspecto.

nombre: guardrails-control
tipo: gateway-guardrails-config
reglas:
- id: pillar-baseline
cuando:
objetivo:
operador: o
condiciones:
modelo:
valores:
- openai-main/gpt-4o
estado: en
asignaturas:
operador: y
condiciones:
en:
- equipo: todos
barandas llm_input_:
- pillar/pillar-default-profile
barandillas llm_output_:
- pillar/pillar-default-profile
guardarraíles mcp_tool_pre_invoke_: []
barandas mcp_tool_post_invoke_guardarraíles: []


Una segunda regla que añada el escaneo de pilares en torno a un servidor MCP utilizado por un equipo de agentes apuntaría al servidor MCP y aplicaría la integración en los enlaces de invocación de la herramienta anteriores y posteriores. Todas las reglas coincidentes se evalúan juntas y sus conjuntos de barandas se unen por gancho. Dos reglas a las que se dirigen ambas barandas llm_input_ ambos se ejecutarán en la entrada.

Las anulaciones por solicitud se admiten a través del BARANDAS X-TFY- cabecera. El encabezado contiene un objeto JSON que especifica los selectores de barandilla para cualquier combinación de los cuatro ganchos. Esto permite a los equipos de aplicaciones establecer una política más estricta o permisiva para una llamada específica sin modificar la configuración global.

Todas las decisiones de salvaguardia se capturan en el rastreo de la solicitud. El intervalo incluye el garfio que disparó y el selector de integración, así como el veredicto y la latencia de la llamada a la barandilla y las pruebas presentadas por Pillar. Las trazas se emiten de forma asincrónica a través de NATS y se exportan a través de OTEL a cualquier servidor de observabilidad que el equipo haya configurado. El panel de control de Pillar muestra los mismos eventos desde su perspectiva, con transcripciones completas de los ataques y desgloses por categorías para comprobar su cumplimiento.

Resumen de arquitectura

De un extremo a otro, el flujo de solicitudes tiene este aspecto. Un cliente envía una solicitud de finalización de chat o de agente a la pasarela. La puerta de enlace autentica a la persona que llama con las claves de IdP almacenadas en caché y resuelve el identificador del modelo mediante el enrutamiento del modelo virtual. Las reglas de protección coincidentes se evalúan en la memoria y la carga útil de entrada se envía a Pillar al mismo tiempo que se realiza la llamada al modelo. Si Pillar marca la entrada, la llamada al modelo se cancela y se devuelve un error estructurado. Si la entrada está limpia, se espera la respuesta del modelo y se envía a los escáneres de salida de Pillar antes de la entrega. Para el tráfico de agentes, se aplica la misma lógica a cada invocación de la herramienta MCP y a cada respuesta de la herramienta antes de que vuelva a entrar en el contexto del agente. Cada paso se captura en un espacio de rastreo con el veredicto adjunto.

No es necesario cambiar nada más en la aplicación. No es necesario instalar ningún SDK en el cliente ni instalar ningún sidecar junto con el agente, ni mantener ningún middleware de seguridad por servicio. La puerta de enlace ya está en la ruta de solicitud y Pillar se conecta a esa ruta a través de su API. El código de cliente compatible con OpenAI existente sigue funcionando sin modificaciones.

El principio arquitectónico que hace que esto sea limpio es la consolidación de la aplicación de políticas en la capa de puerta de enlace. Cuando el tráfico de modelos, el tráfico de herramientas y el tráfico de MCP convergen en un único proxy, las barreras configuradas en ese proxy se aplican de manera uniforme en todos los modelos, equipos y agentes sin código por aplicación. Los escáneres de Pillar funcionan en línea en el mismo punto y el modelo de enlace de la pasarela permite a Pillar acceder a los cuatro puntos de control en los que las decisiones en materia de tiempo de ejecución son realmente importantes.

Comenzar

Obtenga más información sobre Puerta de enlace de IA TrueFoundry y el Plataforma Pillar Security. Conecte Pillar en la configuración de barreras de TrueFoundry y consulte el selector de integración desde cualquier regla que se dirija a sus modelos o servidores MCP.