Políticas del proxy

Las políticas son las reglas que el proxy usa para decidir qué se le permite hacer a cada acción de un agente. Se crean en la consola (o vía la API de plataforma), se almacenan una sola vez en PostgreSQL y se leen en vivo por cada instancia del proxy.

El modelo de política

Una política tiene cuatro partes:

• Condiciones de coincidencia: a qué peticiones se aplica esta política. Las condiciones pueden coincidir por agente, tipo de acción, upstream, contenido del prompt, headers o cualquier combinación.
• Acción: una de ALLOW, FLAG, DENY.
• Prioridad: un entero; las prioridades más bajas se evalúan antes. La primera política coincidente gana.
• Alcance: a qué tenant (y opcionalmente, a qué conjunto de agentes) se aplica la política.

Acciones

• ALLOW: la petición se reenvía al upstream. La traza se registra como ALLOWED.
• FLAG: la petición se reenvía pero la traza se marca como FLAGGED y aparece en el dashboard para revisión.
• DENY: la petición se rechaza antes del reenvío. El agente recibe un error estructurado 403 y la traza se registra como DENIED.

Condiciones de coincidencia

Las condiciones habituales incluyen:

• ID de agente: restringir la política a agentes específicos.
• Tipo de acción: chat_completion, embedding, tool_call, mcp_request, http_request.
• URL de upstream: coincidir con llamadas a un proveedor o dominio específico.
• Contenido del prompt: coincidencia por subcadena o regex contra el cuerpo del mensaje del usuario.
• Valor de header: coincidir por X-RenLayer-User, X-RenLayer-Session o cualquier header reenviado.
• Nombre de herramienta: para llamadas a herramientas, coincidir por la herramienta que el agente está invocando.

Las condiciones se combinan con AND. Para expresar OR, escribe varias políticas con la misma acción.

Prioridad y orden

Cuando múltiples políticas coinciden, gana la que tenga el número de prioridad más bajo. Un patrón común:

1. Prioridad 10: una regla DENY para patrones conocidamente peligrosos (p. ej. exfiltración de credenciales).
2. Prioridad 50: reglas FLAG para patrones sensibles pero ambiguos.
3. Prioridad 1000: una regla ALLOW por defecto que captura todo lo demás.

Si ninguna política coincide, el proxy aplica el valor por defecto del tenant (normalmente ALLOW).

Creación y rollout

Las políticas se crean en la página Políticas de la consola. Cuando guardas una política, se escribe en PostgreSQL y la recoge cada instancia del proxy en su siguiente petición, no hay caché que invalidar ni reinicio necesario.

Puedes deshabilitar una política sin eliminarla; las políticas deshabilitadas permanecen en el historial para auditoría.

Versionado

Cada edición de política crea una fila de versión. El log de auditoría registra quién cambió qué y cuándo. Hacer rollback es una acción de un solo clic que crea una nueva versión apuntando a una definición anterior.

Pruebas

La consola incluye un formulario de prueba de política: pega un cuerpo de petición de muestra y comprueba qué políticas coinciden y cuál sería la acción resultante. Es la forma recomendada de validar una política antes de habilitarla para agentes en producción.

A dónde ir después

• DLP: bloqueo basado en contenido que se ejecuta junto con las políticas.
• Límites de tasa: protecciones basadas en cuota.
• Consola: políticas: creación de políticas en la UI.
• Estados de acción: cómo se ve cada resultado de política en las trazas.