- Venkat Navneeth Burla argues that an AI database tool can give an accurate answer to the wrong person, and that accuracy tests miss this.
- In his synthetic benchmark of 900 queries, plain text-to-SQL returned up to about 80 unauthorized rows. A policy-aware design leaked none.
- Ask your team where access rules live, what database account the AI uses, and whether they can show who saw what.
A correct answer for the wrong person
Most teams test an AI that writes database queries by asking one thing: did it get the answer right? Venkat Navneeth Burla, a senior data scientist, argues in InfoWorld that this test misses the failure that matters. An answer can be accurate and still belong to someone else.
Consider a sales rep who asks for figures on "my hospitals" and receives data on every hospital in the region. The query is well formed and the numbers are right. The rep still sees records meant for colleagues. Burla says multi-tenant apps, HR systems and finance tools can fail in the same way.
Burla built an LLM analytics tool on Snowflake Cortex, using healthcare engagement and field-performance data. People could ask it questions in plain English. He says recurring analytics turnaround fell from days to minutes. The question of who gets to ask what came up while he was building it.
The idea: access is a property of the system, not the model
A language model turns English into SQL, the language databases use to fetch records. On its own, it does not know who is asking or what that person may see.
This shows a shift in where control sits. A person who once needed an analyst to pull a report now needs only a chat box. Whatever judgement an analyst once applied informally now has to be written into the system. It cannot live inside the model.
How the governed design works
Burla describes three steps. The first limits what the model can see. Before any query is written, the system identifies the user and their role, business unit, territory and accounts. The model then receives a schema trimmed to what that user may touch. Columns that hold identifiers, pricing terms or pay get a sensitivity label in the data catalog, and labelled columns are simply left out of the model's view.
The second step is to stop trusting the prompt. Burla says that adding "only show my territory" to the instructions is not enough, because "a prompt is a suggestion." The model can ignore or misread it. In his design, code inspects the SQL the model produced and edits it before it reaches the database. The rules live where the model cannot argue with them.
The third step is to check every query. The checks refuse SELECT *, which asks for every column. They also refuse queries that reach outside the user's scope, return very large result sets or use risky joins. Approved queries then travel through a gateway, and the gateway signs in to the database with an account that has few permissions. Burla says that way a prompt injection, where hidden text tricks the model into a bad request, cannot walk around the rules.
What the benchmark found
The figures come from 900 test queries. Burla says the data is synthetic and de-identified, with no real patient, provider or commercial records. The work is based on a paper accepted at IEEE ICICNIS 2026.
In that set, 40% of queries could run unchanged. Another 20% needed a row filter and 15% needed column masking. A join rewrite was needed for 11.7%. Roughly one in fifteen, 6.7%, went to a human reviewer. A further 6.7% were stopped outright.
The most common fix was a row filter added to the WHERE clause, 285 times. Column masking came next at 240, then scope restriction at 165. Burla's point is that most people still got a useful answer, just a safer one.
The leak figures differ sharply by design. Burla reports that unguarded text-to-SQL exposed as many as about 80 rows a user should not have seen on some queries. Fixed role-based access control also let data through, which he attributes to its blindness to the context of each request. The policy-aware approach leaked none. Burla says it added about 6.5 milliseconds per query.
Treat these as one author's results on synthetic pharma data. They are a design signal, not a measurement of your own systems.
Questions to put to your team
Ask where access rules live today. If the answer is "in the prompt," the rule is a request, not a control.
Ask what the model can see. Does it get the whole schema, or only the tables and columns the asking user may use?
Ask which database account runs the generated SQL. An account with few permissions limits the damage when a generation goes wrong.
Ask whether you could answer "who saw what and why" in minutes. An audit trail would hold five things: the question asked, who the user was, which rule applied, the final SQL and what came back, as Burla recommends.
Ask who reviews the queries that get held back, and how long they wait. In this benchmark, that was about 6.7% of queries.
Burla puts identity first and model quality second. Settle who the user is, then tune how well the model writes SQL. A fast answer only earns trust once the system knows who is asking.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: InfoWorld.
