Cómo configurar mecanismos de protección en la pasarela de IA

Por qué las barreras de seguridad deben estar en la gateway

Un endpoint de modelo sin procesar devolverá alegremente datos personales, aceptará una carga útil de inyección de prompts o proporcionará una respuesta insegura. Las barreras de seguridad solucionan esto inspeccionando y, cuando es necesario, reescribiendo el tráfico antes de que llegue al modelo y antes de que la respuesta llegue al usuario.

Implementar barreras de seguridad en la AI Gateway significa que cada aplicación obtiene la misma protección automáticamente, sin que cada equipo tenga que volver a implementar la seguridad. TrueFoundry incluye barreras de seguridad integradas para la redacción de PII y la detección de inyección de prompts, ambas totalmente gestionadas y sin necesidad de configurar claves de terceros.

El modelo de dos pasos: registrar y luego aplicar políticas

Como documentación de guardrails indica, aplicar barreras de seguridad en la AI Gateway es un proceso de dos pasos.

• Registrar barreras de seguridad. Ve a AI Gateway, luego a Guardrails, crea un grupo de barreras de seguridad y añade las integraciones que desees, ya sean las integraciones nativas de TrueFoundry, proveedores externos o barreras de seguridad personalizadas.
  

• Configurar políticas. Ve a AI Gateway, luego a Policies, después a Guardrails y crea reglas que determinen cuándo aplicar qué barreras de seguridad y en qué puntos de conexión (hooks) se ejecutan.

Creación de una regla de barrera de seguridad

En Policies, dentro de Guardrails, haz clic en Add Rule. Cada regla tiene un ID único y varias secciones que determinan a quién se aplica y dónde se ejecuta.

• Cuando la solicitud se dirige a (objetivos). Coincide con uno o más modelos, o con servidores MCP e incluso herramientas específicas. Las condiciones de destino múltiples se combinan con OR, por lo que la regla se aplica si la solicitud se dirige a cualquiera de los modelos o servidores MCP listados. Si no se especifica ningún objetivo, la regla se aplica a cualquier modelo.
  

• Desde sujetos. Filtra por usuarios, equipos o cuentas virtuales con condiciones IN o NOT IN. Si no hay filtro de sujeto, la regla se aplica a todos los emisores.
  

• Con metadatos. Realiza coincidencias con pares clave-valor enviados en la cabecera X-TFY-METADATA, por ejemplo, environment production.
  

• Aplicar en hooks. Elige el hook y selecciona los guardrails que se ejecutarán en él. Puedes adjuntar varios guardrails al mismo hook, y todos ellos se ejecutarán para las solicitudes que coincidan.

Los cuatro hooks

• Entrada de LLM se ejecuta antes de que el prompt se envíe al modelo.
  

• Salida de LLM se ejecuta después de que el modelo responde, antes de que se devuelva la respuesta.
  

• Pre-invocación de herramienta MCP se ejecuta antes de que se ejecute una herramienta MCP.
  

• Post-invocación de herramienta MCP se ejecuta después de que una herramienta MCP devuelve un resultado, antes de que este llegue al modelo.

Todas las reglas se evalúan para cada solicitud, y los guardrails de todas las reglas coincidentes se combinan y aplican conjuntamente. Si una regla aplica detección de PII en la entrada de LLM y otra aplica detección de inyección de prompts en la entrada de LLM, ambas se ejecutan.

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

Configuración de la redacción de PII y PHI

ElGuardrail de detección de PII y PHI es un guardrail integrado de TrueFoundry que identifica y redacta información de identificación personal (PII) e información de salud protegida (PHI). Funciona internamente mediante la detección de PII de Azure AI Language y está totalmente gestionado, por lo que no requiere claves de API de terceros.

Solo admite el modo de mutación, lo que significa que siempre redacta las entidades detectadas. En el formulario de configuración, estableces un nombre, eliges las categorías de PII o mantienes las predeterminadas (todas las categorías) y seleccionas una estrategia de aplicación. Los valores detectados se reemplazan por asteriscos, por lo que un número de teléfono y un correo electrónico en un mensaje quedan enmascarados antes de que el modelo los vea.

Una configuración común aplica la redacción de PII en la entrada de LLM para limpiar los mensajes de los usuarios, en la salida de LLM para limpiar las respuestas, y en los hooks de MCP para eliminar la PII de los parámetros y resultados de las herramientas, como las filas de una base de datos.

Configuración de la defensa contra inyección de prompts

Elmecanismo de protección contra inyección de prompts es un mecanismo de protección integrado basado en Azure Prompt Shield. Detecta inyecciones directas de prompts, ataques de jailbreak como el patrón "do anything now" e inyecciones indirectas ocultas en documentos o contenido contextual. Analiza el prompt del usuario y el contenido del documento por separado.

Solo admite el modo de validación, lo que significa que detecta y bloquea ataques, pero no modifica el contenido. La configuración solo requiere un nombre y una estrategia de aplicación. La documentación recomienda comenzar con la estrategia de auditoría para supervisar las detecciones en los seguimientos de las solicitudes y, una vez que se tenga confianza en ella, cambiar a la de aplicación.

Cómo ejecuta la pasarela los mecanismos de protección en una solicitud

En una solicitud a un LLM, los mecanismos de protección de mutación de entrada se ejecutan primero y bloquean el proceso hasta que finalizan, por ejemplo, al redactar información de identificación personal (PII) del prompt. A continuación, la validación de entrada, como la de inyección de prompts, se ejecuta en segundo plano mientras la solicitud al modelo está en curso. Si la validación de entrada falla mientras el modelo sigue funcionando, la pasarela cancela la solicitud al modelo de inmediato para que no tenga que pagar por ella.

Una vez que el modelo responde, la mutación de salida puede eliminar secretos y la validación de salida comprueba el resultado final antes de que llegue al cliente. Para las herramientas MCP, todos los mecanismos de protección previos a la herramienta se ejecutan antes de que se llame a la herramienta; si alguno falla, la herramienta nunca se ejecuta. Los mecanismos de protección se ejecutan en cada llamada a la herramienta por separado.

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