Structural classification
Decisions use parsed statement structure instead of keyword matching.
Query enforcement
Read-only means read-only.
Safe Boundary classifies the parsed statement, not just its first keyword. Enforce mode refuses non-read-only SQL, dangerous functions, malformed input, and multi-statement bypass attempts.
Read-only enforcementClassify structure, not the first keyword
Enforce modeSELECT account→DELETE users→SELECT pg_read_file()→ SQL gateParsed SQL structure
ALLOW READ
BLOCK WRITE / UNSAFE
Why this exists
Block by SQL meaning, not string patterns
A regular-expression firewall can miss writes hidden in common table expressions, function calls, comments, or multiple statements. Safe Boundary uses PostgreSQL syntax trees and an explicit dangerous-function deny set.
Observe mode forwards traffic while recording what would have been blocked or masked. Enforce mode changes the data path and fails closed on requests it cannot safely classify.
What it does
Concrete controls, stated precisely.
Dangerous-function deny set
Known file, large-object, and cross-database escape functions are denied inside otherwise read-like SQL.
Controlled failures
Blocked SQL returns a policy error before the statement reaches PostgreSQL.
Blocked examples
Classify the complete statement before PostgreSQL sees it.
These are illustrative examples of the kinds of statements the read-only gate is designed to refuse.
| Decision | Statement shape | Enforce-mode result |
|---|---|---|
| CREATE TABLE target… | Blocked as non-read-only | |
| SELECT …; UPDATE … | Blocked as multi-statement / non-read-only | |
| SELECT dangerous_function(…) | Blocked when the function matches the deny policy |
How it works
A visible enforcement sequence.
Parse
Build the PostgreSQL syntax tree and reject invalid structure.
Classify
Determine whether the statement is read-only and inspect function calls.
Decide
Apply observe or enforce behavior from deployment policy.
Audit
Record the reason, surface, and available caller attribution.
Protected when
- ✓SQL routed through an enforcing surface
- ✓Writes hidden behind complex syntax
- ✓Calls to the configured dangerous-function deny set
Important boundaries
- •Current policy is deployment-wide, not a different ruleset for every agent
- •Historical replay and centrally versioned policy bundles are not current capabilities
- •Database permissions remain the final backstop and should stay least-privileged
Continue the story
Related Safe Boundary pages
Dangerous-function denial →
Block file, large-object, and cross-database escape functions inside read-like SQL.
PostgreSQL wire proxy →
Protect application, ORM, psql, and BI traffic on the PostgreSQL protocol.
MCP server →
Give AI tools a bounded PostgreSQL query surface with local audit.
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.