Fourth in a series on Ai and databases.

What Read-Only Advisory Actually Means

A read-only advisory system does exactly two things: it observes and it recommends. It never acts.

It can tell you a database is in a suspect state. It cannot attempt to recover it. It can tell you a backup chain is broken. It cannot re-run the job. It can identify that a transaction log is growing uncontrollably. It cannot intervene. That boundary is not a limitation. It is a deliberate design decision — and arguably the most important one when building AI for production database environments (in my opnion).

Why It Matters

Production SQL Server instances serve real applications, real users, and real business processes. A wrong action — even a well-intentioned one — can cause an outage, breach compliance, or trigger a recovery scenario nobody wanted. The only rational starting point is observation and recommendation. Let the DBA decide. Let the DBA act. The agent’s job is to make that decision faster and better informed — not to make it for them.

Trust Has to Be Structural

A trustworthy diagnostic agent is built so that the boundary between observation and action is not a setting, a configuration flag, or a prompt instruction. It is structural.

The agent should be architecturally incapable of writing to user data, running DDL, killing sessions, or executing any SQL it generated itself. Not because it has been told not to. Because the capability simply does not exist in the design. That means read-only diagnostic queries only. Pre-approved, version-controlled, human-reviewed. No runtime SQL generation reaching a cursor. The agent reasons over what it observes and hands a recommendation to a human. The human decides what happens next.

That is the only posture that earns enterprise trust — and it should be non-negotiable for any AI system pointed at a production database.

Third part in my Ai series with databases.

When building AI solutions within the database realm the first thing that people do is a straightforward concept, connect the LLM endpoint to a SQL backend let it run queries and become a LLM wrapper.  It works for demos, fails in the real world.

Why is this pattern bad? Couple of reasons – It generates adhoc SQL, the model decides what it wants to code and how to query and parse the data back.  It’s a context window killer. Do you know how heavy the RAW result sets on a msdb query are when you have hundreds of jobs? I have seen token budgets get eaten up very fast. Probably the worst thing without any form of control is the hallucination connection. The model, whether Claude or GPT will absolutely make a casual link between a failed job to a breached backup RPO even when there is no link – I have even asked it why it did that it replied, apologies I just linked the two.  Most importantly, it’s a security issue. Imagine you  are sending back and forth sensitive metadata about key objects within your database system its massive area of concern.

Defence Layers

Architecturally I design to four layers to address these problems to provide a secure confident experience, these are – Entry layer, Context layer, Tool layer and the validation layer.

Each layer is a guardrail that doesn’t depending on the mood of the LLM. The model can’t run dangerous code because it never writes TSQL. It cannot flood the context window because of tool contracts, and it cannot link 2 things together just because it feels like it due to validation layer.

Key design principle?  Guardrails must be structural – NOT behavioural.

The trade off is complexity, this isn’t a something you can design and build in couple of days but how do you build trust if you don’t? The effort is absolutely needed.