Cortex reached general availability in November 2025, with Cortex Code following in February 2026. These capabilities allow organizations to deploy AI agents that can query structured and unstructured data, execute code, call external tools, and expose Snowflake data to external systems via the Model Context Protocol (MCP).
The identity risk that follows is straightforward and under appreciated: a Cortex Agent runs under the privileges of the Snowflake user or role that invoked it. If that role has broad SELECT access across production tables because scoping it down was never prioritized, the agent now has exactly the same reach, and it will use it without hesitation, and often without a human in the loop. Two days after Cortex Code launched, researchers at PromptArmor demonstrated exactly this in practice: indirect prompt injection triggered malware execution that leveraged Cortex’s cached Snowflake credentials to exfiltrate data and drop tables. The vulnerability has since been patched, but the attack chain it exposed is not a quirk of one CLI: it is what privilege inheritance looks like when it meets an agentic workload.
The core problem: agents don’t renegotiate access
Snowflake Cortex is impressive in scope. An agent can answer natural language questions against structured data, retrieve and reason over unstructured documents, generate and execute Python or SQL through Cortex Code, and surface query results to external consumers through MCP integrations. This makes it genuinely useful. It also makes the access footprint of whoever deploys it a genuine security concern.
The issue is not unique to Snowflake, but the nature and gravity of the data within Snowflake’s makes it acute. Many organizations have data engineers, analysts, and pipeline accounts with standing SELECT privileges across broad swaths of their warehouse, sometimes across every schema in a database. We know how scoping these roles down requires time and cooperation that teams rarely prioritize. Those privileges exist quietly in the background, mostly harmless as long as access is exercised through deliberate human actions.
The moment a Cortex Agent is attached to that identity, the situation changes. The agent inherits the full permission footprint of the role under which it runs. It will not ask whether it should query the customer revenue table or the HR compensation schema. If the question is in scope and the privilege exists, it will answer. At scale, across sessions, and through any MCP-connected surface that now has access to the results.
Where the identity risks concentrate
Privilege mirroring at machine scale
Cortex Agents do not independently evaluate whether a query is appropriate relative to its data sensitivity. They evaluate whether a query is answerable given the permissions available. An agent configured for a product analytics use case, running under a role that also happens to have access to financial or HR data, has no internal boundary preventing it from answering questions about that data if asked. The blast radius of over-scoped Snowflake roles expands dramatically once they underpin an always-on agent.
Prompt injection turns over-privilege into active harm
The PromptArmor research published in March 2026 illustrates exactly what this looks like in practice. A prompt injection hidden in the README of an untrusted repository manipulated Cortex Code into bypassing human approval steps, escaping the sandbox, and executing a malicious script, which then used Cortex’s cached Snowflake credentials to exfiltrate table contents and drop them. The malware did not need to steal credentials separately; it used the access the agent already held. The attack worked because two conditions were simultaneously true: the agent had standing access to sensitive data, and it could be redirected by content it encountered during a legitimate task. The patch arrived with Cortex Code v1.0.25, but the underlying pattern is not unique to this vulnerability. Prompt injection sources (such as READMEs, web search results, database records, MCP responses) are too varied to eliminate. The practical defense is reducing what the agent can do if it is successfully manipulated, which brings it back to privilege scoping and eliminating standing access.
MCP as an external exposure channel
Snowflake’s MCP support means that Cortex Agent outputs can be consumed by external tools, workflows, and AI systems. This is useful for building cross-platform AI workflows, but it also means that data reachable by the agent is now potentially reachable outside the Snowflake perimeter. If the underlying role has access to regulated or confidential data, that data can flow outward through an MCP integration that may not be subject to the same access controls as the warehouse itself. Most organizations have not yet extended their data governance policies to cover MCP-connected output paths.
Service account accumulation
Cortex deployments frequently rely on service accounts or dedicated Snowflake roles created for “the agent” without tying that identity to a defined access scope or lifecycle policy. These accounts tend to accumulate privileges over time as teams add data sources or expand the agent’s responsibilities, and they are rarely reviewed or decommissioned when projects end. Within months, a purpose-built agent identity can carry access that no human reviewing it could easily justify.
Recommendations
The governance principles here are consistent with what I’ve written about other AI platforms: the access footprint of your AI agents deserves the same rigour as any privileged identity.
- Scope Snowflake roles specifically for agent use. Do not reuse developer or analyst roles for Cortex Agents. Create purpose-built roles scoped to the exact tables, schemas, and operations the agent requires. Treat agent role design as a security task, not an engineering convenience.
- Audit MCP integrations as an access governance question. Any system that can consume Cortex Agent outputs via MCP inherits an indirect path to your Snowflake data. Inventory those integrations, understand what data can flow through them, and apply appropriate controls.
- Apply lifecycle management to agent identities. Agent service accounts should be subject to the same access review and deprovisioning processes as any other identity. If the project ends or the use case changes, the access should change with it.
- Treat unstructured data access separately. Cortex can query documents and unstructured content, which often lacks the row-level or schema-level access controls applied to structured tables. Confirm that unstructured data sources accessible to the agent have appropriate classification and access boundaries.
- Monitor agent query patterns. Snowflake provides query history and access logging. Agent-driven queries should be surfaced in your identity monitoring workflows so that anomalies like unexpected schemas, unusual volumes, out-of-hours access can be detected and reviewed.
- Treat prompt injection as an identity threat, not just an AI problem. The PromptArmor attack did not target Snowflake’s authentication system. It targeted the agent’s reasoning, then used the agent’s existing credentials to cause harm. Controls that limit what the agent can access limit what an attacker can do through it. Scope first, then monitor. The injection surface (READMEs, web content, database records, MCP responses) is wide enough that elimination is not realistic; reducing the impact of a successful injection is.
In a nutshell…
Snowflake Cortex is a powerful addition to the modern data platform, and the use cases are real. But every Cortex Agent deployment is also an identity governance event. The agent does not audit itself. It queries what it can query, surfaces what it can surface, and connects to what it is given access to.