Docs

Primeros pasos

Arquitectura

Cómo encajan el Proxy, la API de plataforma y la Consola de RenLayer, un esquema PostgreSQL compartido, un modelo de datos multi-tenant, tres componentes desplegables.

RenLayer está dividido en tres componentes desplegables que comparten un único esquema PostgreSQL. Cada componente posee sus responsabilidades; juntos forman un único plano de gobernanza.

Los tres componentes

  • Proxy (renlayer-proxy): un proxy inverso Rust + Axum situado en la ruta de la petición. Recibe el tráfico del agente, clasifica la llamada, evalúa políticas, ejecuta detectores DLP, reenvía al proveedor upstream (OpenAI, Anthropic, servidores MCP internos, APIs de terceros), captura la respuesta y escribe una fila de traza.
  • API de plataforma (renlayer-api): una API REST Rust + Axum responsable de la gestión de tenants, autenticación (JWT + OTP), ciclo de vida de agentes y claves de API, CRUD de políticas y consultas de trazas. Es el único componente con el que la consola habla.
  • Consola (renlayer-console): una aplicación Next.js que renderiza el dashboard, el explorador de sesiones, los agentes, las políticas, las reglas de DLP y el log de auditoría. Es un cliente fino sobre la API de plataforma.

Plano de datos compartido

Los tres componentes leen y escriben en la misma base de datos PostgreSQL (esquema renlayer). Esto es intencional:

  • El proxy puede aplicar una actualización de política en el momento en que aterriza, sin retraso de bus de eventos.
  • La consola puede pasar de un gráfico de alto nivel del dashboard al cuerpo exacto de la petición sin cruzar una frontera de servicio.
  • Tenants, agentes, claves de API, políticas y trazas comparten el mismo modelo de identidad multi-tenant.

Flujo de la petición

Una petición típica sigue esta ruta:

  1. Tu agente llama a un proveedor de modelos a través de la URL del proxy en lugar de la URL del proveedor directamente.
  2. El proxy autentica al agente mediante su clave de API, identifica el tenant y resuelve el registro del agente.
  3. El proxy evalúa políticas en orden de prioridad. Una política coincidente puede ALLOW, FLAG o DENY la llamada.
  4. Los detectores DLP escanean el prompt y la respuesta en busca de PII, secretos, código fuente y patrones personalizados.
  5. Si la política permite la llamada, el proxy la reenvía al proveedor upstream; en caso contrario devuelve un error estructurado.
  6. El proxy escribe una fila de traza con el estado, latencia, conteo de tokens, cuerpo redactado y cualquier hallazgo DLP.
  7. La consola consulta la API para mostrar la traza en el explorador de sesiones y en el log de auditoría.

Multi-tenancy

Cada fila del esquema (agentes, claves de API, políticas, trazas, hallazgos DLP) lleva un tenant_id. La API de plataforma impone el alcance al tenant en cada consulta; el proxy resuelve un tenant a partir de la clave de API en cada petición. No hay estado global compartido entre tenants.

A dónde ir después

Última actualización: