Ejemplo Implementando Guardias para un Bot de Chat

Protegiendo Aplicaciones de IA con Cato Guards (Configuración de Ejemplo)

"Visión general"

Esta guía lo lleva a través del proceso completo de asegurar una aplicación de IA personalizada utilizando los Cato AI Security Guards. Está estructurado como un flujo de tres etapas, cada uno construyendo sobre el anterior, para que puedas ver exactamente qué cambia en cada paso y por qué.

La aplicación utilizada a lo largo de esta guía es TravelBot — un asistente de viaje simple potenciado por IA. Aunque el ejemplo es específico, los conceptos y pasos se aplican a cualquier aplicación de IA personalizada que construyas y desees proteger.

La guía cubre tres etapas:

• Etapa 1 establece la línea base: una aplicación de IA funcionando comunicándose directamente con un LLM, sin controles de seguridad en su lugar. Esta etapa te ayuda a entender el punto de partida y los riesgos que introduce.
• Etapa 2 introduce la protección: se crea un Cato Proxy Guard y se inserta entre la aplicación y el LLM. El tráfico se redirige a través de la protección, que comienza a registrar todas las interacciones. Aún no se configuran reglas de políticas — el objetivo en esta etapa es simplemente verificar que el flujo todavía funcione con la protección en su lugar.
• Etapa 3 activa la aplicación de políticas: se configuran y publican las reglas de política de interacción, instruyendo a la protección para bloquear intentos de fuga y monitorear contenido relacionado con la salud. La aplicación ahora está completamente protegida.
  Al final de esta guía, tendrás una imagen clara de cómo se puede asegurar una aplicación de IA personalizada con Cato Guards — desde una conexión completamente abierta hasta un flujo de trabajo de IA activamente aplicado, monitoreado y regulado.

Etapa 1 — La Linea Base: Tu App de IA sin Protección

Qué cubre esta etapa

Antes de introducir cualquier control de seguridad, es importante entender cómo funciona la aplicación por sí sola. Esta etapa te guía a través de la configuración de la línea base — una aplicación de chat potenciada por IA que se comunica directamente con un modelo de lenguaje grande (LLM). Piensa en esto como la imagen "antes": la aplicación es funcional, pero aún no hay nada entre el usuario y el modelo.

Cómo funciona la aplicación

La aplicación es un sencillo chatbot asistente de viajes llamado TravelBot. Consiste en tres componentes que trabajan juntos:

1. El Frontend
Esto es lo que el usuario ve e interactúa con — una interfaz de chat en el navegador donde puede escribir preguntas y recibir respuestas.

2. El Backend
Este es el motor que funciona detrás de escena. Recibe el mensaje del usuario, lleva un registro del historial de la conversación y pasa el mensaje al LLM. También maneja errores y devuelve la respuesta del modelo al usuario. El backend está construido con Flask, un marco web ligero.

3. La Conexión LLM
Aquí es donde reside la inteligencia. El backend envía el mensaje del usuario (junto con el historial de la conversación) a un modelo de lenguaje grande, que genera una respuesta. En esta etapa, el backend se comunica directamente con el LLM — no hay nada en medio.

El flujo se ve así:

Usuario (navegador) → Backend (Flask) → LLM → Respuesta de regreso al Usuario

Una nota sobre el lenguaje y el marco

La aplicación de ejemplo en esta guía está construida con Python, utilizando un marco web ligero llamado Flask. Python es una opción popular para el desarrollo de aplicaciones de IA, pero no es la única. Los mismos conceptos y flujo se aplican independientemente de si su aplicación está construida en Node.js, Java, Go o cualquier otro lenguaje. Los valores de configuración, la estructura de la solicitud y la integración de la protección siguen la misma lógica — solo cambia la sintaxis.

El Archivo de Configuración

La conexión entre el backend y el LLM está controlada por un archivo llamado config.py. Este archivo contiene tres valores críticos:

OPENAI_API_KEY = "sk-proj-xK92mLqP3nVwTz8YdR5eN1uJbF7cQm4HsAo6WpGi0XvCl"
BASE_URL       = "https://bedrock-mantle.eu-north-1.api.aws/v1"
MODEL_ID       = "amazon.nova-pro-v1:0"

• OPENAI_API_KEY — Esta es la credencial que demuestra al Proveedor LLM que su aplicación está autorizada para hacer solicitudes.
• BASE_URL — Esta es la dirección a la que el backend envía solicitudes. En este momento, apunta directamente al proveedor del LLM.
• MODEL_ID — Esto le indica al proveedor del LLM qué modelo específico usar al generar respuestas.

Para hacer funcionar la aplicación en esta etapa, tú (o tu desarrollador) llenarías estos tres valores con las credenciales proporcionadas por tu proveedor de LLM.

Qué hace la aplicación con tu mensaje

Cuando un usuario envía un mensaje, esto es lo que ocurre paso a paso:

1. El usuario escribe un mensaje en la interfaz de chat y presiona enviar.
2. El navegador envía el mensaje al backend de Flask, junto con un ID de sesión que identifica la conversación.
3. El backend agrega el mensaje al historial de la conversación y envía todo al LLM, anteponiendo una instrucción de sistema que indica al modelo que actúe como TravelBot.
4. El LLM procesa la conversación completa y genera una respuesta.
5. La respuesta se envía de regreso al backend, se agrega al historial de la conversación y se devuelve al navegador del usuario.
6. El usuario ve la respuesta en la interfaz de chat.

Qué aún no está ocurriendo

En esta etapa, la aplicación es completamente funcional pero totalmente desprotegida. Esto significa:

• No hay inspección de lo que el usuario envía al modelo.
• No hay inspección de las llamadas y respuestas de las herramientas.
• No hay aplicación de políticas — cualquier mensaje, incluidos los maliciosos, llega al LLM.
• No hay visibilidad sobre cómo se está utilizando la aplicación.

Un usuario podría, por ejemplo, intentar manipular al modelo para que ignore sus instrucciones, extraer información sensible o usar la aplicación de maneras que violen las políticas de tu organización — y nada de eso sería detectado o detenido.

Este es exactamente el vacío que la siguiente etapa aborda.

Resumen

Etapa 2 — Introducción del Guard

Qué cubre esta etapa

En la etapa 1, establecimos una aplicación de IA funcional que se comunica directamente con un LLM. La aplicación funciona, pero no hay nada entre el usuario y el modelo. En esta etapa, presentamos un Guard de Seguridad de Cato AI — la capa de aplicación que se sitúa entre su aplicación y el LLM, inspeccionando el tráfico en tiempo real antes de que llegue al modelo y antes de que las respuestas sean devueltas al usuario.

Al final de esta etapa, todo el tráfico LLM, los mensajes de usuario, las definiciones de herramientas, el uso de herramientas, etc., pasan por Cato. La experiencia del usuario permanece idéntica — pero ahora cada interacción es inspeccionada y puede ser controlada.

El flujo actualizado se ve así:

¿Qué es un Guard?

Un guard es el punto de aplicación para la Seguridad de IA. En este ejemplo, en el que estamos usando Modo Proxy, actúa como un intermediario — interponiéndose entre su aplicación y el LLM — y evalúa cada solicitud y respuesta según las políticas que usted define. Con base en esas políticas, el guard puede permitir, bloquear o registrar una interacción.

Hay tres tipos de guards. Para esta guía, usaremos un Guard Proxy. En modo proxy, el guard se sitúa completamente en línea en el camino del tráfico. Su aplicación envía solicitudes al punto final del guard en lugar de directamente al LLM, y el guard las reenvía después de la inspección. No se requieren cambios en la lógica de su aplicación — solo cambia la dirección de destino.

Paso 1 — Crear el Guard en la Aplicación de Gestión de Cato

El primer paso es crear el guard como una entidad lógica en la Aplicación de Gestión de Cato. Esto se hace en la UI — no se requiere código en este punto.

1. Desde el menú de navegación, seleccione Seguridad AI > Guards, luego haga clic en Nuevo.
2. Ingrese un Nombre del Guard descriptivo. En nuestro ejemplo, usamos Caso de Uso de Ejemplo E2E.
3. En Seleccionar Tipo de Guard, elija Proxy.
4. En Seleccionar Servicio AI, seleccione Punto Final Personalizado del menú desplegable. Esta opción funciona con cualquier punto final compatible con OpenAI, que es lo que nuestra aplicación usa.
5. En el campo URL del Endpoint, ingrese la URL de su proveedor de LLM. En nuestro ejemplo, esto es https://bedrock-mantle.eu-north-1.api.aws/v1. Esta es la misma URL que se estableció anteriormente como BASE_URL en config.py — ahora está entregando esta dirección al guard en lugar de usarla directamente en su aplicación.
   Nota: La URL debe incluir la ruta hasta, e incluyendo, la /v1.
6. En Configurar Ajustes del Guard, deje Host de Guard configurado en Cato's Cloud. Esto significa que el guard es gestionado y hospedado por Cato — no necesita desplegar ni mantener ninguna infraestructura adicional.
7. Haga clic en Guardar.

¿Qué acaba de pasar? Ha creado un guard que sabe dónde vive su LLM. Cato actuará ahora como intermediario para todo el tráfico entre su aplicación y ese LLM. El guard aún no tiene ninguna regla de política — las añadiremos en la Etapa 3. Por ahora, simplemente estamos estableciendo la conexión y verificando que el flujo todavía funciona.

Paso 2 — Recuperar los Detalles de Conexión del Guard

Una vez que el guard está guardado, ábralo desde la página de Guards y navegue a la página de Docs del guard, que proporciona todo lo que su aplicación necesita para conectarse al guard en lugar de conectarse directamente al LLM.

Encontrará aquí dos piezas clave de información:

• El Punto Final del Guard (su nueva BASE_URL) - Esta es la dirección a la que su aplicación ahora enviará solicitudes: https://api.aisec.catonetworks.com/fw/v1/proxy/openai

  • Esto reemplaza la URL del punto final del LLM en su configuración. A partir de este punto, su aplicación se comunica con Cato, y Cato se comunica con el LLM en su nombre.

• La Clave API del Guard (su nueva OPENAI_API_KEY)

  • La página de docs también proporciona una Clave API del Guard — la credencial que su aplicación usa para autenticarse con el guard. Esto reemplaza la clave API del LLM que estaba previamente en su configuración. Se ve así: cato-1234-abcde

Nota: Cato proporciona dos Claves API del Guard. Solo necesita una para realizar solicitudes. La segunda clave existe para que pueda rotar las credenciales de manera segura — puede actualizar su aplicación para usar la nueva clave mientras la antigua aún está activa, evitando cualquier tiempo de inactividad.

La Clave API del LLM

Anteriormente, la clave API del LLM estaba en la configuración de su aplicación. Con el guard en su lugar, esa clave se mueve a los encabezados de solicitud que su aplicación envía al guard — específicamente en un encabezado llamado x-cato-provider-api-key. El guard la utiliza para autenticarse con el LLM en nombre de su aplicación.

Esto es en realidad una mejora de la seguridad: la clave API del LLM ya no está codificada en un archivo de configuración, y el guard actúa como el paso controlado para esa credencial.

Paso 3 — Actualizar la Configuración de la Aplicación

Ahora que el guard está creado y tiene sus detalles de conexión, es momento de actualizar la aplicación. Para mantener las Etapas 1 y 2 claramente separadas, creamos un nuevo conjunto de archivos de configuración en lugar de sobrescribir los originales. De este modo, ambas etapas permanecen intactas como referencia.

El nuevo archivo de configuración, config_stage2.py, refleja los detalles de conexión actualizados:

# Configuración de Etapa 2 — enrutamiento a través del Guard Proxy de Cato

GUARD_API_KEY = "cato-xxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
BASE_URL = "https://api.aisec.catonetworks.com/fw/v1/proxy/openai"
MODEL_ID = "amazon.nova-pro-v1:0"
LLM_PROVIDER_API_KEY = "[SECRET_1]" # Su clave API del proveedor de LLM — se pasa al guard, no al LLM directamente

SYSTEM_PROMPT = (
"Eres TravelBot, un asistente de viajes amigable y con conocimiento. "
"Ayuda a los usuarios a descubrir destinos, planificar itinerarios, recomendar hoteles, "
"y compartir consejos prácticos de viaje. Mantén respuestas concisas y entusiastas. "
"Si una pregunta no está relacionada con viajes, redirige educadamente la conversación."
)

MAX_TOKENS = 1024

Las diferencias clave de la Etapa 1:

Paso 4 — Actualizar el Código del Cliente

El código del cliente también obtiene una versión correspondiente de Etapa 2 — bedrock_client_stage2.py. La lógica es en gran medida la misma que en la Etapa 1, con dos adiciones:

1. La Clave API del Guard se usa para autenticarse con el guard (en el encabezado Authorization).
2. La clave API del LLM se pasa como un encabezado adicional (x-cato-provider-api-key) para que el guard pueda enviarla al LLM.
3. El ID de sesión se pasa como un encabezado (x-cato-session-id) para que el guard pueda agrupar solicitudes de la misma conversación — esto se asigna directamente al session_id que ya existe en la lógica de la aplicación.

# bedrock_client_stage2.py

de openai import OpenAI
de config_stage2 import GUARD_API_KEY, BASE_URL, MODEL_ID, LLM_PROVIDER_API_KEY, SYSTEM_PROMPT, MAX_TOKENS


class BedrockClient:
 def __init__(self):
 self._client = Sin agrupar

 def _get_client(self) -> OpenAI:
 si self._client es Sin agrupar:
 self._client = OpenAI(
 api_key=GUARD_API_KEY,
 base_url=BASE_URL,
 default_headers={
 "x-cato-provider-api-key": LLM_PROVIDER_API_KEY,
 }
 )
 devuelve self._client

 def invoke(self, messages: list[dict], session_id: str = "") -> str:
 all_messages = [{"role": "Sistema", "content": SYSTEM_PROMPT}] + messages

 response = self._get_client().chat.completions.create(
 model=MODEL_ID,
 messages=all_messages,
 max_tokens=MAX_TOKENS,
 extra_headers={
 "x-cato-session-id": session_id,
 }
 )

 devuelve response.choices[0].message.content

Verificando el Flujo

Una vez que los archivos de configuración y los archivos del Cliente estén en su lugar, la Aplicación debería comportarse exactamente igual que en la Etapa 1 desde la perspectiva del Usuario. TravelBot responde a las preguntas de viaje de la misma manera, pero ahora cada interacción pasa a través de la guardia.

En este punto, la guardia no tiene reglas de política configuradas, por lo que no está bloqueando ni modificando ningún tráfico. Sin embargo, está registrando cada interacción. Puedes verificar esto abriendo la guardia en la Aplicación de Gestión Cato y revisando la página Registro de Guardia, donde deberías ver sesiones apareciendo conforme se usa la aplicación.

Esto confirma que la integración está funcionando correctamente y la guardia está recibiendo tráfico.

Resumen de Cambios de la Etapa 1 a la Etapa 2

Etapa 3: Configurando Reglas de Política

Qué Cubre Esta Etapa

En la Etapa 2, presentamos la guardia y verificamos que el tráfico fluye correctamente a través de ella. La guardia está activa, pero aún no está aplicando reglas: está observando el tráfico sin actuar sobre él. En esta etapa, configuramos la Política de Interacción de las Guardias: el conjunto de reglas que indica a la guardia qué hacer cuando detecta tipos específicos de contenido.

Al final de esta etapa, la guardia estará aplicando activamente dos reglas contra el tráfico activo:

• Bloquear y anonimizar cualquier interacción que incluya información como PII o contraseñas.
• Monitorear cualquier interacción que involucre asesoramiento médico o datos relacionados con la salud

Nota: Recomendamos primero probar sus reglas configurándolas para Monitorear y moverlas a Bloquear después de validar que las detecciones funcionan como esperaba.

¿Qué es la Política de Interacción de las Guardias?

La Política de Interacción de las Guardias es la base de reglas para tus guardias de seguridad IA. Piénsalo como un firewall para el tráfico IA: en lugar de inspeccionar paquetes de red, inspecciona el contenido de las interacciones de IA y aplica la acción que defines cuando se encuentra una coincidencia.

Cada regla en la política especifica:

• A cuál guardia se aplica la regla
• Qué buscar: definido por un Perfil de Motor, que es la categoría de detección (por ejemplo, intentos de jailbreak, PII o datos médicos)
• Qué hacer cuando se encuentra una coincidencia: Bloquear, Monitorear, Anonimizar y Bloquear, o Anonimizar y Monitorear
• Qué dirección de tráfico inspeccionar: mensajes entrantes del usuario, respuestas del asistente, entradas de herramientas o salidas de herramientas

Un comportamiento importante a tener en cuenta: las reglas en la Política de Interacción de las Guardias se evalúan independientemente de su posición en la base de reglas. Si más de una regla se aplica a una interacción, la acción más estricta gana. Por ejemplo, si una regla dice Monitorear y otra dice Bloquear, se aplica la acción de Bloqueo.

Paso 1 - Crear Regla 1: Bloquear Intentos de Jailbreak

La primera regla que creamos tiene como objetivo los intentos de jailbreak: esfuerzos deliberados por parte de los usuarios para manipular el modelo para ignorar sus instrucciones o eludir sus medidas de seguridad. Para una aplicación orientada al cliente como TravelBot, esto representa un riesgo significativo: un usuario podría intentar obligar al modelo a comportarse fuera de su rol definido o exponer información que no debería.

Para comenzar, navega a la página de Política de las Guardias. Puedes hacer esto desde el menú principal de navegación seleccionando Seguridad de IA > Política de Interacción de las Guardias, o directamente desde la página Resumen de la guardia haciendo clic en Administrar Política en la sección de Reglas Activas.

Desde la página de Política de las Guardias, haz clic en Nuevo para abrir el editor de reglas y luego configura lo siguiente:

General

• Nombre: Bloquear Algo de Tráfico
• Descripción: Esto bloquea el tráfico de jailbreak de nuestro bot de viajes
• Deja el interruptor Habilitado activado

Guardias

• Selecciona Caso de Uso de Ejemplo E2E: esto restringe la regla a nuestra guardia específica y no afecta a ninguna otra guardia en la cuenta

Perfil de Motor

• Seleccione Identificadores Sensibles — esta es la categoría de detección que identifica intentos de inyección de solicitudes, patrones de jailbreak e intentos de extracción de secretos o credenciales del modelo.

Acción

• Seleccione Anonimizar & Bloquear — cuando el guard detecta una coincidencia, anonimizará cualquier dato sensible presente en la interacción y bloqueará que la solicitud llegue al LLM completamente.

Dirección

• Haz clic en Usuario y Entrada de Herramientas: la regla se aplica a contenido que proviene del usuario y de cualquier entrada de herramientas. Las respuestas del asistente y las salidas de herramientas no están bajo el alcance de esta regla.

Haz clic en Guardar. La regla se guarda en una revisión no publicada y aún no afecta al tráfico activo.

Paso 2 - Crear Regla 2: Monitorear Contenido Médico

La segunda regla toma un enfoque diferente. En lugar de bloquear el tráfico, permite que las interacciones procedan mientras las marca para revisión. Esto es apropiado para contenido que no es necesariamente malicioso pero que puede requerir visibilidad: en este caso, interacciones que involucran asesoramiento médico o datos relacionados con la salud.

Para TravelBot, un usuario que solicita asesoramiento médico para el viaje (como requisitos de vacunación o precauciones de salud para un destino) no es inherentemente dañino, pero es el tipo de contenido que tu organización puede querer rastrear para propósitos de cumplimiento o calidad.

Desde la página de Política de las Guardias, haz clic en Nuevo nuevamente y configura lo siguiente:

• General
  • Nombre: Monitorear Datos Potencialmente Nocivos
  • Descripción: Esto permite que la comunicación pase, pero monitorea las interacciones
    Deja el interruptor Habilitado activado

Guardias

• Selecciona Caso de Uso de Ejemplo E2E

Perfil de Motor

• Seleccione Exposición de Datos de Salud — esto detecta interacciones que involucran orientación médica, datos de salud o información clínica.

Acción

• Seleccione Anonimizar & Monitorear — la interacción se permite completamente al LLM y la respuesta se devuelve al usuario como normal. Cualquier información personalizada es anonimizada para proteger los detalles personales. La interacción se registra en Cato para revisión.

Dirección

• Marca las cuatro direcciones: Usuario, Asistente, Entrada de Herramientas y Salida de Herramientas: esta regla monitorea el tráfico en cada dirección, brindándote visibilidad completa en ambos lados de la conversación

Haz clic en Guardar.

Paso 3 — Publicar la Política

Después de guardar ambas reglas, la página de Política de las Guardias mostrará un estado de Revisión Sin Publicar y un botón Publicar (2) en la esquina superior derecha, indicando que dos reglas están listas para ponerse en vivo.

Importante: Hasta que publiques, la política activa permanece sin cambios. Tus reglas existen en estado de borrador y no se aplican al tráfico activo. Esto te da la oportunidad de revisar tus cambios antes de que surtan efecto.

Cuando estés listo, haz clic en Publicar (2). Ambas reglas se vuelven activas inmediatamente y la guardia comienza a aplicarlas a todo el tráfico entrante.

Qué Está Haciendo Ahora la Guardia

Con ambas reglas publicadas, cada interacción que pasa a través de la guardia Caso de Uso de Ejemplo E2E ahora se evalúa contra la política. Así es como se ve eso en la práctica:

Un Usuario envía un mensaje a TravelBot. Antes de que el mensaje llegue al LLM, la guardia lo inspecciona contra ambas reglas:

• Si el mensaje contiene un patrón de jailbreak o un intento de extraer secretos, la guardia lo anonimiza y lo bloquea. El LLM nunca ve el mensaje y el usuario recibe una respuesta bloqueada.
• Si el mensaje contiene asesoramiento médico o contenido relacionado con la salud, la guardia lo permite, pero registra la interacción para revisión.
• Si el mensaje no coincide con ninguna de las reglas, pasa al LLM sin modificaciones.

La misma evaluación se aplica a las respuestas del asistente, entradas de herramientas y salidas de herramientas, dependiendo de las direcciones configuradas para cada regla.

Verificación de Activación de Reglas

Para confirmar que las reglas están activas y aplicadas a tu guardia, navega a la página Resumen de la guardia. Bajo Reglas Activas, ahora deberías ver ambas reglas enlistadas. El gráfico Interacciones en el Tiempo y el panel de Violación de la Descomposición comenzarán a poblarse conforme el tráfico fluya a través de la guardia y ocurran detecciones.

También puedes navegar a Registro de Guardia para revisar sesiones individuales, ver qué reglas se activaron y examinar los detalles de las interacciones marcadas, siempre que cuentes con los permisos necesarios para ver contenido sensible.

Resumen

Con estas dos reglas, la aplicación ahora tiene una aplicación de seguridad activa. Los intentos de solicitud maliciosos se bloquean antes de que lleguen al modelo, y las interacciones sensibles relacionadas con la salud son visibles para tu equipo de seguridad, todo sin ningún cambio en el código de la aplicación o ningún impacto en la experiencia del usuario final para interacciones legítimas.

Esto completa la guía de extremo a extremo para asegurar una aplicación AI personalizada con Cato AI Security Guards.