QueryShield › Guides

How do I block DELETE and DROP from LLM-generated SQL?

The obvious answer — give the AI agent a read-only database user — is a good first layer, but it is not sufficient on its own. Read-only roles can be misconfigured, they do not stop expensive or data-exfiltrating SELECTs, and they push the security boundary onto every database you connect. To reliably protect a database from AI agents, block destructive statements before they ever reach the wire.

Validate at the AST level, not with string matching

Blocklisting the words DROP or DELETE in the raw SQL text is trivially bypassed with comments, casing, or encoding. Instead, parse the query into an abstract syntax tree and inspect the statement type. QueryShield allows a query only when:

• the statement is a single SELECT (no INSERT, UPDATE, DELETE, DROP, ALTER, or TRUNCATE);
• there are no stacked statements (no ; chaining a second command);
• no forbidden functions or system tables are referenced;
• a LIMIT is present, capping how much data any single call can return.

Defense in depth

Pair AST validation with a read-only replica and per-agent row-level security so that even a novel bypass is contained. Every accepted and rejected query is written to an append-only audit log, so you can prove what an agent did and did not run.

Related guides

• How do I prevent SQL injection from LLM-generated queries?
• How do I enforce RBAC for AI agents accessing a database?
• How do I stop an AI agent from seeing database credentials?
• How do I give an AI agent safe access to a production database?
• What is a query firewall for AI agents?