Why Safe Boundary

A database role grants access. It does not define every safe use.

Applications, human tools, AI agents, and Supabase clients reach the same PostgreSQL data through different protocols. Safe Boundary adds an explicit enforcement decision to each routed path.

Get early access
Review the security model →

Why this exists

AI multiplied the routes to production data

Database grants and row-level security remain the authority for authentication and row access. They do not necessarily prevent an approved read path from returning raw sensitive values, accepting an unsafe function call, or exposing more data than an AI workflow needs.

Safe Boundary sits on the protocol the caller actually uses. It parses the request, applies configured query and data policy, preserves upstream authorization where supported, and records the decision before protected output reaches the caller.

What it does

Concrete controls, stated precisely.

01

Control query structure

Classify complete PostgreSQL statements, refuse writes on read-only paths, and deny known escape functions before execution.

02

Control returned values

Map eligible output to configured catalog columns and return type-compatible masked representations.

03

Keep decision evidence

Record allow, block, and mask outcomes with the identity or attribution each surface can establish.

How it works

A visible enforcement sequence.

  1. 1

    Map callers

    List the applications, people, agents, and REST clients that can reach production data.

  2. 2

    Map paths

    Identify whether each caller uses PostgreSQL wire, MCP tools, or Supabase PostgREST.

  3. 3

    Choose controls

    Apply read-only, masking, inference, and audit policy appropriate to that path.

  4. 4

    Close bypasses

    Remove direct endpoints and credentials from callers that must stay inside the boundary.

Protected when

  • ✓Requests routed through a supported enforcement surface
  • ✓Configured sensitive PostgreSQL columns and supported response shapes
  • ✓Unsafe SQL and known dangerous functions recognized by policy

Important boundaries

  • —Safe Boundary complements PostgreSQL permissions and RLS rather than replacing them
  • —Direct database and Supabase endpoints remain bypasses until deployment closes them
  • —Identity strength differs between PostgreSQL roles, JWTs, human certificates, and MCP labels

Continue the story

Related Safe Boundary pages

Architecture →

See how the three enforcement surfaces share policy and audit semantics.

Security model →

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

Observe to enforce →

Measure policy decisions on representative traffic before activating enforcement.

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.

Get early access