RLS preservation

Keep row policy where it belongs.

Safe Boundary complements row-level security; it does not replace or synthesize it. Wire passthrough preserves the role, while REST forwards Supabase JWT and apikey headers.

Why this exists

Rows upstream, sensitive values at the boundary

PostgreSQL and Supabase remain authoritative for which rows a caller may access. Safe Boundary adds structural query controls and configured value masking on routed traffic.

No tenant predicate is injected. If RLS is missing, disabled, or bypassed by a powerful upstream role, Safe Boundary does not manufacture the missing row-authorization policy.

What it does

Concrete controls, stated precisely.

01

Wire role preservation

Passthrough relays authentication so PostgreSQL evaluates grants and RLS as the connecting role.

02

REST JWT preservation

Headers reach PostgREST unchanged so Supabase role switching and RLS still run.

03

Column boundary

Masking and inference protection add controls row-level policy alone does not provide.

How it works

A visible enforcement sequence.

  1. 1

    Keep RLS

    Define and test row policies in PostgreSQL or Supabase.

  2. 2

    Route

    Use an RLS-preserving authentication mode or REST filter.

  3. 3

    Mask

    Protect sensitive columns for allowed rows.

  4. 4

    Test both

    Verify row isolation and response masking independently.

Protected when

  • Existing RLS on supported passthrough paths
  • Sensitive values in allowed rows
  • PostgREST inference on configured fields

Important boundaries

  • No automatic tenant-filter injection
  • RLS bypass roles remain powerful
  • Performance depends on workload and must be measured in your deployment

Continue the story

Related Safe Boundary pages

Test the boundary on a real access path.

Start in observe mode, validate the policy against representative traffic, and move to enforcement with explicit bypass controls.