Short answer: AI-generated SQL runs without approval when the same step that writes the query also executes it. To prevent that, separate the two: have the tool show the SQL and wait for an explicit Run, turn on tool-call approval in any AI app that can execute queries, and connect with a read-only database user so that whatever does run cannot change data.
Three controls that keep a human in the loop
1. Show the SQL, and run it only on an explicit click
The simplest approval step is a person reading the query before pressing Run. Prefer tools that put the generated SQL in front of you, let you edit it, and do nothing until you choose to execute it. Be careful with "auto-run" or "answer my question" modes on real data: they skip this step by design.
2. Use your AI app's tool approval
When an AI assistant such as Claude or ChatGPT can call a database tool, the assistant app decides whether to ask you first. Check its settings for connectors or tools and require confirmation for any tool that runs queries, at least until you trust the setup.
3. Connect read-only, with limits
Approval catches mistakes you notice; permissions catch the rest. Give the AI tool a database user
with SELECT-only grants, ideally on a replica, and prefer tools that also reject
non-read statements and cap rows and run time. See
how to give an AI agent read-only database access.
What AI2SQL does at each step
In the web builder
- SQL is shown before it runs. Generated SQL appears in the output panel and the Run button is enabled; on your own connected database nothing executes until you click Run.
- You can edit it first. The Edit button next to Run (on wider screens) lets you change the query; Run executes the SQL as shown.
- A read-only check on Run. When you run a query on your own database, AI2SQL refuses
statements that do not start with
SELECT,WITH,SHOW,EXPLAINorDESCRIBE, and refuses more than one statement at a time. Use a read-only database user as well; the check is a second layer, not a replacement for permissions. - One exception: the sample database. On the
demo_shopsample database, which holds sample data rather than yours, a generatedSELECTorWITHquery runs right after it is generated so you can see results immediately.
Through the MCP server (Claude, ChatGPT, Cursor)
- Read-only queries only. The
run_querytool accepts a singleSELECTorWITHstatement. Writes, DDL, multiple statements and a list of server-side functions (for example file-reading and sleep functions) are rejected before the query reaches your database. - Bounded results. Results are capped at 1,000 rows, and queries on connected databases time out after 10 seconds.
- You see what ran. The tool's response includes the exact SQL that was executed, including any row limit AI2SQL added.
- Approval happens in your AI app. Whether Claude, ChatGPT or Cursor asks you before
calling
run_querydepends on that app's settings. AI2SQL labels its tools as read-only and non-destructive with MCP tool annotations, which the MCP specification defines as hints for the client.
Setup steps for each assistant are on the AI2SQL MCP page. Connecting your own database is part of the Pro and Team plans; the Free plan includes 3 queries a day on a demo database.
A quick checklist
- Generate the SQL, then read it: tables, filters, joins and anything that looks like a write.
- Edit it if needed, and run it yourself only when it looks right.
- Connect AI tools with a read-only user, ideally against a replica.
- In AI assistants, require approval for tools that execute queries.
- For anything that changes data, copy the SQL into your usual change process instead of letting an AI tool run it.