Multi-tenant isolation and Postgres RLS

Isolation is not only application-layer WHERE clauses. Agent Forge validates tenant, owner, and model routing together in request context. In Postgres mode, session-level app.tenant_id drives row-level security so a missed filter cannot silently expose rows.

Three dimensions

Dimension	Meaning
tenant	Which data plane may be touched
owner	Who may use it; sessions and related resources filter by owner
model	Logical model routing (request header or route table)

Any miss rejects the request. After identity binding, tenant and role are authoritative on the server. See identity and tenant binding.

flowchart TD
  Req[Request] --> Ctx[Tenant + Owner + Model + Role]
  Ctx --> PG[SET LOCAL app.tenant_id]
  PG --> RLS[RLS policies filter rows]

RLS

After app.tenant_id is set in the transaction, business tables expose only that tenant’s rows per policy. RLS-enabled tables include sessions and messages, triggers and runs, roles, audit, approval, observability, resource sharing, teams and team runs, and related surfaces (see current migrations). Cross-tenant identifiers such as project metadata may sit outside the same tenant RLS set.

Production connection roles must be NOBYPASSRLS (non-superuser, cannot bypass). Open source provides column and read isolation; tenant/account write management and related capabilities are gated by the enterprise multitenant license feature. Deployment checks: deployment verification.

Storage selection: with DATABASE_URL / AGENTFORGE_DATABASE_URL, use Postgres; otherwise SQLite. AGENTFORGE_DB=pg without a connection string fails startup—no silent mix.

Related reading: