Read the third entry in our new series: Making AI Agents Work in High Stakes Environments
Written by
Share this post
Subscribe for best practices on optimizing your software business.
Listen to this article
Read the third entry in our new series: Making AI Agents Work in High Stakes Environments
TL;DR: In high-stakes analytics, giving an LLM direct access to raw tables is a trust and security risk. Reliable agentic analytics needs semantic context, staged validation, strict access controls, and ongoing maintenance.
The fatal trap of agentic analytics: giving an LLM the keys to the raw database
“Agentic Analytics” promises a new way to interact with data: ask in plain English, get validated answers. But the fastest way to turn that promise into a liability is to give an LLM direct access to your raw database tables and hope it magically figures out your business logic.
In low-stakes settings, “close enough” may be tolerable. In high-stakes environments like finance, payments, or regulated enterprise workflows, it is a massive liability. Trustworthy agentic analytics requires a governed semantic layer, multi-step validation, strict authorization, and continuous maintenance.
Most failure modes in agentic analytics fall into one of two categories:
- Silent inaccuracy: The system gives the wrong answer that looks right
- Unauthorized access: The system gives the right answer to the wrong person
A trustworthy agentic analytics setup has to solve both.
Silent inaccuracy: wrong answers that look right
The first trap is deceptively simple: wrong answers often look polished enough to pass.
DataBrain’s vendor-reported evaluation of 50,000+ production natural-language-to-SQL queries found accuracy around 55% without semantic context. This means almost half of all answers are wrong. The same write-up says most production failures are not syntax errors, but schema, join, and business logic mistakes.
You can see this in a few common patterns:
🔴 Missing implicit business filters: Ask for “active customers by region,” and the result may include deleted accounts, trials, paused contracts, or churned users because the agent does not magically know your internal definition of “active.”
🔴 Wrong aggregation logic: Ask for “average order value by customer,” and the result may average product prices instead of order totals. The SQL runs. The answer is still wrong.
🔴 Wrong table or join path: Ask for “daily revenue,” and the result may choose the table that sounds intuitive rather than the one finance actually treats as the source of truth.
This is why high-stakes analytics must be treated as a modeling and governance problem.
Unauthorized access: the system gives the right answer to the wrong person
Correctness is only half the story.
The moment analytics becomes conversational, it also becomes an access-control problem. The interface may feel friendly, but the underlying risks are still enterprise security risks.
Open-source standards like the Model Context Protocol (MCP) strongly recommend strict authorization for AI data access, and for good reason. Consider the breach of McKinsey’s internal AI platform, Lilli, on February 28, 2026.
An autonomous AI agent exploited unauthenticated endpoints to gain read/write access to a database serving over 40,000 consultants. But this wasn't just data theft. Because the attack relied on SQL injection, it highlights a terrifying reality for analytics teams. Agentic analytics tools are literally designed to generate and execute SQL. If you allow an LLM to blindly write queries against raw tables without a governed intermediary layer, you aren't just risking hallucinated metrics — you are opening a massive SQL injection vector into your enterprise.
In other words, trustworthy analytics must answer more than “Is this query valid?” It must also answer:
- Is the question well defined?
- Is the answer correct under sanctioned business logic?
- Is this user allowed to see it?
What good looks like
To prevent both wrong answers and data breaches, you can adopt a governed reference architecture. The gold standard pattern is a multi-agent workflow supported by a semantic layer, rigid identity and access control, and continuous evals and maintenance.
1. Start with a semantic layer, the missing business context
The semantic layer is the translation engine that connects messy physical data to the language of your business.
It defines which metrics are sanctioned, which tables are authoritative, and which synonyms map to the same concept. DataBrain reported that query accuracy jumps from ~55% to 90%+ with semantic context, confirming that the gap isn't an LLM capability problem, it's a missing context problem.
Key principles:
- Sanctioned metrics should be defined once
- Authoritative join paths should be explicit
- Synonyms and business terminology should be encoded
- Verified, human-approved queries should be reusable
- Visibility rules should be part of the model, not bolted on later
If a CFO asks, “show net revenue retention by segment,” the system should not improvise what counts as contraction, expansion, churn, reactivation, or the valid reporting grain. It should access the semantic layer to find those definitions.
2. Treat Validation as a Multi-Agent Workflow
Snowflake’s engineering write-up describes a workflow that classifies the question, extracts features, enriches context with verified queries and relevant literals, and then uses multiple SQL-generation agents before selecting a final answer. That architecture is worth paying attention to because it reflects the right design instinct: generation should be staged, checked, and compared before execution.
- Intent classification: First, determine whether the question is clear enough and safe enough to answer. If the user asks, “Show me revenue,” the system should clarify, e.g., "which revenue? gross? net?" instead of guessing.
- Feature extraction: Decomposes the natural-language question into the atomic building blocks of an SQL statement: requested metrics, the dimensions to group by, the implied filters and time ranges, and any comparisons or aggregations.
- Context ernrichment: Injects your semantic model-definitions, KPI logic, synonyms and relationships, and dimensional hierarchies-into the prompt so the AI has the full picture.
- Multi-query generation: Routes the enriched context to multiple SQL-generating agents using different foundation models, reducing single-point-of-failure risks.
- Error correction: Runs the generated SQL through a compiler and schema validator to catch hallucinated column names or impossible joins, like a code review before execution.
- Query synthesis: Compares outputs and delivers the final, verified query. If agents disagree, the system flags uncertainty rather than picking arbitrarily.
3. Preserve identity, authorization, and auditability all the way through
Authorization cannot stop at the chat interface. At the conversational entry point, the MCP server (the standardized open-source bridge connecting enterprise data tools to conversational agents) must authenticate the calling application, correctly propagate user roles, and restrict data access.
At the database level, mechanisms such as row-level security must ensure that even if a generated query is valid, it returns only the subset of data the user is entitled to view.
Make the answer auditable. A trustworthy answer should not be a black box. Users should be able to inspect the:
- confidence level
- SQL or logical query used
- metric definition applied
- filters and time assumptions
- freshness of the data
- scope of access that shaped the result
Trust is much easier to build when users can see how the answer was produced.
The full reference architecture inspired by Snowflake's Cortex Analyst implementation:
The part most teams underestimate: continuous evals and maintenance
Architecture alone does not preserve accuracy. Foundation models update. Business logic drifts. Warehouse schemas evolve. The semantic layer that was correct in January may be subtly wrong by April - and "subtly wrong" is worse than "obviously broken," because nobody catches it until the damage is done. A 5-point drop in accuracy on renewal forecasting can mean millions in misallocated retention spend.
Reliable agentic analytics requires three ongoing disciplines:
- AI evals: Build a regression suite of representative questions paired with golden (or reviewer-approved) SQL. Re-run it whenever you update the model, change the schema, or modify the semantic layer. Treat regressions as release gates, not informational dashboards.
- Feedback loops: Thumbs-down signals, analyst corrections, and support tickets on bad answers are not noise - they are your most valuable training data. Route them into a structured process that updates the definitions, the verified-query library, the prompt context, and the AI evals. Without this loop, the system quietly decays.
- Context engineering: What you inject into prompts, how you phrase guardrails, which examples you include — it's continuous maintenance, not a launch checkbox. Budget ongoing engineering capacity for this layer alongside your product features. It is the difference between a demo and a product.
Practical implementation playbook
You do not need to boil the ocean. You need a practical roadmap.
- Week 0 (i.e., build or buy): Audit your data partners. Do they already provide a trustworthy agentic analytics layer with BYOA (Bring Your Own Agent) support? If yes, you can start connecting in Week 1. If not, you face a build decision: commercial tools like Snowflake's Cortex Analyst or open-source solutions like Inconvo can accelerate the path, but expect a multi-month effort before you reach production readiness. Make this decision explicitly before proceeding.
- Weeks 1-2: Identify 1-2 high-value, data-driven analytics tasks (e.g., "Weekly Business Review" or "Customer Cohort Churn Analysis") and build a lightweight proof of concept.
- Week 3: Connect an approved agent — ChatGPT, Claude, or a domain-specific tool — via MCP to the agentic analytics layer.
- Week 4: Test how well the agent answers the high-value tasks. Work with your data partner to improve performance from both sides.
- Month 2+: Roll out to a pilot group. Monitor performance metrics and user feedback. Close the feedback loop with your data partners.
