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 denialRead-only SQL can still call escape functions
Deny set configuredpg_read_file()→lo_export()→dblink()→ Function gateParsed function calls
ALLOW SAFE READ
BLOCK DANGEROUS
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.
Large-object protection
Deny known large-object operations that can move data beyond the intended result path.
Cross-database boundaries
Refuse configured functions that can turn an approved connection into a bridge to another data source.
Function families
Treat read-like SQL with powerful functions as a separate risk class.
| Decision | Family | Why it is reviewed |
|---|---|---|
| Server-file access | Can read from or write to the database host’s filesystem | |
| Large-object operations | Can move data through an alternate result path | |
| Cross-database / external access | Can reach beyond the intended database boundary |
How it works
A visible enforcement sequence.
Parse
Build the complete PostgreSQL syntax tree instead of scanning keywords.
Walk
Inspect function calls throughout the statement structure.
Match
Compare resolved names with the configured dangerous-function policy.
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 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.