Docs

Proxy

Cómo funciona el proxy

Flujo extremo a extremo de una petición a través del proxy de RenLayer: autenticación, evaluación de políticas, escaneo DLP, reenvío al upstream y persistencia de la traza.

El proxy convierte cada petición de un agente en un evento estructurado y gobernado. Esta página recorre el flujo desde el momento en que la petición aterriza hasta el momento en que la traza se escribe.

Ciclo de vida de la petición

  1. Ingreso. El agente llama a la URL del proxy con su clave de API de RenLayer en el header Authorization: Bearer ….
  2. Autenticación. El proxy valida la clave de API, resuelve el agente e identifica el tenant. Las claves inválidas devuelven 401 inmediatamente.
  3. Clasificación. El proxy lee la ruta y el cuerpo para determinar el tipo de acción, chat completion, embedding, llamada a herramienta, petición MCP o HTTP arbitrario.
  4. Evaluación de políticas. Las políticas del tenant se evalúan en orden de prioridad. La primera regla coincidente decide la acción: ALLOW, FLAG o DENY.
  5. Escaneo DLP (petición). Detectores incorporados y personalizados escanean el prompt en busca de datos sensibles. Los hallazgos se adjuntan a la traza y pueden desencadenar un resultado DLP_BLOCKED o DLP_WARNED.
  6. Reenvío al upstream. Las peticiones permitidas se enrutan al upstream configurado (OpenAI, Anthropic, servidor MCP interno o URL arbitraria). El proxy preserva la semántica de streaming para respuestas SSE.
  7. Escaneo DLP (respuesta). El cuerpo de la respuesta se escanea igual que la petición. Una respuesta bloqueada puede sustituirse por un error estructurado.
  8. Persistencia de la traza. Se escribe una fila con: ID de tenant, ID de agente, tipo de acción, estado, latencia, uso de tokens, cuerpos redactados de petición/respuesta, hallazgos DLP e IDs de las políticas que se activaron.

Headers

El proxy lee y emite un pequeño conjunto de headers X-RenLayer-* para que los agentes puedan atribuir las llamadas a usuarios o sesiones lógicos:

  • X-RenLayer-User: identificador opaco del usuario final (usado por los límites de tasa por usuario y el log de auditoría).
  • X-RenLayer-Session: agrupa múltiples llamadas en una sesión en la consola.
  • X-RenLayer-Trace-Id: devuelto en la respuesta para que los logs del lado del agente puedan unirse a las trazas de RenLayer.

Estos headers son opcionales. Cuando faltan, el proxy aún registra la llamada contra el agente.

Estados de acción

Cada traza termina con uno de estos estados:

  • ALLOWED: la petición coincidió con una política permisiva (o ninguna política) y se reenvió.
  • FLAGGED: la petición se reenvió pero se marcó para revisión.
  • DENIED: la política rechazó la petición antes del reenvío.
  • DLP_BLOCKED: un detector DLP coincidió con un patrón crítico; petición bloqueada.
  • DLP_WARNED: DLP coincidió con un patrón no crítico; petición reenviada pero registrada.

Consulta estados de acción para la máquina de estados completa.

Streaming

El proxy soporta respuestas en streaming (Server-Sent Events). Realiza un buffering mínimo para poder aplicar DLP en la respuesta sin romper el contrato de streaming con el cliente. Para streams muy largos, la traza se escribe cuando el stream se cierra.

Modos de fallo

  • Timeout del upstream: el proxy devuelve el error del upstream tal cual y escribe una traza con el error capturado.
  • Base de datos no accesible: por defecto el proxy falla abierto (la petición continúa, la traza se descarta) para preservar la disponibilidad del agente. Configurable por tenant.
  • Error en evaluación de política: falla cerrado (petición denegada) para que las políticas mal configuradas nunca permitan tráfico silenciosamente.

A dónde ir después

Última actualización: