Agents are most convincing when questions are tidy and the data is predictable; however, enterprise environments are rarely so accommodating. Real data estates span systems and business rules that aren't obvious from the question alone. The difficulty isn't generating a query; it's deciding whether that query follows a route the organisation trusts.

The moment thatchanges the nature of the servicecomes after the model writes SQL but beforethe queryreaches the warehouse. Inour workwith clients, this is where a demonstration becomesoperational:theorganisationmust decide whether the query fits the user, the purpose and the moment.If that decision is missed, the query may still run,while crossing a boundary nobody intended.

That decision needs its own control point. A checkpoint weighs the query, who is asking and the rules that apply. It can allow the work, refuse it, narrow the request or send it for review. The model proposes; the checkpoint decides. In our experience, the hardest requests are not obviously dangerous. They cross a business boundary, misuse trusted data or ask for more than the answer justifies. That is why the decision cannot sit with the model alone.

This article sets out how to design that checkpoint: what it decides, in what order and how to test it.

Why a data checkpoint matters now

Before covering that design, it's worth being precise about why this control matters more than most. What changes in practice is the route from question to execution. A dashboard exposes measures and filters that have already been designed; an agent can propose a different route through the data every time it is asked a question. In delivery, that flexibility is often where early excitement meets the realities of ownership, business definitions and shared platform capacity.

This creates a gap between permission and judgement. A person may be entitled to see several data sets without every combination being meaningful or proportionate, and better prompt wording does not close that gap.

Ardent builds checkpoints to close exactly that gap for clients, and the aim isn't to slow adoption down. It's what lets an organisation move past demonstrations without handing an unpredictable agent unrestricted access to business-critical systems,which matters more as agents serve more users and domains.

For leaders, the practical question is not whether an agent can produce SQL. It is whether the team knows why arequest should be allowed, who owns that decision and what happens when circumstances change.That's what turns those decisions into something the organisation can review and improve, instead of leaving them inside the model's response.

Building the checkpoint: a five-step guide

When researching this topic and discussing it with our engineers, one theme came through clearly: clients are increasingly asking how to put this kind of control into practice.The following five stepsreflect how we advise teams to think through thedesign, beginning with the business decision and working outwards.

Step 1: Define the boundary before the technology

The first thing to consider is whatboundaryyourorganisationwouldrecognise: whichquestions the agent should answer,whoit will serve andwhichdecisions it may support. Without thatshared definition, the controls have no reliable standardagainst which to judgea request.

For each use case, we work with business and data owners to agree what is in scope, which data and measures are trusted, how much detail an answer may contain and when a person must decide. Those choices become the policy the checkpoint enforces. If the owners cannot explain the boundary, encoding it will not make it reliable.

Consider revenue by product. A query may run successfully while counting the same revenue more than once. Ardent helps avoid this by creating an approved data layer where revenue, product and period have governed meanings and trusted relationships.

We normally keep the first release narrow: one use case, one user group and one governed part of the data estate. This reveals where the boundary works, where it blocks legitimate questions and which assumptions still need human judgement before the scope expands.

Step 2: Keep the decision outside the model

The next questionis where the final decisionshouldsit. We would avoid asking the model tojudge whether its own work is safe. Another model may help interpret a request, butconsistent rulesoutside the model are better placed tohold when prompts, wording or models change. The agentcan then be givenonly the authority its task requires.

We wouldthereforehave the agentsubmit proposed work to a separate checkpoint. That servicecan establishwhat the request would do,considerwho is asking and why, andcompareit with the agreed boundary. It adds a decision before the platform’s existing permissions are used; it does not replace them.

In Ardent’s approach, the relevant context becomes a concise, versioned decision record rather than being inferred from the user’s wording. This makes decisions explainable and separates changes to the agent from changes to the rules.

Responsibility also remains clear: the model interprets the question and proposes an action; the checkpoint evaluates it against policy; and the data platform enforces the underlying permissions. If one layer fails, the others still have a defined role.

Step 3: Check the request before it runs

Next, consider which checks yourorganisationneeds before a query runs.Each checkshould recorda reason the application can act on andhelp establishwhether the queryis appropriate forthis user, purpose and moment.

• Understand the request. Establish what the query would do, which data it would use and whether it strays outside the boundary. Understanding intent is more reliable than searching for blocked words.

• Confirm the approved data. Keep the request within curated views and governed measures rather than broad catalogue access. The platform must still enforce access rules and protect sensitive fields.

• Validate how the answer is calculated. Approved data can still be combined in a misleading way. Compare the proposed calculation with documented relationships and verified examples, and refuse to invent a route the organisation has not agreed.

• Estimate the workload. Assess how much data the request may process. The estimate only needs to identify unusually large work, missing limits or requests requiring review.

• Control the result. A small answer can still require extensive work. Consider both the effort involved and whether the result’s size and sensitivity suit the interaction.

In practice, we recommend stoppingclearly unacceptable requests earlywhile still checking permitted work for workload and output risk.This createsa sequence of decisions the team can explain and review, rather thanrelying onone clever rule.

Step 4: Design outcomes that move the user forward

Attention then turns towhat should happen after thecheckpointreaches a decision. In our experience,a simple allow-or-refuseresponse is rarely enough. Depending on theorganisationand use case, the checkpoint mightapprove, narrow, refer for review or refuse with a clear explanation. The applicationcan thenturn that outcome into a safe next step rather thaninvitingrepeated attempts.

A refusal only helps if the user knows what to do next. The checkpoint might shorten an overly broad timeframe, point to an approved summary or involve an analyst where no trusted answer exists. We design those routes alongside approvalrulesso a technically correct refusal does not leave the user stranded.

Every outcome should provide a concise reason without exposing sensitive policy.Done well, thissupports the user and reveals recurring demand: repeated requests for the same rejected question may show that a new governed route is needed.

Refusal behaviour also shapes trust. A vague error feels arbitrary; an explanation tied to the boundary helps the user reformulate a legitimate need without encouraging repeated retries.

Step 5: Test the boundary before launch

Before launch, we advise testingthe boundaryrather thanmerelyconfirmingthat straightforward requests work.That means includingquestions that should clearly pass or fail,alongsideawkward cases that expose gaps.Known-good requestscan then be variedby widening the timeframe, adding unapproved data or asking for greater detail.

During a shadow period, we compare checkpoint decisions with engineers’ and analysts’ judgements before affecting live execution. Disagreements are especially useful: a false rejection can expose a missing approved route, an unsafe approval can reveal an overly broad rule, and inconsistent human decisions can show that the business boundary remains unclear.

Wherethe checkpoint lacks enough information,we advise failing safely.Readiness is not a high approval rate; it is the team’s ability to explain decisions, correct weak rules and keep uncertain requests away from business-critical data.

Wealsorecommend testingthe experience around the decision. Reviewerscancheck whether reasons are understandable, narrowed requests preserve intent and review routes reach the right owner. A logically correct checkpoint can still fail if it leaves people stranded.

Running the checkpoint in practice

Once thecheckpoint islive, consider who will own itsdecisions, howoutcomeswill be monitoredandhowpolicywill evolveas the data environment changes.We recommend giving theteamvisibility intowhy requests are allowed or refused, where users repeatedly retry and where expected workload differs from whatactually happens.

We recommend rerunning the relevant policy tests wheneverdata, measures, permissions or platformbehaviourchange. This keeps the checkpoint aligned with the environment it governs rather than treating launch as the end of the design process.

As coverage grows, the governance model also needs toremain proportionate.A policy that works for one finance question will not automatically suit operational, customer or people data.Before addinga new use case, we would ask whetherits measures, owners, risk tolerances and review path are understood,andthen test it against the same decision discipline.

Control is what makes scale possible

What we have learnedfrom putting conversational access in front of enterprise data is that model capability and operational permission are different things. A query can look convincing and still be wrong for the user, the purpose or the moment. A data checkpoint makes that judgement visible, allowing access to expand without treating every plausible request as safe.

If your AI agent proposed a convincing but misleading, unnecessarily detailed or unexpectedly costly query tomorrow, could your team explain why it was allowedand stop it before it reached a critical workload?

Ardent helps data teams define the first permitted use case, agree the boundary with its owners and test the checkpoint against real requests before it controls live execution.

If you are moving an agent beyond demonstration, we can help identify the decisions that need to sit between its proposal and your warehouse.

Sources and related Ardent reading

• Lei et al., "Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows" (ICLR 2025) - Read source

• OWASP GenAI Security Project, "LLM06:2025 Excessive Agency" - Read source

• Ardent, "An AI Agent That Can Query Your Warehouse Can Also Break It. Here's What Stops That" (2026).

• Ardent, "Conversational Runbooks are Changing Incident Response on Snowflake & Databricks" (2026).

• Ardent, "Migrating to Agentic AI: A Practical Roadmap for Data Teams Already Running ETL Pipelines" (2026).