How to let an AI agent run queries on your data warehouse safely

Run every query the agent writes through a gate that reads the statement before the warehouse does. Read-only queries on approved views run within cost and time caps; saving or scheduling a query is drafted for a person; anything that creates, changes or deletes data is refused. Each answer carries the query that produced it, so anyone can rerun it.

What does it mean for an agent to run its own queries, and who owns it?

Granting access decides what data the agent may see; that is covered in how to give an AI agent read access to your data warehouse. This playbook is about the next question: the agent now writes and runs SQL of its own. That brings three risks the access grant does not cover. The statement might change data. The query might be expensive or lock tables others need. And the answer might be wrong while looking authoritative.

The data platform team owns the execution path: the role the agent runs under, the compute it uses, the caps. Each analytics or finance lead owns the questions the agent answers in their area and decides which answers may be shared without review.

How do you set it up, step by step?

1. Platform team: give the agent a read-only role on approved views. The role has no rights to write, create or drop anything. This is the floor; the next steps sit on top of it.
2. Platform team: put a statement check in front of the warehouse. It parses each query and classifies it: read, write, schema change, procedure call. Only reads proceed. Evidence: a verdict per statement with its class.
3. Platform team: set cost and runtime caps. Estimate cost before execution and refuse queries above the cap; stop queries that run past a time limit. Evidence: refused or stopped queries with the estimate.
4. Platform team: give the agent its own compute. A separate pool keeps a runaway query from slowing month-end reporting.
5. Agent, depth 1: writes and runs read queries. It answers questions and shows the query with the result.
6. Agent, depth 2: drafts a saved query or report. A named analyst reviews it before others can use it. Evidence: held verdict, approver, approved version.
7. Agent, depth 3: refreshes an approved scheduled query. Only queries a person has already approved, unchanged, within the caps.
8. Platform: refuses any write. Creating tables, inserting rows or changing schemas is outside the agent's bounds. Evidence: refused verdicts naming scope.

Which controls keep queries safe, and what evidence do they leave?

Statement classification outside the model. Do not rely on the agent promising to write only reads. Parse the statement. Evidence: class and verdict on every query.

Read-only role underneath. If the parser misses a case, the role still cannot write. Two independent layers. Evidence: grants export.

Cost and time caps. Evidence: estimates and stops in the log.

Query attached to the answer. An answer without its query cannot be checked. Evidence: each answer stores the query text and a fingerprint of the result.

Approved metrics win. Where the business has an agreed definition, such as monthly active customers or net revenue, the agent should use the approved view rather than compute its own. Evidence: answers cite the metric's view.

Untrusted text stays out of the SQL. Customer messages, file contents and web text can contain instructions. The agent must not paste them into queries it runs. Evidence: queries built from parameters, with inputs logged separately.

Code execution raises similar issues; see whether an AI agent can run code safely.

What should you measure?

• Refused statements by class. Any write attempts at all deserve a look at the agent's brief.
• Cost per answered question, and the share of queries that hit the cap.
• Answer accuracy on a sample. Each week an analyst reruns a handful of answers by hand. Disagreements go back into the agent's sources or brief.
• Divergence from official reports. If the agent's figure for a metric differs from the finance pack, one of them is wrong.
• Rerun consistency. The same question on the same data should give the same answer.

Where does it usually go wrong?

The agent invents a metric. Asked for "churn", it writes its own definition and the number circulates. Point it at the approved view or make it say there is none.

Joins multiply rows. A careless join double-counts revenue. The number looks plausible. Sampling at step 5 catches this; nothing else will.

Agents chain queries. One agent's output becomes another's input with no check between them. The risks of this are covered in how multiple AI agents work together safely.

Answers go to auditors unreviewed. When an auditor asks a question, the agent can draft the answer and its query, but a person sends it. The method is set out in how to answer auditor queries with an AI agent.

Caps are raised to stop complaints. Raise them per capability with a reason, not globally.

Where Pryme fits

In Pryme, each query is an action checked against the agent's bounds when it is attempted: approved views, statement class, caps and certificate. Writes are refused, saved reports are held for a named analyst, and every query and answer is filed. More on the model is in the governed agentic operating system guide.