Writing  ·  21 September 2026

How to stop an AI agent writing SQL against Oracle

It’s an increasingly common question: “How do I stop my ai agent from writing sql?”.

In this article we’ll cover:

1. Why an AI agent writing SQL is a bad idea
2. How hard it can be to stop an AI agent from writing SQL
3. Why MCP DB Wizard is a ‘sane’ alternative to writing SQL if you need database access
4. What none of this fixes

Why an AI agent writing SQL is a bad idea

We’ve written about this before, but direct SQL access from an agent is a recipe for disaster. I mean, where do I even start? Let me try…

1. You are asking an agent to derive an architect-level understanding of a business from table names and column names in a thirty year old schema that also includes tables from an acquisition made twenty years ago. You will then be surprised and baffled when the agent does odd things.

2. Data normalisation has always been a bone of contention in database circles. Everyone agrees first normal form violations are bad, as are second normal form violations. Third normal form (‘3NF’) is what we would aspire to, maybe in an ideal world Boyce-Codd Normal Form. Or if, god forbid, your system was designed by an Architecture Astronaut and is overnormalised. And if you, the reader, are baffled by these sentences, imagine how an agent will be when it just sees table names and column names.

3. The author has never seen a real-world, production database that had been running at scale and for a long period of time where the data in tables was a perfectly accurate representation of the enterprise. In addition to a database, you usually have several rooms full of people whose entire job is to translate what the raw data says into something you can file a corporate tax return with. The ‘Agent writes SQL’ gambit assumes that it magically absorbs their knowledge.

4. This is before we even get into the agent misbehaving…

How hard is it to stop an AI agent from writing SQL?

The reason so many agents get SQL access is that it’s really easy to do. SQL is, at heart, a simple protocol. While ‘grown ups’ use bind variables, even the simplest AI agent can hack together a crappy SQL statement simply by looking at the data dictionary. Aside from the built in security risks, it leads to really terrible database performance if done at scale, as parsing a SQL statement can cost an two order of magnitude (100x) or more than executing one already in the cache, which is why DBAs hate dynamic SQL.

So, ‘OK’ you say. ‘Let’s not allow direct SQL access!’. Here’s where it starts to get weird. An agent doesn’t need a built in SQL connector to run amok. It just needs database credentials. If the end user insists that the agent access a database and either provides database credentials, provides enough information they can be guessed, or even is running on the same host where they are stored in a text file, the agent will find, download or possibly write a library to allow it to access the database.

The bottom line is that you can’t stop an agent from writing SQL. What you can do is prevent it from gaining unrestricted access to a live database. That’s where MCP DB Wizard comes in.

Why MCP DB Wizard is a ‘sane’ alternative to writing SQL if you need database access

The agent never gets database credentials, because the server holds them. That is a key part of it. What the agent is given is a URL and a token; the Oracle username and password live in the generated server’s environment, on a host the agent is not on. The scenario above — an agent that goes looking for a connection string in a config file and writes itself a connector — has nothing to find. It can compose all the SQL it likes in its own context, and none of it arrives at Oracle by this route, because nothing on the way accepts SQL text.

What crosses instead are bind values for the PL/SQL routines and the statements you wrote and tested. This also answers the DBA’s objection from the last section rather than dodging it: fixed statements with real bind variables share cursors, so the parse cost that makes dynamic SQL expensive at scale does not multiply. The set of distinct SQL_IDs arriving from that account is bounded by the config and stops growing once each tool has been called — which, incidentally, is how you check this from the database’s own side rather than taking our word for it.

And if the token does leak, it is the small thing that leaked. Tokens are per account, scoped by the access matrix to the configs that account may drive, and revocable in the console. Behind them the Oracle account should hold CREATE SESSION and one grant per object it is meant to reach — narrow by construction, so the blast radius is the config rather than the schema.

What none of this fixes

It does not stop the agent writing SQL. Nothing does, as above — it stops that SQL reaching your database, which is a different claim and the only one worth making. It also assumes the server is genuinely the agent’s only route to Oracle. Hand the same agent a connection string for a convenience, leave a tnsnames.ora and a password on a host it can read, and you are back where the last section started. This is a control over what the agent can reach, not over what it can think of.

It does not stop a tool being used badly. The right tool at the wrong moment, the wrong tool chosen confidently, three correct calls chained into a conclusion nobody would endorse — a fixed set of statements does nothing about any of that, and the narrowness of the claim is its own subject. What follows here is that the audit trail and the descriptions on your tools stop being optional extras once there is no SQL prompt. They are what is left doing the work.

And it does not make a wrong statement right. Everything exposed this way is something somebody on your side wrote and chose. A statement that is subtly wrong becomes reliably wrong rather than occasionally wrong, which is an improvement in consistency and not in correctness. Test them against realistic volumes before they go anywhere near a config.

None of which is an argument for keeping the SQL prompt — it is the same trade seen from the other end, and it is worth seeing laid out row by row before you decide, because three of those rows go the other way.

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.