AI agents on governed data: keeping permissions intact when agents query your platform

AI agents do more than answer questions from documents: they write and run queries, call tools and chain steps together. That makes them useful on enterprise data, and it makes one design decision critical: whose permissions does the agent use when it touches your data?

The core risk: one service account for everyone

The quickest way to build an agent is to give it a single service account with broad read access. Every user then effectively has that account’s access:

• Leaks: a sales rep asks about “top customers by margin” and gets rows from a region, or columns such as personal data, they are not allowed to see.
• Blind audit: the log shows the agent ran the query, not who asked.
• Policy drift: permissions designed for people (row filters, masks, groups) are bypassed rather than reused.

The fix: the agent acts as the user

The governed pattern is simple to state: the agent queries with the identity of the person asking, so the data platform’s existing controls decide what can come back.

• Databricks: agents can use user authorization (previously called on-behalf-of-user), so queries run as the requesting user and Unity Catalog applies their permissions, row filters and column masks automatically. Agents can mix this with app-level access for shared resources such as a common vector search index.
• Snowflake: row access and masking policies set on tables propagate to semantic views and are enforced when they are queried, and Cortex Agents need privileges on both the semantic view and its underlying tables, so the querying role’s access still matters. Row access policies can also check whether an agent is active and hide rows in that case.
• Microsoft Fabric and other platforms: confirm in the documentation how the agent authenticates to each source, then test with a deliberately restricted user before trusting it.

Tools are part of the attack surface

Agents act through tools: SQL, vector search, APIs, functions. Govern each one:

• Register tools centrally (for example as Unity Catalog functions) so they have owners, permissions and lineage.
• Least privilege per tool: a tool that only needs one table should not hold access to a schema.
• Standard connections: the Model Context Protocol (MCP) standardizes how agents discover and call tools, but it does not decide who may see which data; the platform behind each tool still must.
• Writes are different: keep agents read-only until there is a review step for anything that changes data or sends messages.

Documents need the same treatment

Agents that retrieve documents must carry each document’s access rules into the index and filter at retrieval time. We cover that pattern in RAG on enterprise data: keeping document permissions intact.

Rollout checklist

1. Map every data source and tool the agent can reach, with an owner for each.
2. Make the agent query as the user wherever the platform supports it; document any shared-access exceptions.
3. Classify sensitive columns and apply masks before launch, not after.
4. Test with three users: an administrator, a typical user and a deliberately restricted one. The restricted user’s answers must not contain restricted data.
5. Log every agent query with the user’s identity, and review samples weekly at first.
6. Start read-only; add write actions only with human approval.

The short version

The identity an agent queries with decides what its answers can contain. Make agents act as the asking user so row filters, masks and audit keep working, govern every tool with least privilege, carry document permissions into retrieval, and test with a restricted user before launch.

Related: what is Unity Catalog, semantic layers for AI, how to assess AI readiness and our AI-ready data service.

Sources

• Authentication for agents, Databricks documentation (user authorization, Unity Catalog enforcement)
• Cortex Agents and best practices for semantic views, Snowflake documentation (privileges and policy propagation)
• Understanding row access policies, Snowflake documentation
• What is the Model Context Protocol?

Further reading from other practitioners

• Data governance for agentic AI: the four governance surfaces, LatentView Analytics
• Protecting your data while leveraging agentic queries in Snowflake, Aimpoint Digital
• Data readiness for AI agents, Geakminds
• What early access to Databricks’ Agent Bricks taught us, Analytics8