Ardent has spentnearly 20years buildingandmodernisingdata platforms. As AI agents begintoquery those environments, a familiar engineering question takes on new significance: what happens when an apparently valid request creates an unexpected effect?

Permission is only one part of the answer.A workload can be valid, a job can begreenand a user can beauthorised, yet theresult maystill arrive late, consume far more resources than expected or failto support thedecision it wasintended to inform.

That lesson becomes more important when an AI agent is allowed to query a warehouse. A dashboard follows a route that someone has already designed and tested. An agent interprets a question, chooses a route through the data, writes SQL and may try several approaches before it is satisfied with the answer. The conversation may looksimplewhile the workload underneath it is changing with every turn.

At Ardent, we treat warehouse-connected agents as production workloads from the outset. Correct SQL is only the starting point. Our designhas toestablish whose authority the query carries, which data it can reach, how much compute it can consume, how retrieved content is handled and whether engineers can reconstruct the decision afterwards.

Read-only is still a production workload

Read-only access sounds safe because it rules out direct changes to production data. It does not rule out a large scan, an inefficient join, repeated retries, exposure of a restricted field or contention with reporting that the business needs now.

Our teams already manage these failure mechanics in conventional data estates. A query does not need to fail to create operational risk: it can remain technically valid while queue depth rises, latency worsens or a delivery window begins to slip. The agent adds uncertainty because the query pattern is no longer fully known in advance. A person can ask a small question and create a branching investigation across several tables and several attempts.

That is why Ardent tests read-only agents against the same delivery windows, concurrency pressures and recovery paths as any other production workload, rather than treating the absence of write access as proof of safety.

The objective is not to make every model decision perfect; no live system can promise that. It is to ensure that an imperfect decision remains small, visible, inexpensive and easy to stop. Identity is the first boundary because every later action inherits what that identity is permitted to do.

Start with the identity, not the interface

When Ardent designs an agent connection, identity is established before the interface is released. The agent needs its own non-human identity, tied to one use case and one environment, with credentials that expire and rotate and access that can be revoked without waiting for an application release. Its access must also reflect what the person asking the question is entitled to see.

The consequences of an overpowered identity are well established. In the 2024 campaign against Snowflake customer environments, Mandiant and Snowflake notified approximately 165 potentially exposedorganisations. At least 79.7%of the attacker-used accounts had previous credential exposure, while affected accounts commonly lacked multi-factor authentication and network restrictions. Valid credentials can quickly lead to operational impact when the surrounding controls are weak.

An AI agent is not the attacker in that incident, but the engineering lesson is the same: legitimate access can still create impact. Ardent gives each production agent a distinct, traceable identity with no standing administrative role. Its permission is the overlap between the agent's defined task and the requesting user's access. Before release, the team also knows which token to revoke, which connection to close and which workload to suspend.

Give the agent the part of the warehouse it actually needs

Long-lived warehouses accumulate far more than any one assistant should discover: raw ingestion tables, temporary objects, technical metadata, historical records and columns retained for uses unrelated to the question in front of it. Broad catalogue access gives a model more ways to guess, not necessarily more ways to be right.

Ardent begins with the business questions the agent is expected to answer and works backwards to a deliberately small query surface. That surface is made from approved views, agreed measures and documented relationships in the finished data layer. A commercial performance agent may need governed revenue, product, region and period measures; it does not automatically need customer identifiers or access to tables still moving through the pipeline.

In Ardent’s designs, the dataplatform remains the enforcement point. Databricks Unity Catalog can apply row filters and column masks at query time; Snowflake can apply row-access and masking policies and retain policy references in Access History.Amodel may misinterpret a prompt, but itcannot negotiate awaythoseplatformcontrols.We also limit group sizes, dimensions and result sets so several acceptable answers cannot combine to expose a sensitive pattern.

Check the query before it reaches the warehouse

Inourimplementationswith clients, generated SQL does notmove directly from the model to the platform.A definedcheckpoint validates the requested operation, referenced objects, likely scan and result size, then rejects commands or routes the agent was never intended to use.Predefinedrules decide whether the query can run; the model is never asked to approve its own work.

The same caution applies in the other direction. Warehouses increasingly contain support notes, survey responses, product descriptions and other free text. To an engineer, that content is data. To a language model, a sentence inside it may look like another instruction.

The risk is straightforward: text retrieved from the warehouse should be treated as information, not as an instruction. A note, description or support record might contain wording that pushes the agent towards an action the user never requested.Thequery mustthereforepass the samepredefinedchecks, regardless of what the retrieved text appears to tell the model.

In practice, this means keepingretrieved contentseparatefrom trustedinstructions,recordingwhere it came fromandcheckingpermission again beforean actioncould expose data or affect another system.The model can help interpret the information, but it should not be able to change the rules governing what happens next.

Protect the workloads behind the conversation

Permissions protect data; they do not protect capacity. Ardent's experience managing multi-petabyte, near-real-time and business-critical data environments has taught us to treat compute as part of the business service, not an unlimited technical pool. A fullyauthorisedquery can still be a badneighbourif it competes with overnight processing, month-end reporting or a customer-facing workflow.

Where the architecture allows it,weseparate conversational workloads from critical reporting and transformation. The agent receives a warehouse, SQL endpoint or compute policy sized for its use case, with explicit limits on execution time, concurrency, retries, scan volume and total consumption.

Snowflake, for example,provides statement timeouts and resource monitors for warehouse workloads, while serverless features and AI services require the corresponding budget controls. Matching the guardrail to the agent's actual compute path prevents a technically permitted conversation from undermining a business-critical workload.

What happens at the limit matters as much as the number itself.Auseful failure routemightnarrow the time window, use an approved aggregate, explain that the request exceeds its boundary or hand the investigation to an analyst. Quietly scaling the platform until an answer appears is not resilience; it is an uncontrolled recovery strategy.

Make the decision traceable from question to effect

Query history records the SQL that ran. It does not, on its own, explain why that SQL existed. For a warehouse-connected agent, our engineers need to connect the original question, the requesting user, the agent and policy version, the data that influenced the plan, the statements proposed or rejected, the objects touched and the result returned.

At Ardent, we look at whether an agent’s activity can be followed from the original question through to the warehouse query and the answer returned. Snowflake query tags and Access History, alongside Databricks query history, audit logs, lineage and UnityCatalog, can provide much of that technical record. The precise implementation will depend on the platform and the organisation, but the objective remains the same: engineers should be able to understand which request produced a workload, what it accessed and how it behaved.

That evidence is most valuable when it informs day-to-day operations rather than being retained only for later review. Rejected queries may point to missing aggregates, repeated timeouts may identify areas that needoptimisation, andattempts to reach masked fields may reveal that access no longer matches the use case.

Ardent helps teams decide which signals matter and what response is appropriate. Depending on the controls available, that might mean cancelling a query, restricting compute, revoking access or preserving the records for investigation. A successful query status alone does not show that the wider business outcome was protected.

Before the agent goes live

A convincing demonstration is not enough to put a warehouse-connected agent into production. Before release, the organisation needs clear ownership of what the agent can access, how much resource it can consume and when a person must intervene.

Ardent helps bring those decisions together so access can expand carefully,one use case, one data domain and one level of authority at a time.

Once an agent is generating its own queries, could your team identify the request behind an unusual workload, understand what data it reached and stop it before reporting, pipelines or customer-facing services were affected?

Speak to Ardent about introducing conversational access to your data platform with the controls, visibility and operational ownership it needs.

References and further reading

• Ardent, “How Modern Data Lakes and Data Warehouses like Databricks and Snowflake Power Conversational AI” — Read on LinkedIn

• Ardent, “Conversational Runbooks are Changing Incident Response on Snowflake & Databricks” — Read on LinkedIn

• Ardent, “Migrating to Agentic AI: A Practical Roadmap for Data Teams Already Running ETL Pipelines” — Read on LinkedIn

• Mandiant / Google Cloud, “UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion” (10 June 2024) — Read source

• Snowflake documentation, “Working with Resource Monitors” — Read source

• Snowflake documentation, “Access History” — Read source

• Databricks documentation, “Row Filters and Column Masks” — Read source