Protección en tiempo de ejecución de Onyx ahora en TrueFoundry AI Gateway: guardrails de directivas para cada llamada a LLM
.png)
Diseñado para la velocidad: ~ 10 ms de latencia, incluso bajo carga
¡Una forma increíblemente rápida de crear, rastrear e implementar sus modelos!
- Gestiona más de 350 RPS en solo 1 vCPU, sin necesidad de ajustes
- Listo para la producción con soporte empresarial completo
Si su equipo enruta el tráfico de LLM a través de un AI gateway, cada prompt y cada respuesta es un punto donde algo puede salir mal. TrueFoundry AI Gateway le ofrece acceso unificado a más de 1000 LLM tras una única API compatible con OpenAI. Onyx ahora está disponible como guardrail personalizado en ese gateway, para que los clientes de TrueFoundry puedan añadir protección en tiempo de ejecución sin cambiar el código de las aplicaciones.
La protección en tiempo de ejecución debe estar en el punto de cumplimiento de directivas, no en cada aplicación. Onyx ejecuta las mismas comprobaciones en cada prompt y respuesta que cruza ese límite. Sus aplicaciones obtienen la defensa contra prompt injection, detección de jailbreak, comprobaciones de exfiltración de datos y directivas de contenido de Onyx evaluadas antes de que el modelo o el usuario vean el resultado.
La configuración se realiza exclusivamente mediante parámetros. No hay ningún wrapper que desplegar ni código de aplicación que modificar.
Requisitos previos
- Un TrueFoundry AI Gateway con al menos un proveedor de modelos configurado que admita verdict: false en HTTP 200.
- Una directiva de Onyx AI Guard y su Guard Token, con al menos una regla de bloqueo (Block) que escanee la dirección de entrada (Input) o salida (Output) que desee aplicar.
- Conexión HTTPS saliente desde su gateway de TrueFoundry hacia el host de su tenant de Onyx.
- Permisos para añadir y vincular grupos de guardrails en el panel de control de TrueFoundry.
Integración paso a paso
Onyx expone un endpoint evaluate nativo de TrueFoundry que cumple directamente con el contrato de guardrails personalizados del gateway. TrueFoundry llama a Onyx y Onyx devuelve un veredicto. No hay ningún wrapper ni adaptador intermedio.
Paso 1: Obtener el Guard Token y construir la URL
El Guard Token en la URL de su directiva de AI Guard identifica qué directiva evaluar y actúa como autenticación para la llamada. No es una API key ni un MCP Gateway Token. En Onyx, vaya a Policies, luego a Runtime Policies, seleccione la pestaña AI Guard, abra la URL de AI Guard de la directiva y copie el Guard Token y el nombre de host de su tenant.
Construya la URL del guardrail:
https://<routing-id>.ai-guard.onyx.security/guard/evaluate/v1/<guard-token>/truefoundry
Utilice el host de su propio tenant. La dirección simple https://ai-guard.onyx.security no enruta a ningún tenant y devuelve un error 404.
Paso 2: Registrar las configuraciones de guardrail personalizado
En el panel de control de TrueFoundry, vaya a AI Gateway, luego a Guardrails y seleccione New Guardrails Group. Elija Custom y asígnele el nombre onyx-security. Añada dos configuraciones, una por cada dirección, ambas apuntando a la misma URL de Onyx.
Para la configuración de entrada, establezca el nombre en onyx-input, la operación en Validate y el destino en Request. Pegue la URL del guardrail que construyó en el Paso 1, deje Auth Data como None, configure Config como {} y elija Enforce But Ignore On Error como estrategia de aplicación.
Para la configuración de salida, establezca el nombre en onyx-output, la operación en Validate y el destino en Response. Utilice la misma URL de guardrail, deje Auth Data como None, configure Config como {} y elija Enforce But Ignore On Error como estrategia de aplicación.
Las únicas diferencias entre ambas configuraciones son el nombre y el destino. Deje Auth Data vacío. El Guard Token en la ruta de la URL es la autenticación, por lo que no se requiere ningún Bearer token.
Paso 3: Vincular el guardrail al tráfico
Vincule el grupo a un modelo en la configuración de guardrails del modelo, aplíquelo en todo el gateway a través de Policies y luego Guardrails, o selecciónelo por petición mediante un encabezado para probarlo sin cambiar de modelo:
{
"llm_input_guardrails": ["onyx-security/onyx-input"],
"llm_output_guardrails": ["onyx-security/onyx-output"]
}
Envíe un prompt benigno y pasará directamente al modelo. Envíe uno que active una regla de Onyx y el gateway lo bloqueará, devolviendo el mensaje de la directiva en lugar de la respuesta del modelo, como HTTP 400 con error.type: guardrail_checks_failed. Para la protección de respuestas, configure "stream": false; los guardrails de salida no se ejecutan en respuestas en streaming.
Ventajas que obtiene
Validación de entrada y salida. El guardrail de entrada analiza los prompts antes de que se ejecute el modelo. El guardrail de salida analiza las respuestas antes de que lleguen al usuario, en peticiones sin streaming. Onyx evalúa cada una con respecto a las reglas de dirección de entrada (Input) y salida (Output) de su directiva.
Bloqueo basado en directivas. Los bloqueos incluyen el mensaje que configuró en Onyx, por lo que quien realiza la llamada ve su texto y no un error genérico. Puede cambiar la aplicación de directivas editándolas en la consola de Onyx, sin realizar cambios en el lado de TrueFoundry.
Una sola directiva para todas las aplicaciones. Dado que la comprobación se ejecuta en el gateway, cada equipo y cada aplicación que se enrute a través de él hereda los mismos guardrails. No hay que mantener una integración por aplicación ni existen vacíos de cobertura cuando se lanza un nuevo servicio.
Observabilidad en el mismo lugar. Las decisiones de los guardrails se rastrean junto con el resto de la petición. El gateway cumple con OpenTelemetry, por lo que puede ver qué peticiones se bloquearon y por qué en el mismo entorno que ya utiliza para latencia y costes.
Preguntas frecuentes
¿Qué son los guardrails para LLM en un AI gateway?
Los guardrails son comprobaciones que el gateway ejecuta en prompts y respuestas antes de que lleguen al modelo o al usuario. En TrueFoundry AI Gateway se ejecutan como directivas configurables, lo que permite bloquear prompt injection, jailbreaks o fugas de datos de forma centralizada en lugar de hacerlo en cada aplicación.
¿Tengo que desplegar algo para añadir el guardrail de Onyx?
No. TrueFoundry llama directamente al endpoint evaluate de Onyx. Solo debe registrar dos configuraciones de guardrail que apunten a su URL de Onyx. No hay ningún wrapper ni adaptador que alojar.
¿Se ejecuta el guardrail de Onyx tanto en prompts como en respuestas?
Sí. La integración registra dos guardrails, uno en la petición y otro en la respuesta. Que una frase se bloquee en la salida depende de que su directiva de Onyx tenga una regla de dirección Output; Input y Output se configuran por separado en Onyx, y la protección de salida requiere peticiones sin streaming.
¿Tengo que cambiar el código de mi aplicación para añadir guardrails?
No. El guardrail se ejecuta en el gateway. Lo vincula a un modelo o pasa un encabezado en la petición, y el código de su aplicación sigue funcionando sin cambios.
¿Por qué mi petición devuelve un error de validación?
El endpoint /truefoundry requiere context.user.subjectSlug en la petición. El gateway lo proporciona en el tráfico normal; si llama al endpoint directamente para hacer pruebas, incluya subjectSlug o Onyx devolverá un veredicto de bloqueo con "could not validate the request".
¿Puedo ejecutar TrueFoundry AI Gateway en mi propia VPC?
Sí. TrueFoundry admite despliegues en VPC, instalaciones local (on-prem), entornos aislados (air-gapped) y configuraciones de multicloud, sin que ningún dato salga de su dominio.
¿Se integra con mi infraestructura de observabilidad actual?
Sí. El gateway cumple con OpenTelemetry y se conecta con Grafana, Datadog o Prometheus, rastreando cada petición desde el prompt hasta el modelo, incluidas las decisiones de los guardrails.
Onyx y TrueFoundry han colaborado en esta integración. Póngase en contacto con su representante de TrueFoundry u Onyx para comenzar.
TrueFoundry AI Gateway ofrece una latencia de entre 3 y 4 ms, gestiona más de 350 RPS en una vCPU, se escala horizontalmente con facilidad y está listo para la producción, mientras que LitellM presenta una latencia alta, tiene dificultades para superar un RPS moderado, carece de escalado integrado y es ideal para cargas de trabajo ligeras o de prototipos.














%20(28).webp)



.webp)
.webp)
.png)

.png)
.png)
.png)
.png)
.png)
.webp)
.webp)





