01
File-access denial
Recognize configured server-file functions inside expressions, nested queries, and multi-statement input.
Dangerous-function denial
A SELECT can still cross a security boundary.
Safe Boundary inspects function calls inside parsed SQL and denies known operations that can read server files, export large objects, or reach outside the intended database path.
Dangerous-function denialA read-like statement can still escape its boundary
Deny set activepg_read_file()→lo_export()→dblink()→ Function gateParsed call inspection
ALLOW SAFE READ
BLOCK ESCAPE
Why this exists
Read-only syntax is not the same as harmless behavior
PostgreSQL exposes powerful functionality through callable functions. A statement can begin with SELECT and still attempt file access, large-object export, cross-database access, or another operation that is inappropriate for a bounded application or AI tool.
Safe Boundary walks the parsed function calls and compares them with an explicit dangerous-function policy. A match is blocked before PostgreSQL executes it, even when the surrounding statement otherwise looks read-only.
What it does
Concrete controls, stated precisely.
02
Large-object protection
Deny known large-object operations that can move data beyond the intended result path.
03
Cross-database boundaries
Refuse configured functions that can turn an approved connection into a bridge to another data source.
How it works
A visible enforcement sequence.
- 1
Parse
Build the complete PostgreSQL syntax tree instead of scanning keywords.
- 2
Walk
Inspect function calls throughout the statement structure.
- 3
Match
Compare resolved names with the configured dangerous-function policy.
- 4
Block
Return a controlled policy error and record the reason before execution.
Protected when
- ✓SQL routed through Safe Boundary wire or MCP enforcement
- ✓Known dangerous calls nested inside otherwise read-like statements
- ✓Bounded query paths that should not reach server files or external databases
Important boundaries
- —The deny policy must evolve with installed extensions and the deployment threat model
- —Least-privileged PostgreSQL roles remain the essential backstop
- —Functions and endpoints outside a routed Safe Boundary surface are not inspected
Continue the story
Related Safe Boundary pages
Read-only query enforcement →
See how complete statements are classified before execution.
MCP server →
Give AI tools a bounded PostgreSQL query surface with local audit.
Security model →
Understand trust boundaries, credentials, identity, and bypass conditions.
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.