SQL-aware enforcement

Understand the query before changing it.

Safe Boundary parses PostgreSQL statements and resolves selected output to real catalog columns. That supports precise read-only decisions and eligible projection rewrites without fragile regex.

Get early access
Review the security model →

Why this exists

Narrow rewriting is safer than magical rewriting

The current product rewrites eligible SELECT projections for masking. It understands aliases, stars, casts, and supported expression shapes well enough to identify protected output and refuse ambiguous cases.

It does not inject tenant predicates, repair application authorization, add arbitrary JOIN conditions, or reinterpret business logic. Those responsibilities remain in grants, RLS, and application policy.

What it does

Concrete controls, stated precisely.

AST-based

The decision uses parsed PostgreSQL structure, including nested and multi-statement forms.

Catalog-aware

Projection output maps to schema types and columns before a mask is selected.

Ambiguity fails closed

Protected output that cannot be proven safe is blocked rather than passed through raw.

Rewrite boundary

See the narrow transformation the parser can prove safe.

Illustrative SQL only. Safe Boundary does not inject tenant predicates or rewrite arbitrary business logic.

Incoming projection

SELECT customer_id, email, status
FROM customers;

Eligible protected projection

SELECT customer_id,
       mask_email(email) AS email,
       status
FROM customers;

How it works

A visible enforcement sequence.

  1. Parse

    Build a syntax tree from incoming SQL.

  2. Resolve

    Map returned expressions to catalog columns and types.

  3. Rewrite

    Apply configured masks to eligible projection output.

  4. Refuse

    Block protected shapes that cannot be rewritten safely.

Protected when

  • ✓Supported PostgreSQL SELECT projections
  • ✓Configured column rules
  • ✓Queries whose output resolves unambiguously

Important boundaries

  • •No automatic tenant-predicate injection
  • •No arbitrary business-logic rewriting
  • •No claim of complete support for every PostgreSQL extension or procedural language

Continue the story

Related Safe Boundary pages

Schema-aware masking →

Configure which columns are protected and preserve compatible response types.

PostgreSQL wire proxy →

Protect application, ORM, psql, and BI traffic on the PostgreSQL protocol.

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