AI agents are moving access control out of the dashboard and into the data

What happened

In a piece published on 2 September, Snowflake set out a problem many data teams are about to meet in production: the access controls most organisations rely on were designed for dashboards, not for AI agents.

The argument runs in three parts. First, agents can query multiple datasets and take actions across systems, so permissions applied in a BI tool no longer define what can be seen; enforcement has to move into the data layer, with fine-grained entitlements and row- and column-level security. Second, testing an agent before deployment is not enough, because the things around it change — an API update or a permission drift can alter its behaviour — so monitoring must continue in production. Third, organisations are accumulating “AI orphans”: unmanaged agents without clear ownership, adding to identity sprawl.

It fits a wider pattern. InfoQ’s 2026 Cloud and DevOps trends report, published in August, places enterprise AI gateways and agent governance among the practices only innovators and early adopters have in place.

Why it matters

We see the same failure in almost every agent pilot we are asked to rescue, and it is almost never about the model.

The agent inherits a human’s access. The fastest way to get a pilot working is to give the agent a service account with broad read access, or to run it under the builder’s own credentials. It works in the demo. In production, it means an assistant answering a sales question can read HR tables, because nothing in the data layer says it cannot.

Definitions live in the wrong place. Revenue, active customer and margin are often defined inside dashboard logic. An agent writing its own SQL does not see those definitions, so it produces a plausible, confidently wrong number. Governance is not only about who can see data; it is also about which answer is correct.

Nobody is watching after launch. Evaluation happens before go-live and stops. Months later a schema change or a new table silently changes what the agent retrieves, and nobody notices until a customer does.

What we would do

1. Inventory every agent and AI integration with access to your data platform: what it is for, whose credentials it uses, who owns it. Retire the orphans.
2. Give agents their own identities with least-privilege, purpose-specific access. Never let an agent borrow a person’s login.
3. Enforce policy in the platform. Move sensitive data to row- and column-level policies and masking in Snowflake, Databricks Unity Catalog or Microsoft Purview, so every consumer — dashboard, analyst or agent — gets the same rules.
4. Publish a semantic layer. Certify the metrics and entities that matter and point agents at those, rather than at raw tables.
5. Monitor in production. Log agent queries, re-run evaluation sets on a schedule and after every schema or model change, and alert when answers drift from certified metrics.

This is less glamorous than choosing a model. It is also what decides whether an agent can be trusted with real data.