Using an AST to validate AI-generated PostgreSQL before it runs

If an LLM is generating PostgreSQL in your application, there is one moment worth treating separately: after the model returns SQL, but before your code calls db.query().

Prompt rules are useful. They can make the model more likely to produce the sort of query you want. They do not decide which tables the application is allowed to read, whether multiple statements are acceptable, or whether a function call should run.

I have been working on sql-guard, a TypeScript package for that gap. It parses PostgreSQL into an abstract syntax tree (AST), checks the tree against an explicit policy, and rejects anything it cannot validate confidently.

Why I did not want to check SQL with regex

SQL is structured. A query may have joins, subqueries, aliases, unions, and common table expressions (CTEs). Checking raw text can catch an obvious keyword, but it cannot reliably answer what the query actually does.

For example:

SELECT * FROM public.users;

SELECT 1; DELETE FROM public.users;

WITH removed AS (
  DELETE FROM public.users
  RETURNING id
)
SELECT * FROM removed;

All three examples contain SELECT, but they are not equivalent. The second has two statements. The third uses a data-modifying CTE. A validator needs to understand the query structure rather than look for a few strings.

An AST makes that possible. It lets the validator inspect statement types, source tables, function calls, and nested expressions. It also means an alias or CTE name cannot conceal the base table being read.

The policy is the important part

sql-guard is built around allowlists. You state what a particular feature may use, and the validator checks the generated SQL against that list.

Here is a small policy for an assistant that can look at users and orders:

import { validate } from 'sql-guard';

const policy = {
  allowedTables: ['public.users', 'public.orders'],
  allowedFunctions: ['count', 'lower'],
};

const result = validate(
  'SELECT lower(u.email) FROM public.users AS u',
  policy,
);

if (!result.ok) {
  console.error(result.errorCode, result.violations);
  // Do not execute the SQL.
}

// Execute only after result.ok is true.

The default policy allows one SELECT statement and no function calls. Tables and functions have to be allowed explicitly. Multi-statement input is disabled by default.

That makes the initial policy intentionally strict. A request for public.secret_users, information_schema.tables, or pg_catalog.pg_read_file(...) is denied unless the policy names it.

A few details that matter in real queries

Unqualified names such as SELECT * FROM users can be ambiguous. By default, sql-guard expects schema-qualified names. You can choose a simple default schema for a single-schema application:

const policy = {
  defaultSchema: 'public',
  allowedTables: ['users', 'orders'],
};

Or you can provide a resolver when the application needs more control over how names map to schema-qualified tables.

Functions need the same care. An unqualified lower(...) and pg_catalog.current_database(...) are separate policy entries. This lets a feature allow exactly the form it intends to use.

The package returns structured violations and an error code rather than just true or false. An application can log a rejected query without attempting to execute it. If a rejected query should interrupt the request immediately, assertSafeSql() throws a SqlValidationError with the same details.

Where this fits in a database security model

This check is only about query shape. It does not sanitize values, execute SQL, evaluate row-level security, decide column-level permissions, or notice runtime schema changes.

The surrounding controls still matter: