Governing Snowflake Cortex Agents

Cortex Agents inherit Snowflake's existing role-based access control and row and column-level security policies for any data they query inside the platform, which gives them a genuinely strong, consistent access model as long as the query stays inside Snowflake's own compute and storage. The governance question that matters is what happens when an agent calls an external function or exports results to a system outside Snowflake — because Snowflake's own access control model was built to govern data inside its platform, not to follow that data once it leaves.

What Cortex Agents cover well

Cortex Agents sit on top of two retrieval capabilities Snowflake has built into its Cortex AI suite: a tool for querying structured data through natural language, and a tool for retrieving relevant unstructured content. An agent orchestrates between them to answer a request that may need both a database lookup and a document search.

• Access control is inherited, not reinvented. A Cortex Agent querying a table is subject to the same role-based access control that governs any other query against that table, and row-access policies and column masking apply identically regardless of whether the query originated from a human analyst or an agent.
• Data never has to leave Snowflake's governed perimeter to be queried. For an agent whose entire job is answering questions about data that already lives in Snowflake, using tools that already live in Snowflake, the platform's existing security model is the correct and sufficient answer.
• Auditability of queries benefits from Snowflake's existing query history and access history features, giving a documented record of what a Cortex Agent actually queried, under which role, without needing a parallel logging system built specifically for agent activity.

For an organization whose Cortex Agents are confined to answering questions from data that lives entirely in Snowflake, without calling out to external functions or exporting results elsewhere, this is a mature, low-risk configuration. The access control question and the agent-orchestration question are cleanly separated, which is a genuine advantage over platforms where those two concerns are entangled.

Where the platform boundary bites: external functions and exports

External functions — the mechanism for calling code or an API that runs outside Snowflake — are a distinct capability from ordinary SQL functions, precisely because they leave the platform's own compute environment. That distinction matters directly for agent governance:

1. An external function call is not subject to Snowflake's row-access or masking policies once the call is made. Those policies govern what data is visible in a query result; they do not follow that data into whatever external service the function calls.
2. A Cortex Agent that can invoke an external function inherits whatever that function's underlying integration is authorized to do, which is governed by the cloud infrastructure hosting that integration, not by Snowflake's RBAC. Reviewing the agent's Snowflake role without reviewing the external function's own permission scope leaves half the picture unexamined.
3. Exporting query results to a downstream system — a BI tool, a reporting pipeline, or a general-purpose agent platform — is the point where financial and analytical data, often among the most commercially sensitive data an organization holds, leaves the perimeter Snowflake's own access controls can enforce. Data residency for AI agents covers why the destination of an export, not just the source query's access policy, needs its own governance answer.
4. Third-party MCP servers or tool integrations connected to a Cortex Agent are a separate control surface from Snowflake's native external functions, and typically require independent vetting. MCP server vetting and registry risk covers what that review should check regardless of which data platform is calling the tool.

The practical risk pattern is consistent: a Cortex Agent's Snowflake-side access can be scoped precisely and reviewed regularly, and that discipline says nothing about whether the external function or export path it uses is equally well governed, because that is a different system with a different owner.

A cross-boundary risk checklist

What is specific to Snowflake, beyond the generic inventory-and-audit layer

A cross-platform agent inventory, a unified audit trail, and consistent egress policy are the same shared controls every data platform in this comparison needs, covered in what is an AI control plane and building an AI agent inventory.

The Snowflake-specific work is narrower and sits at the row-security-versus-external-function line specifically:

• Give external function integrations a named owner separate from the Snowflake role owner. Their permission scope lives in cloud infrastructure configuration — an API gateway, a proxy service, an IAM role on the hosting cloud — not in Snowflake's own RBAC surface, so the person accountable for a Cortex Agent's Snowflake role is frequently not the person who can answer what its external functions can reach.
• Confirm row-access and masking policies were evaluated against every query path a Cortex Agent actually uses, with external function calls treated as an explicit, separate exception rather than assumed to inherit the same enforcement.
• Anomaly detection on agent-triggered compute and export volume, catching a Cortex Agent that suddenly queries or exports at a scale outside its historical pattern. Anomaly detection for agent spend covers the general pattern this applies to.

What good looks like

1. Every external function and export path reachable by a Cortex Agent is inventoried, with an owner distinct from the Snowflake role owner where the integration is separately configured.
2. Row-access and masking policies are confirmed to apply to every query path a Cortex Agent uses, with external function calls reviewed as a separate, explicit exception.
3. Spend and query volume for Cortex Agent activity is attributed per agent, not aggregated at the warehouse level.
4. A unified audit trail spans Snowflake's native query history and any external system an agent's results are exported to.
5. Cortex Agents are included in a cross-platform inventory alongside any agents built on other data or cloud platforms.

Snowflake's decision to route Cortex Agent data access through its existing RBAC and row-security model, rather than inventing a separate agent-specific permission system, is a sound design choice. The governance work an organization still owns is making sure that discipline extends to the points where an agent's activity leaves Snowflake's own compute — external functions, exports, and any tool integration that reaches outside the platform's boundary.

Common questions

Do row-access policies apply to Cortex Agent queries the same way they apply to a human analyst's query? Yes, for queries that stay inside Snowflake. Row-access and column-masking policies are enforced at the data layer based on the querying role, and a Cortex Agent operating under a role is subject to the same enforcement as any other query under that role.

Is an external function the same governance risk as a third-party MCP server? They are structurally similar in that both let an agent reach outside the platform's native access control, but they are governed by different mechanisms — an external function's permissions are set through cloud infrastructure configuration tied to Snowflake, while an MCP server's behavior is governed entirely by its own operator. Both need independent review; neither substitutes for the other.

Does Snowflake's query history give a complete audit trail for Cortex Agent activity? It gives a complete record of what was queried inside Snowflake, which is a strong foundation. It does not capture what happened to a result after it was exported to an external system, which is why a unified audit trail spanning both sides of that boundary is necessary for a genuinely complete incident reconstruction.