Configured field masks
Apply deterministic masks to explicitly protected columns and supported response types.
Fintech and payments
Keep raw payment data out of routine reads.
Use explicit column rules to mask account identifiers, emails, PAN-like fields, and other sensitive PostgreSQL values on selected wire, MCP, and PostgREST read paths.
Fintech and paymentsReturn useful shapes without raw account data
Payment fields maskedDATABASE RESULTpan: 4242 4242 4242 4242iban: DE89 3704…email: ada@acme.io
Payment boundaryDeterministic masks
PROTECTED RESULT•••• •••• •••• 4242DE•• ••••…a••@acme.io
MASK
Why this exists
Protect known fields with deterministic policy
Safe Boundary returns type-compatible masked values and can preserve a suffix for supported string masks. It does not tokenize source data or automatically classify arbitrary payloads.
Combine the boundary with least-privileged roles, RLS, secrets management, network isolation, immutable retention, and your PCI or financial-control program.
What it does
Concrete controls, stated precisely.
Read-only tool paths
Prevent analytics or AI tools from using the protected path for writes or dangerous functions.
RLS preserved
Keep PostgreSQL roles and Supabase JWT-based row authorization in force.
Data-control distinction
Masking is not tokenization, vaulting, or classification.
| Decision | Control | What this page means |
|---|---|---|
| Masking | Return a configured, type-compatible representation on a routed read path | |
| Tokenization / vault | Not supplied by this capability; source-system design remains required | |
| Classification | Rules are explicit; automatic PAN/IBAN discovery is not claimed | |
| Compliance | A technical safeguard, not an automatic PCI scope or certification conclusion |
How it works
A visible enforcement sequence.
Inventory
Identify in-scope tables and columns from your classification program.
Mask
Define explicit policy and verify client type compatibility.
Constrain
Use least-privileged roles and query enforcement together.
Evidence
Export decision records into the controlled audit pipeline.
Protected when
- ✓Explicitly configured sensitive fields
- ✓Routed PostgreSQL, MCP, and PostgREST reads
- ✓Unsafe statements recognized by policy
Important boundaries
- •No automatic PAN or IBAN discovery and no vault-backed tokenization
- •No Oracle, SQL Server, or MySQL enforcement surface
- •PCI scope and compliance conclusions require assessment of the whole system
Continue the story
Related Safe Boundary pages
Schema-aware masking →
Configure which columns are protected and preserve compatible response types.
Audit and attribution →
Record policy outcomes and the identity information each surface can establish.
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.