Platform Foundation

Tenant Isolation

Row-Level Security at the PostgreSQL layer enforces tenant boundaries on every query. Not a filter, not a tag — a schema-level guarantee.

Why this matters for enterprise procurement

Most multi-tenant SaaS isolates tenants with `WHERE tenant_id = ?` filters in application code. One missing filter, one bug, and tenant data leaks. FrontLine moves isolation into the database: PostgreSQL Row-Level Security policies reject queries that don't carry a tenant claim, so application bugs cannot cause cross-tenant data exposure.

How it's implemented

Isolation enforced at the schema, not patched on in application code

Every table carrying tenant-scoped data has an RLS policy bound to the `app.tenant_id` session variable. The API service sets that variable from the authenticated JWT's tenant claim before any query runs. Policies are `RESTRICTIVE` (deny-by-default), so a missing or mismatched session variable returns zero rows rather than leaking. RLS is enabled at the database role level — even direct DB access via a connection pool cannot bypass it. Policies are version-controlled alongside the schema.

Capabilities

What's covered out of the box

RLS on every tenant-scoped table (130+ tables)

Deny-by-default RESTRICTIVE policies

Tenant claim set from JWT, never from user input

Per-client and per-LOB sub-policies on relevant tables

Connection pooler enforces the same role membership

Schema migrations gate-check that new tables have RLS enabled

Test suite asserts cross-tenant access is rejected for every endpoint

Audit log captures any policy-rejected query attempt

Standards & compliance

Audit-ready artifacts your reviewers can lean on

SOC 2 Type II — logical separation controls
PIPEDA — reasonable safeguards for personal information
GDPR Article 32 — security of processing
Audit-ready evidence: RLS policy DDL exported on request

Procurement FAQ

What security and compliance reviewers actually ask

Can the application accidentally leak cross-tenant data?+

No. Even if application code forgets to filter, the database rejects the query because the tenant session variable doesn't match. The application would receive an empty result set.

How is the tenant claim verified?+

It comes from a signed JWT, set at session start by the API authentication middleware. Users cannot set or alter their own tenant claim.

What about database administrators?+

Application DB roles run with RLS enabled. Privileged DBA roles required to bypass RLS are not in the application connection path — they're behind a separate, audited break-glass procedure.

How do you test that isolation works?+

Integration tests for every endpoint include a 'try to access another tenant's data' case that must return zero rows or 404. Tests fail the build if isolation regresses.

Run this past your security team

We share security overviews, RLS policy DDL, audit-event schemas, and SOC 2 progress on request. Book a 30-minute security review with the founders.

Book a security review Back to the Atlas