Guardrails para agentes de IA: inspección de cada llamada a herramientas y salto de modelo

¿Qué son los guardrails para agentes de IA?

Los guardrails para agentes de IA son controles de inspección de contenido que examinan la carga útil real de cada interacción del agente (el prompt del usuario, la respuesta del modelo y los argumentos y resultados de cada llamada a herramientas) y toman medidas (permitir, bloquear o reescribir) según la política establecida.

Resulta útil separar dos preguntas que toda llamada de agente gobernada debe responder:

• Si la llamada está permitida — gestionado por el control de acceso e identidad (qué agente es este, qué tiene permitido hacer).
• Qué contiene la llamada — gestionado por los guardrails (¿hay una inyección en este resultado de herramienta, un secreto en esta salida, un DROP TABLE en estos argumentos?).

El control de acceso es el portero en la entrada; los guardrails son el detector de metales. Necesita ambos. Un agente puede estar totalmente autorizado para llamar a su servidor MCP de Postgres y aun así ser engañado para enviar una consulta destructiva: el acceso dijo que sí, y solo un guardrail en los argumentos de la herramienta detecta cuál es realmente la consulta.

Por qué los agentes aumentan los riesgos

Los guardrails no son nuevos en las aplicaciones de LLM, pero los agentes cambian el problema de tres formas concretas:

• El contenido no confiable fluye continuamente. Cada resultado de una herramienta (una página web, un ticket de soporte, una fila de base de datos) vuelve a entrar en el contexto del modelo en el siguiente turno. Cualquiera de ellos puede contener una inyección, por lo que las entradas deben verificarse incluso cuando el usuario es de confianza.
• Las salidas se convierten en acciones. Un comando de shell alucinado o una sentencia SQL demasiado amplia no solo se lee mal; se ejecuta. Los argumentos de las herramientas deben verificarse antes la herramienta se ejecute.
• Las cadenas multiplican la exposición. Una cadena de cinco herramientas supone cinco oportunidades para filtrar un secreto o exfiltrar información de identificación personal (PII). Unas barreras de seguridad eficaces se ejecutan en cada llamada a herramienta por separado, por lo que cada salto cuenta con sus propias comprobaciones.

Dónde se ejecutan las barreras de seguridad de los agentes de IA: los cuatro puntos de enganche

En TrueFoundry, las barreras de seguridad se aplican en la pasarela durante la ruta de llamada del agente : la cadena de usuario → aplicación → agente → subagente → llamadas a herramientas MCP. Cada salto supervisado pasa por un punto de interceptación con un antesydespués de que de cada punto de enganche.

El orden es importante para el coste y el radio de impacto. Un fallo previo a la herramienta significa que la herramienta nunca llega a ejecutarse, lo que supone el fallo más económico posible. Un fallo en la entrada del LLM cancela la solicitud al modelo en curso antes de que tengas que pagar por ella. Dado que cada salto se comprueba de forma independiente, un resultado comprometido en el tercer salto se detecta en ese mismo momento, y no después de que se haya propagado a tres llamadas más.

Cómo asociar riesgos a barreras de seguridad

La ventaja de ejecutar barreras de seguridad en la MCP Gateway es que cada riesgo real del agente se asigna a un control específico e integrado. Las barreras de seguridad integradas de TrueFoundry se ejecutan en la infraestructura gestionada por TrueFoundry, sin necesidad de configurar claves API de terceros.

Más allá de las funciones integradas, la pasarela se conecta con proveedores externos (Palo Alto Prisma AIRS, CrowdStrike AIDR, Cisco AI Defense, AWS Bedrock Guardrails, Google Model Armor, NVIDIA NeMo Guardrails, Guardrails AI, entre otros) y admite barreras de seguridad totalmente personalizadas cuando necesitas una lógica específica para tu dominio.

La barrera de seguridad contra inyección de prompts es la que se ha diseñado específicamente para el problema de los agentes: analiza el prompt del usuario y y cualquier documento o contenido contextual por separado, de modo que una inyección oculta dentro de una página web o un ticket devuelto se detecta incluso cuando el mensaje original del usuario es seguro.

Cómo implementar barreras de seguridad para agentes de IA

La aplicación de barreras de seguridad al tráfico de los agentes sigue un flujo de tres pasos y, fundamentalmente, nada de esto reside en el código de su agente.

Paso 1: Registrar las barreras de seguridad

EnAI Gateway → Guardrails, cree un grupo de barreras de seguridad y añada las integraciones que necesite: integradas, de proveedores externos o personalizadas. Un grupo es también la unidad de control de acceso: un gestor puede añadir, editar y eliminar barreras de seguridad; un usuario solo puede aplicarlas. Un patrón común es tener un grupo para toda la organización gestionado por el equipo de plataforma, además de grupos por equipo para comprobaciones específicas de producto.

Paso 2: Crear políticas que vinculen las barreras de seguridad por objetivo

EnAI Gateway → Policies → Guardrails, cree reglas que decidan cuándo se ejecuta cada barrera de seguridad. Esto es lo que permite que el modelo escale a flotas de agentes: las reglas se basan en el objetivo (los modelos, servidores MCP e incluso herramientas específicas que se están llamando) y el sujeto (usuarios, equipos o cuentas virtuales). Dado que una regla cubre a cada llamante de un servidor MCP o modelo determinado, protege a todos los agentes que acceden a ese objetivo, sin necesidad de configuración por agente.

‍

Cada regla combina:

‍

• Objetivos : modelos (IN / NOT IN) y servidores MCP, opcionalmente restringidos a herramientas específicas (por ejemplo, solo la herramienta run_query de un servidor de base de datos).
• Sujetos — Filtros IN / NOT IN para usuarios, equipos o cuentas virtuales.
• Metadatos — coincidencia con pares clave-valor X-TFY-METADATA, de modo que una regla pueda aplicarse solo a environment: production.
• Hooks — asocia las barreras de seguridad registradas a la entrada del LLM, la salida del LLM, o a la pre-invocación o post-invocación de herramientas MCP.

‍

Captura de pantalla del producto — Documentación de TrueFoundry: editor de reglas de políticas de barreras de seguridad.

‍

Todas las reglas que coinciden se evalúan y sus barreras de seguridad se combinan por hook. Si la Regla A aplica detección de PII en la entrada del LLM y la Regla B aplica detección de inyección de prompts en la entrada del LLM, ambas se ejecutan. Una regla sin condiciones de destino o sujeto se convierte en una línea base que se aplica a todo el tráfico; es útil para realizar una comprobación de inyección de prompts a nivel de toda la empresa por encima de todo lo demás.

‍

Para pruebas rápidas o llamadas puntuales, también puede pasar barreras de seguridad por solicitud con la cabecera X-TFY-GUARDRAILS, lo que omite las políticas por completo:

‍

curl https://<your-gateway>/api/llm/chat/completions \

  -H "Authorization: Bearer $TFY_API_KEY" \

  -H 'X-TFY-METADATA: {"environment":"production","agent":"research-agent"}' \

  -H 'X-TFY-GUARDRAILS: {"llm_input":["global/prompt-injection","global/pii-detection"]}' \

-H "Content-Type: application/json" \

-d '{

"model": "openai-main/gpt-4o",

        "messages": [{"role":"user","content":"Summarize ticket #4521 and email the customer"}]

}'

Paso 3 — Verificar en los seguimientos

Cada solicitud se rastrea junto con las barreras de seguridad que se ejecutaron y sus veredictos, para que pueda confirmar la cobertura antes de confiar en ella. Aquí es también donde se ajustan los falsos positivos, que son más importantes para los agentes que para los chatbots: un salto bloqueado puede hacer fallar toda una cadena.

‍

Captura de pantalla del producto — Documentación de TrueFoundry: resultados de las barreras de seguridad en un seguimiento de solicitud.

‍

Antes de publicar, utiliza el Playground para realizar pruebas de prompts y llamadas a herramientas en los cuatro hooks y observar qué es lo que se detecta.

‍

Captura de pantalla del producto: documentación de TrueFoundry: AI Gateway Playground.

‍

Modos de aplicación: validar, mutar y nivel de bloqueo

Dos ajustes controlan el comportamiento de cada guardrail.

‍

Modo de operación:

‍

• Validar — inspeccionar y bloquear (por ejemplo, la detección de inyección de prompts, que solo detecta y bloquea).
• Mutar — reescribir el contenido y, opcionalmente, bloquear (por ejemplo, la detección de PII que redacta un correo electrónico antes de que el prompt llegue al modelo).

‍

Estrategia de aplicación:

‍

• Aplicar (Enforce) — bloquear ante una infracción y si el propio guardrail genera un error. Úsalo para comprobaciones de cumplimiento estricto, como PII.
• Aplicar pero ignorar errores (Enforce But Ignore On Error) — bloquear ante una infracción, pero permitir el tráfico si el proveedor del guardrail sufre una interrupción. Es la opción pragmática por defecto para la mayoría del tráfico de agentes.
• Auditoría — solo registrar, no bloquear nada.

‍

Para lógica personalizada, despliegas un guardrail como servicio HTTP y la pasarela lee su contrato de respuesta: un HTTP 2xx significa que el guardrail se ejecutó, y el cuerpo JSON contiene el resultado — verdict: false para denegar, o un cuerpo de resultado mutado para reescribir:

‍