1 in 3: AI database queries that run without an error and still answer wrong
A peer-reviewed test of 12 AI models: the top model's queries ran almost every time, yet about 1 in 3 still returned the wrong answer. Permissions stop damage. They don't catch a wrong answer.
About 1 in 3 database queries from the top AI model ran without an error and still returned the wrong answer. That’s from a peer-reviewed test of 12 models.
Why it matters
AI assistants can now let people ask a company database a question in plain English. The AI writes the query, runs it, and reports what came back.
The database maker’s own safety guidance is sound. The AI may read freely, and any change needs a person’s approval. Think of a new hire with a read-only badge: they can’t shred the archive.
They can still pull the wrong folder. A query can run cleanly and fetch the wrong records, and no error message warns the person who asked before they act on it.
So the two risks need separate checks. Permissions stop damage. Wrong answers need a different test, the way you’d check a new hire’s first reports against figures you already know.
An AI query needs two proofs before I’d trust it: that it was allowed to run, and that it got the answer right.
How it works
CypherBench, a benchmark published at ACL 2025, gave 12 LLMs a graph schema and no worked examples, then asked them to write Cypher, Neo4j’s query language, for 2488 test questions.
The top model, claude3.5-sonnet, wrote queries that ran 96.34% of the time. Only 61.58% returned the reference result. The models already had the schema, which Neo4j’s guidance supplies to prevent hallucinations.
The 1 in 3 is my subtraction from the paper’s table: 96.34 minus 61.58. GPT-4o’s gap is 34.76 points.
Limits: 2024-era models, public encyclopedia data rather than a company’s schema, and a strict metric that counts a result as right only if it returns the same records as the reference.
Neo4j’s MCP server, the bridge that connects AI assistants to Neo4j, classifies queries with EXPLAIN, which never runs the statement, and disables writes in read-only mode.
Parameters guard against Cypher injection when values go into pre-written queries. Each check governs what a query may do. None checks what it returns.
My supply-chain copilot shows the same gap. The LLM only supplies values for 3 pre-written templates, so it can’t write its own query. But when it extracts no name from the question, the agent starts from a default supplier so a graph still comes back. That answer runs cleanly, and it can be about the wrong supplier.
When an AI writes database queries for your team, what’s your known-answer check: a fixed test set, or spot checks on live answers?