Decision preview
Evaluate supported traffic against policy and record the expected outcome without immediately blocking the request.
Observe to enforce
See the decision first. Enforce when the evidence is ready.
Use observation on supported proxy and filter paths to find client assumptions, incomplete masking rules, and unexpected query shapes before policy begins changing production behavior.
Observe to enforcePreview policy against representative traffic
Observe modeWIRE / ORM→PREPARED SQL→POSTGREST / REST→ Policy previewEvaluate · forward unchanged
WOULD ALLOW
WOULD BLOCK / MASK
Why this exists
A safe rollout is part of the security design
Inline enforcement affects real application behavior. Switching it on before exercising representative traffic can block legitimate queries, reveal incomplete field coverage, or hide a direct path that never crossed the boundary.
Observation separates policy evaluation from policy effect. Teams can inspect would-allow, would-block, and would-mask outcomes, correct the policy or client path, and then activate enforcement with a known change set.
What it does
Concrete controls, stated precisely.
Compatibility evidence
Exercise real drivers, ORMs, prepared statements, REST shapes, and application query patterns.
Explicit cutover
Move a validated path into enforcement, then watch block and mask outcomes for regressions.
Exit criteria
Make “ready to enforce” a reviewable checklist.
- □Representative drivers, ORMs, prepared statements, REST shapes, and MCP tools have crossed the boundary.
- □Would-block and would-mask events have owners and an explicit disposition.
- □Protected columns resolve unambiguously and expected client response types remain compatible.
- □Direct DSNs, original REST URLs, and alternate tools have been removed or proven unreachable.
- □The team has a rollback plan and knows which audit sink is authoritative for each surface.
How it works
A visible enforcement sequence.
Inventory
Record every DSN, REST base URL, MCP configuration, and credential used by the protected workflow.
Observe
Route representative traffic through the boundary and collect policy decisions.
Resolve
Fix unsupported client behavior, missing rules, and direct-path dependencies.
Enforce
Activate blocking and masking, close bypasses, and monitor the resulting decision stream.
Protected when
- ✓Rollouts tested with representative client and query behavior
- ✓Policy changes reviewed before they alter the protected path
- ✓Enforcement cutovers backed by observable decisions
Important boundaries
- •Observation records a decision but does not itself stop a harmful request
- •Traffic that never reaches Safe Boundary cannot appear in its observation data
- •A short or synthetic test window may miss infrequent production query shapes
Continue the story
Related Safe Boundary pages
Deployment and bypass prevention →
Route constrained callers through the boundary and close direct access paths.
Architecture →
See how the three enforcement surfaces share policy and audit semantics.
Audit and attribution →
Record policy outcomes and the identity information each surface can establish.
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.