How to Govern AI Agents in Snowflake and Databricks Notebooks

The Governance Gap Native Platforms Don't Close

Snowflake and Databricks both provide mature identity and access control systems. Snowflake role-based access control and Databricks Unity Catalog govern which principals can connect to which compute resources, query which tables, and execute which jobs. These controls operate at the level of the platform: they answer the question of who is allowed to enter a notebook session or attach to a warehouse.

They do not answer a different question that agentic workflows introduce: once inside that session, what is the agent doing, and should it be allowed to do it. A notebook typically executes code under a single inherited session credential. When a human data scientist writes and runs a cell, that credential authorizes the action. When an AI agent embedded in the same notebook autonomously issues a query, calls an external tool, or modifies a table, it frequently does so under that same inherited credential. The platform has no native mechanism to distinguish an agent-initiated action from a human-initiated one, and no native mechanism to apply a narrower permission set to the agent than to the human user who launched the session.

This is the specific governance gap enterprises need to close before scaling agentic workflows in production: not a lack of platform access control, but a lack of action-level control over what an agent does with the access it has inherited.

Why Broad, Persistent Credentials Are the Core Risk

Agents operating inside notebooks typically inherit broad, persistent credentials scoped to the session rather than to the task. A credential provisioned for a data science workload often carries read and write access across multiple schemas or catalogs, because it was provisioned for a human user with a range of legitimate responsibilities. An agent executing a narrow, well-defined task does not need that full scope, but without a separate enforcement layer, it operates with it anyway.

The risk is compounded by the fact that agent actions are often unmonitored at the tool-call level. Native audit logs in data platforms are generally built to capture query- or job-level events: what query ran, which job executed, which user or service principal issued it. They are not built to capture the intermediate reasoning steps or sequence of tool calls an agent makes en route to that query. If an agent calls three tools, discards two responses, and executes a query based on the third, the platform log typically shows only the final query, not the decision path that led to it. Reconstructing that path after an incident, or during a compliance review, is difficult or impossible without additional instrumentation.

Architectural Pattern: An Intermediary Enforcement Layer

The architectural pattern that addresses this gap places a runtime enforcement layer between the agent and the backend platform APIs, rather than relying solely on the platform's native permission model. This layer intercepts tool-call requests before they reach Snowflake or Databricks, evaluates each request against defined policy, and logs the request and outcome regardless of whether it was permitted or blocked.

This approach is consistent with the intermediary-layer pattern seen in Model Context Protocol-style architectures, where an agent's tool calls pass through a controlled interface rather than directly invoking backend systems. The enforcement layer does not need to duplicate Snowflake roles or Unity Catalog permissions; it needs to sit alongside them, applying a finer-grained policy check (specific action, specific object, specific session context) before a request is allowed to proceed to the platform's own access control layer.

Established correctly, this pattern also allows short-lived, task-scoped credentials to be issued per agent action rather than relying on a single persistent session credential. This narrows the blast radius of any single compromised or misbehaving agent action without requiring changes to how human users are provisioned.

Governance Considerations for Security and Platform Teams

Accountability becomes difficult when agent and human actions share a credential and are indistinguishable in logs. Security teams need a way to attribute specific actions within a session to the agent rather than the user, both for internal review and for external compliance inquiries. This requires defining, in advance, what audit artifacts are necessary to reconstruct a full agent action sequence: not just the final query executed, but the tool calls, permission checks, and any denied requests that preceded it.

Teams also need an escalation path for the case where an agent's requested action falls outside pre-approved policy boundaries. Without a defined override or escalation procedure, teams tend to default to either blocking all unrecognized requests, which breaks legitimate workflows, or allowing them by default, which reintroduces the governance gap this guide addresses. Neither is an acceptable default at scale, which is why policy enforcement and escalation handling need to be designed together, not treated as separate problems.