RenLayer es multi-tenant desde la base. Cada recurso, agentes, claves de API, políticas, patrones DLP, trazas, entradas de auditoría, pertenece a exactamente un tenant, y cada ruta de código que toca datos lleva un alcance de tenant.
El modelo
- Tenant es la unidad de nivel superior. Mapea a una organización cliente, una unidad de negocio o cualquier otra frontera de aislamiento que quieras imponer.
- Cada otro recurso tiene una clave foránea
tenant_id. - Cada llamada a la API lleva un alcance de tenant, derivado del tipo de credencial:
- JWT de operador: claim
tenant_id, fijado en la emisión del token. - Clave de API de agente:
tenant_idresuelto a partir de la clave en cada petición.
- JWT de operador: claim
- Cada consulta a la base de datos en la API de plataforma se parametriza por el ID de tenant resuelto. No hay una ruta de consulta global que cruce tenants.
Esquema compartido, filas aisladas
RenLayer usa un modelo de aislamiento de esquema compartido, a nivel de fila en lugar de bases de datos separadas por tenant. Es intencional:
- El proxy puede aplicar una actualización de política en el momento en que aterriza, sin despliegue por tenant.
- Las uniones entre componentes (el proxy escribe trazas; la API las expone) son uniones locales de PostgreSQL, no llamadas entre bases de datos.
- Operar un esquema es más simple que operar miles.
El aislamiento se aplica en la capa de aplicación (consultas parametrizadas, endpoints con verificación de rol) y se refuerza en la capa de base de datos (políticas de seguridad a nivel de fila, donde la topología de despliegue lo soporta).
Qué protegen las fronteras de tenant
- Lecturas. Un tenant no puede leer las trazas, políticas, agentes, claves o log de auditoría de otro tenant a través de ninguna ruta estándar de la API.
- Escrituras. Un tenant no puede crear ni modificar recursos en otro tenant.
- Enumeración. Un tenant no puede enumerar la existencia de otros tenants.
- Hallazgos DLP y cuerpos revelados. Los permisos de revelación están delimitados al tenant del operador que llama.
Qué no protegen las fronteras de tenant
- Upstreams compartidos. Si dos tenants usan la misma cuenta de OpenAI, RenLayer no puede impedirlo, la credencial y el presupuesto se comparten upstream.
- Canales laterales por tiempo. RenLayer no promete que dos tenants no puedan inferir carga en la plataforma a partir del tiempo de respuesta.
- Operadores entre tenants. Un usuario puede pertenecer a múltiples tenants por concesión explícita; cambia entre tenants en la consola. Esto es por diseño para escenarios de partners / consultoría.
Acceso entre tenants para soporte
Las atenciones de soporte ocasionalmente requieren que un ingeniero de RenLayer vea los datos de un cliente. Es una ruta separada y auditada: requiere consentimiento explícito del cliente, queda registrada en el log de auditoría del tenant afectado y tiene tiempo limitado. Los JWTs estándar no pueden alcanzar esta ruta.
A dónde ir después
- Conceptos de la API: el árbol de recursos bajo un tenant.
- Consola: log de auditoría: donde se registra el acceso entre tenants.
- Glosario: vocabulario compartido.