Multi-tenant SaaS

Preserve tenant isolation. Add a value boundary.

Keep tenant authorization in PostgreSQL RLS and application policy. Use Safe Boundary to preserve upstream identity and add read-only controls, masking, inference protection, and audit.

Get early access
Review the security model →

Why this exists

Defense in depth, not a substitute tenant model

Tenant isolation is application- and schema-specific. Safe Boundary does not infer ownership or inject tenant_id predicates into arbitrary SQL.

It can preserve the role or JWT that drives existing RLS, then prevent raw configured values from leaving routed interfaces. This helps support tools and AI agents that need broad row visibility but not raw secrets.

What it does

Concrete controls, stated precisely.

RLS-preserving paths

Keep upstream database roles and PostgREST JWT semantics intact.

Support-tool masking

Hide configured customer values from support, analytics, or agent responses.

Routed-path audit

Record decisions with the identity or attribution available on each surface.

Support-tool scenario

Let support inspect the right rows without returning every raw value.

Illustrative workflow: RLS decides which tenant rows are visible; Safe Boundary masks configured columns in the routed support path.

Support request

SELECT tenant_id, email, plan, last_seen
FROM customers
WHERE tenant_id = $1;

Expected boundary behavior

Rows: decided by existing RLS
email: configured mask
plan / last_seen: policy-dependent
tenant_id injection: not performed

How it works

A visible enforcement sequence.

  1. Prove RLS

    Test tenant isolation against each database role and JWT class.

  2. Identify values

    Define columns that stay masked within allowed rows.

  3. Route tools

    Protect support, AI, and REST paths with the matching surface.

  4. Test bypasses

    Verify direct endpoints are unavailable to constrained callers.

Protected when

  • ✓Configured values in rows allowed by upstream policy
  • ✓RLS semantics on passthrough paths
  • ✓Support and AI access routed through Safe Boundary

Important boundaries

  • •No tenant-policy discovery or predicate injection
  • •Safe Boundary supports PostgreSQL, not Oracle, SQL Server, or MySQL
  • •An RLS bypass role remains powerful upstream

Continue the story

Related Safe Boundary pages

Preserving RLS →

See the exact row-security contract.

Supabase REST protection →

Mask PostgREST responses and stop filters from becoming inference oracles.

Security model →

Understand trust boundaries, credentials, identity, and bypass conditions.

Test the boundary on a real access path.

Start in observe mode and validate the policy against representative traffic before you enforce it. That gives the team evidence for each decision, along with explicit bypass controls for the cases that need a deliberate exception.

Get early access