AI Agents Should Not Be Allowed to Run Just Any SQL Query

AI agents should not be allowed to run just any SQL query against production databases. That sentence sounds obvious until teams start wiring assistants into real systems and assume "read-only" means "safe."

Read-only protects data from mutation. It does not protect a production database from expensive reads. A bad query can still scan huge tables, explode joins, create temporary tables, trigger filesorts, export too much data, and compete with customer-facing workloads.

Read-only is not a guardrail

Most agent failures around databases are not malicious. The model is trying to answer a question. It sees a plausible table name, writes a plausible query, and assumes the database can handle it.

But production databases are not neutral documents. Some tables are tiny configuration tables. Others are billion-row operational ledgers. Some columns are indexed. Others are not. Some joins are cheap. Others multiply the work by orders of magnitude. An agent that does not know the difference is not grounded.

Kognita's production query analyzer pattern

In Kognita client deployments, we have helped put a query analyzer in front of production database access. The point is not only to forbid writes. The point is to inspect the query before it runs and decide whether it is a responsible way to read the system.

The analyzer allows safe query classes such as SELECT, WITH, EXPLAIN, DESCRIBE, and SHOW. For high-volume tables, it runs EXPLAIN FORMAT=JSON, parses the execution plan, computes risk, and blocks queries that would put too much pressure on production.

Agent SQL request
  -> allow only SELECT / WITH / EXPLAIN / DESCRIBE / SHOW
  -> detect high-volume production tables
  -> run EXPLAIN FORMAT=JSON
  -> parse the execution plan
  -> score cost, rows examined, joins, temp tables, filesort, and index use
  -> allow, warn, or block
  -> return schema and index hints so the agent can rewrite the query

The analyzer looks at the signals a senior engineer or DBA would inspect: estimated query cost, rows examined, access type, selected indexes, nested-loop amplification, temporary tables, filesort, and wasteful filters where MySQL scans many rows only to discard almost all of them.

Request:
SELECT * FROM PAYMENT_REQUEST WHERE AMOUNT > 100

Analyzer response:
BLOCK
- high-volume table
- weak filtering
- likely full scan
- use indexed tenant/date predicates
- select only needed columns

The denial is not only protection. It is grounding.

Blocking the query saves the database from heavy work. That matters. But there is a deeper opportunity: the denial tells the agent something true about the system.

It says: this table is high-volume. This predicate is weak. This access path is dangerous. This query shape does not match how production should be read. Use tenant filters. Use date ranges. Use indexed columns. Select only the fields you need. Start from the table that gives the optimizer leverage.

A blocked query should not be treated as a dead end. It should become retrieved context for the next attempt. The guardrail becomes a teacher.

This reduces hallucination

Query analysis reduces false positive hallucinations because the agent cannot continue pretending that a guessed query is valid. If it invents a column, ignores indexes, or assumes a huge table is small, the database plan pushes back with evidence.

It also reduces false negative hallucinations because the analyzer can reveal what the agent missed: the real cost driver, a better index, a join path, a table size, or a filter that should have been applied first.

That is the larger pattern for agent systems. Do not give models unlimited tools and hope they self-regulate. Put structured truth in the path of action.

Chunk the database by tables

A query analyzer is strongest when the agent already has a grounded map of the database. That starts with table-level chunks. A useful table chunk is not just DDL. It carries business meaning, row scale, indexes, common filters, common joins, ownership, PII risk, and examples of safe query patterns.

Table chunk: PAYMENT_REQUEST
- business meaning: incoming payment event from integration layer
- row scale: high-volume operational table
- common filters: TENANT_ID, CREATE_DATE, payer/account identifiers
- risky patterns: SELECT *, leading wildcard LIKE, unbounded date ranges
- joins: PAYMENT_TRANSACTION via PAYMENT_REQUEST_ID
- safe query hint: filter by tenant and date range first

Once the database is chunked this way, the agent can retrieve table context before writing SQL. It knows which tables are dangerous, which predicates are expected, and which joins encode the business workflow.

Then build the table graph

Tables are not isolated reference pages. They are a graph of operational meaning. Customers connect to contracts. Contracts connect to products. Payments connect to requests and transactions. Tokens connect back to device access. Reports sit downstream from operational records.

A graph database of tables gives agents a navigable structure before they query. Instead of discovering the schema by trial and error against production, the agent can ask the graph: where does this concept live, what does it join to, which path is canonical, and what tables should be avoided unless the query is tightly scoped?

The practical rule

Production database access for agents should include:

• Strict allowlisting of query classes.
• High-volume table detection.
• EXPLAIN-based analysis before execution.
• Blocking for unsafe cost, row scan, join, sort, or index patterns.
• Schema and index hints returned to the agent when a query is denied.
• Table-level chunks with row scale, business meaning, and safe query examples.
• A graph of table relationships and canonical join paths.

This is what serious AI database access looks like. Not "the agent can query production." The real bar is: the agent can query production through a system that knows enough to say no.

Kognita's view

Kognita is built around this belief: agents become useful when they are grounded in the real structure of the systems they touch. Code, schemas, tickets, docs, logs, and operational rules all have to become queryable context, not loose text.

For databases, that means guarded tools, table chunks, schema graphs, and analyzers that turn unsafe attempts into better context. The goal is not just to protect production from the agent. It is to make the agent smarter by forcing it to learn from production's actual shape.