Multi-tenancy

RenLayer is multi-tenant from the ground up. Every resource, agents, API keys, policies, DLP patterns, traces, audit entries, is owned by exactly one tenant, and every code path that touches data carries a tenant scope.

The model

• Tenant is the top-level unit. It maps to a customer organization, a business unit, or any other isolation boundary you want to enforce.
• Every other resource has a tenant_id foreign key.
• Every API call carries a tenant scope, derived from the credential type:
  • Operator JWT: tenant_id claim, set at token issuance.
  • Agent API key: tenant_id resolved from the key on every request.
• Every database query in the Platform API is parameterized by the resolved tenant ID. There is no global query path that crosses tenants.

Shared schema, isolated rows

RenLayer uses a shared-schema, row-level isolation model rather than separate databases per tenant. This is intentional:

• The proxy can apply a policy update the moment it lands, with no per-tenant deployment.
• Cross-component joins (proxy writes traces; API surfaces them) are local PostgreSQL joins, not cross-database calls.
• Operating one schema is simpler than operating thousands.

Isolation is enforced at the application layer (parameterized queries, role-checked endpoints) and reinforced at the database layer (row-level security policies, where supported by the deployment topology).

What tenant boundaries protect

• Reads. A tenant cannot read another tenant’s traces, policies, agents, keys, or audit log through any standard API path.
• Writes. A tenant cannot create or modify resources in another tenant.
• Enumeration. A tenant cannot enumerate the existence of other tenants.
• DLP findings and unmasked bodies. Reveal permissions are scoped to the calling operator’s tenant.

What tenant boundaries do not protect

• Shared upstreams. If two tenants both use the same OpenAI account, RenLayer cannot prevent that, the credential and the budget are shared upstream.
• Side-channel timing. RenLayer does not promise that two tenants cannot infer load on the platform from response timing.
• Cross-tenant operators. A user may belong to multiple tenants by explicit grant; they switch between tenants in the console. This is by design for partner / consulting scenarios.

Cross-tenant access for support

Support engagements occasionally require a Renlayer engineer to view a customer’s data. This is a separate, audited path: it requires explicit customer consent, is recorded in the audit log of the affected tenant, and is time-limited. Standard JWTs cannot reach this path.

Where to go next

• API concepts: the resource tree under a tenant.
• Console: audit log: where cross-tenant access is recorded.
• Glossary: shared vocabulary.