Writing ·
Can I let an AI agent query my production database?
This is the question everyone actually asks, usually phrased more nervously than that. And the honest answer is yes, you can, and quite a lot of people already are. The interesting part is what happens next.
The default answer is a run-sql tool, and that is the problem
Nearly every “connect your AI to a database” product works the same way: it gives the model a tool that takes a SQL string and runs it. It is the obvious design. It is also the one that makes your security team go quiet.
Here is why it is worse than it looks. You are not deciding whether the model can write a bad query. You are deciding whether there is any mechanism that would stop it. With a SQL prompt, there isn’t one — there is only the model’s judgement, and the model is non-deterministic. It will do the right thing a thousand times and then do something novel on the thousand-and-first, because nothing in the architecture prevents it.
You cannot test your way out of that. Testing a non-deterministic system tells you what it did, not what it will do.
“We’ll just use a read-only account”
This is the usual second answer, and it is genuinely a good idea — you should always limit privs. But notice what it does and does not buy you.
It stops writes. It does not stop a query that table-scans your largest table at month end. It does not stop a model reading a column it should never have seen, because “read-only” is not the same as “only these rows and columns”. And it does nothing at all about the interesting failure mode, which is not malice but confidence: a query that runs fine, returns a number, and the number is wrong because the schema did not mean what the column names suggested. The author has never once in his career seen a large, real world, mature database that you could safely point an agent at.
The alternative is boring, and boring is the point
Instead of handing over SQL, hand over a fixed set of operations. The PL/SQL your team already wrote and tested. The specific queries you know are correct. The tables you are happy to expose, with the operations you are happy to allow.
The agent gets tools. It does not get a SQL prompt, because there is no tool that takes one.
If you already have one that does, getting from there to here is its own piece of work — starting with the fact that you cannot stop an agent writing SQL at all, only stop it reaching your database.
That changes the security conversation from “we trust the model” to “here is the list”. A list is a thing your compliance people can read, sign off, and diff between releases. It is not clever, and it is much easier to defend.
What you give up
Flexibility, honestly. If someone asks a question nobody anticipated, the agent cannot improvise its way to an answer — it will tell you it has no tool for that. Some people find this maddening. It is the same trade you already made when you decided your web application would have defined endpoints rather than an admin SQL box.
The question worth asking is which of those two you would rather explain after an incident.
How do I get MCP DB Wizard?
It’s available from our GitHub repo as a Docker image, and the quickstart will get you a running server against your own schema.