Natural Language SQL Agents Need Guardrails Before Orchestration

The default pattern for natural-language Structured Query Language (SQL) agents is a chat box that asks a large language model to write a query and hands it to an automation workflow; the production pattern is a database-agent control plane that treats generated SQL as untrusted code until policy, cost, schema, and audit checks prove otherwise.

Situation

PostgreSQL chat agents are becoming the new analyst interface: a user asks for “high-risk transactions in Q3,” an orchestrator generates SQL, a workflow tool such as n8n executes it, and a summarizer sends the result to Slack, email, or an embedded CopilotKit panel.

That is useful, but it moves the hard part. The risk is no longer whether a model can write a plausible SELECT. The risk is whether the system can prove that the generated query is safe, bounded, semantically correct, and reviewable after something goes wrong.

Approach	Default implementation	Production implementation
Natural language to SQL	Prompt an LLM with schema text	Route intent through allowlisted data products
Execution	n8n PostgreSQL node runs generated SQL	Read-only role, timeout, EXPLAIN, row limit, audit entry
Result delivery	Summarize rows directly	Mask, shape, validate, then summarize
Trust model	Prompt instructions	Database permissions and policy gates

The Problem

The failure mode is not only “the model writes invalid SQL.” PostgreSQL will reject invalid syntax cleanly. The expensive failures are valid SQL statements that answer the wrong question, scan the wrong table, cross tenant boundaries, or leak fields through the summary layer.

Failure point	What breaks	Why it matters
Schema grounding	The model joins transactions.user_id when the business question meant store_id	The query succeeds and produces a confident false answer
Access control	Prompt says “read-only,” but the database role can still INSERT, UPDATE, or call unsafe functions	Prompt text is not a security boundary; PostgreSQL privileges are
Cost control	Generated SQL omits LIMIT or joins two wide tables without selective predicates	A single chat request can become a production incident on a shared Aurora PostgreSQL writer
Tenant isolation	The query omits tenant_id = current_setting('app.tenant_id') or equivalent policy context	Cross-customer disclosure is a compliance incident, not a dashboard bug
Result summarization	The SQL is allowed, but the summarizer repeats sensitive columns from returned rows	Policy has to apply after execution, not only before it
Auditability	Only the natural-language prompt is logged	Incident review needs prompt, generated SQL, role, plan, latency, row count, and delivery channel

PostgreSQL gives you the pieces: privileges, row-level security, statement_timeout, EXPLAIN, views, schemas, and extensions such as pg_stat_statements. The agent has to assemble them into an operating model. The core question is not “can an LLM write SQL?” It is: what must be true before generated SQL is allowed to touch production data?

Guardrail the SQL Agent as a Control Plane

The right architecture is a narrow control plane around the model. The model proposes. The database and policy layer dispose.

flowchart TD
    User[User question] --> Intent[Intent classifier — analytical task]
    Intent --> Catalog[Approved catalog — tables and metrics]
    Catalog --> Generator[SQL generator — constrained prompt]
    Generator --> Parser[SQL parser — abstract syntax tree]
    Parser --> Policy[Policy gate — role tenant limit]
    Policy --> Plan[Plan gate — explain and cost]
    Plan --> Execute[PostgreSQL replica — read only]
    Execute --> Shape[Result shaping — masking and limits]
    Shape --> Summary[LLM summary — bounded context]
    Summary --> Delivery[Delivery channel — UI Slack email]
    Execute --> Audit[Audit log — prompt SQL rows latency]
    Policy --> Reject[Reject with reason]
    Plan --> Reject

1. Start with approved data products, not raw schema dumps.
   Give the agent a catalog of approved views, metric definitions, join keys, and allowed filters. A production catalog should say “finance.v_high_risk_transactions is the approved surface for fraud review,” not “here are 180 tables, good luck.” PostgreSQL views are the cheapest boundary; materialized views are reasonable when the approved question is repeatedly expensive.
   Verification: run the evaluation set against only approved views and fail any query that references a base table directly.

2. Use a read-only database role with a short statement timeout.
   The execution role should have SELECT on approved schemas only, no ownership of application tables, no write grants, and no ability to mutate session state beyond approved settings. PostgreSQL documents statement_timeout as a server-side limit that aborts statements exceeding the configured duration, so set it at the role or connection level, not inside the prompt. A typical starting point for an analyst agent is statement_timeout = '5s' and idle_in_transaction_session_timeout = '10s', then tune after observing real plans.
   Verification: connect as the agent role and prove INSERT, UPDATE, DELETE, CREATE, and direct access to restricted schemas fail.

3. Parse SQL before execution.
   Do not validate SQL with startswith("SELECT"). A generated statement can hide risk in common table expressions, functions, comments, multiple statements, or dialect edge cases. Parse into an abstract syntax tree with a PostgreSQL-aware parser, reject multiple statements, reject write operations, reject disallowed functions, and require a top-level row limit unless the approved view already enforces one.
   Verification: maintain negative tests for COPY, CREATE TEMP TABLE, SELECT pg_sleep(60), multi-statement payloads, and unrestricted scans.

4. Run EXPLAIN as a cost gate.
   PostgreSQL EXPLAIN can return JSON, which makes it usable as a machine check rather than a string review. The gate should reject plans with sequential scans over large relations, missing tenant predicates, or estimated row counts above the channel limit. This is not perfect; planner estimates drift when statistics are stale. It is still better than discovering the plan after the workflow is already waiting on a hot query.
   Verification: compare accepted plans against a blocked corpus of known bad joins and full-table scans.

5. Shape results before summarization.
   The summarizer should receive the smallest useful result: selected columns, masked sensitive fields, row caps, aggregate outputs where possible, and explicit caveats. If the user asks for “anomalies,” return the rule used to classify anomaly, not just a dramatic sentence.
   Verification: assert that restricted columns such as Social Security numbers, access tokens, patient identifiers, or cardholder fields cannot appear in the summarizer input.

6. Audit the complete chain.
   Store user_id, prompt, resolved intent, generated SQL, rejected reason, execution role, execution latency, row count, delivery channel, model name, and schema catalog version. pg_stat_statements can help correlate normalized query patterns at the database layer, but it does not replace application-level audit context.
   Verification: pick any delivered answer and reconstruct who asked, what SQL ran, what policy allowed it, and what rows were exposed.

In Practice

The documented pattern is already visible in production database and agent tooling. These are not anecdotes; they are public design constraints that point in the same direction.

Public source	Documented behavior	Engineering implication
PostgreSQL Row Security Policies	PostgreSQL row security policies restrict which rows can be returned or modified by normal queries and data modification commands	Tenant isolation belongs in database policy or approved views, not only in LLM instructions
PostgreSQL statement_timeout	PostgreSQL cancels statements that exceed the configured timeout; the setting can be applied per session or role rather than globally	Query cost control should live in the connection or role configuration, not in prompt text
PostgreSQL EXPLAIN	PostgreSQL exposes estimated cost and row counts, and machine-readable EXPLAIN formats such as JSON	A control plane can reject bad plans before execution, while still treating planner estimates as imperfect signals
LangChain SQLDatabaseChain security note	LangChain warns that SQL database credentials should be narrowly scoped because the chain may attempt destructive commands if prompted	The execution credential must be least-privilege even when the application claims to be analytical
Supabase Row Level Security guidance	Supabase tells teams to enable RLS on exposed schemas and treat RLS as defense in depth around PostgreSQL data access	Cloud-hosted PostgreSQL does not remove the need for database-enforced policy
AWS Bedrock text-to-SQL architecture	AWS describes a text-to-SQL architecture that routes questions through context retrieval, enforces Row-Level Security, validates SQL, executes against Redshift, and emits traces to CloudWatch	Public reference architectures put orchestration, policy, validation, execution, and observability into separate control points

This is why a simple Crafted AI Framework, n8n, CopilotKit, and PostgreSQL demo is useful but incomplete. The walkthrough shows the control flow: question, orchestration, SQL execution, summarization, delivery. Production requires the missing gates between those boxes.

A generated query like this is syntactically ordinary:

SELECT
    t.transaction_id,
    t.user_id,
    t.amount,
    t.date,
    c.risk_level
FROM transactions t
JOIN countries c
    ON t.destination_country = c.country_code
WHERE t.amount > 10000
  AND t.date BETWEEN DATE '2024-07-01' AND DATE '2024-09-30'
  AND c.risk_level = 'high'
LIMIT 100;

The control-plane question is whether it is authorized. Does user_id mean customer, employee, merchant, or account owner? Should the filter be store_id = 123, as the user asked, or user_id = 12345, as the generated SQL guessed? Is countries.risk_level the approved compliance source or a stale enrichment table? Is the query running on a replica with a 5-second timeout or on the writer behind checkout traffic?

That is the gap between a demo and a system a platform lead can defend in a post-incident review.

Where It Breaks

Failure mode	Trigger	Fix
Plausible wrong metric	User asks for “revenue,” model uses gross transaction amount instead of recognized revenue	Force metric names through a semantic catalog with owner-approved SQL definitions
Expensive valid query	PostgreSQL 15 or 16 planner chooses a sequential scan because statistics are stale after a large load	Run ANALYZE, reject high estimated row counts, and route heavy questions to precomputed views
Tenant leak	Agent omits tenant predicate on a shared table	Use Row Level Security or tenant-scoped views and set tenant context server-side
Prompt injection through data	A table row contains text instructing the model to reveal hidden fields	Treat database content as untrusted input and summarize only shaped, masked results
Summary overclaim	LLM says “fraud detected” when SQL only found transactions over a threshold	Require summaries to cite the rule, row count, and time window used
Workflow sprawl	n8n workflow grows ad hoc branches for every executive request	Keep orchestration thin; move policy into code, database roles, and versioned catalog files
Audit blind spot	Slack message survives, generated SQL does not	Insert audit rows before execution and update them with outcome, latency, and row count
Replica lag	Agent reads from an Aurora PostgreSQL read replica during high write volume	Expose freshness metadata and reject questions requiring current transactional state

What to Do Next

• Problem: Natural-language SQL agents fail when generated queries are treated as trusted database clients.

• Solution: Put a control plane between the model and PostgreSQL: approved catalog, parser, policy gate, EXPLAIN gate, read-only execution role, result shaping, and audit logging.

• Proof: A useful validation signal is an evaluation set where ambiguous time windows, missing tenant filters, expensive joins, restricted columns, and prompt-injected table content are rejected before execution.

• Action: This week, build the smallest safe version: three approved views, one read-only role, statement_timeout = '5s', mandatory LIMIT 100, JSON EXPLAIN, and an ai_query_audit table.

A SQL agent earns production access only when the database would still be safe if the model made the worst plausible choice.