It's a fair thing to worry about. Giving a system that generates its own SQL a line into your database sounds like exactly the kind of decision that ends up in an incident review. But the risks aren't vague — they're a short, concrete list, and each has a known control. Connecting AI to a database is safe when you address all of them, and genuinely risky when you skip any.
The four real risks
1. The agent runs a destructive statement
An autonomous agent can generate an UPDATE or DROP and, on a raw
connection, run it. Fix: enforce read-only by classifying every statement before it
executes and running it in a read-only transaction. Note that a read-only transaction alone
isn't enough — the archived official Postgres MCP server had a documented SQL-injection that bypassed
exactly that. Classify first.
2. Credentials leak from config files
The common setup pastes your database password into a config file on every developer's laptop. Fix: never give the agent the password. Store credentials encrypted server-side and let the agent authenticate with a scoped, revocable key.
3. A runaway query overwhelms the database
"Read-only" doesn't stop a SELECT that scans everything, and an agent in a loop can fire
many. Fix: cap result size and set a query timeout so one call can't drain the
database.
4. No record of what the AI did
When someone asks "what has the agent queried on production?", you need to answer. Fix: log every call with the key that made it, and keep the ability to revoke a key instantly.
So — is it safe?
Yes, if all four controls are in place; no, if you connect an agent raw. That's the entire reason the AI2SQL Gateway exists: it's a hosted MCP endpoint that enforces read-only two ways, isolates your credentials, bounds every query, and logs everything — so "connect AI to my database" stops being a gamble. Prefer a read-only replica where you can, and connect through the gateway.
For the control-by-control detail, see how to give an AI agent read-only database access.