Snowflake Cortex agents turn broad role access into data exposure

At a glance

What this is: This article argues that Snowflake Cortex agents inherit the full privileges of the invoking role, turning broad warehouse access into an agentic data-exposure problem.

Why it matters: For IAM and NHI practitioners, it shows why agent deployments must be governed as privileged identities rather than treated as a simple application feature.

👉 Read P0 Security's analysis of Snowflake Cortex agent identity risk

Context

Snowflake agent governance breaks down when an autonomous workload inherits the same access as the human or service identity that launched it. In practice, that means broad SELECT rights, unreviewed service accounts, and external tool connections can turn a useful agent into an identity risk multiplier for NHI governance.

The operational issue is not that the agent is malicious. It is that the permission model was built for deliberate human use, not for always-on execution through AI agents and MCP-connected surfaces. Once an agent can query structured and unstructured data under a broad role, the blast radius of that role becomes the blast radius of the agent.

Key questions

Q: How should security teams govern AI agents that inherit user or role permissions?

A: Security teams should treat inherited permissions as a privilege design problem, not a model problem. Give each agent a dedicated identity, scope it to the minimum data and actions required, and review it on the same lifecycle schedule as other non-human identities. If an agent can inherit broad access, it can also inherit broad damage.

Q: Why do autonomous agents increase the risk of over-privileged access?

A: Autonomous agents increase risk because they can use permissions continuously, at scale, and without human hesitation. A role that looks acceptable for a person can become dangerous when an agent can query more often, across more surfaces, and under conditions where prompt injection or tool misuse can redirect its behaviour.

Q: What is the difference between least privilege for people and least privilege for agents?

A: For people, least privilege limits what a person can do during interactive use. For agents, least privilege must also constrain what the system can do after a prompt, tool call, or integration failure. Agent privilege should be narrower, more explicit, and tied to lifecycle controls because the execution pattern is autonomous.

Q: When should organisations treat agent output integrations as part of access governance?

A: They should do so whenever agent output can reach external tools, analytics layers, or downstream workflows. If data leaves the core platform through MCP or another integration, the access path extends beyond the original system. That path needs the same review, logging, and sensitivity controls as the source environment.

Technical breakdown

Privilege inheritance in Snowflake Cortex agents

Cortex agents execute under the Snowflake user or role that invoked them, which means the agent does not negotiate a fresh security boundary for each action. If the underlying role can query many schemas or tables, the agent can do the same when prompted. That is a classic privilege inheritance pattern, but it becomes far more dangerous when execution is autonomous and continuous. The security flaw is not the agent itself. The flaw is allowing machine-scale use of human-shaped entitlements.

Practical implication: Review every agent-facing role as if it were a privileged non-human identity with direct data access.

Prompt injection becomes an access amplification path

Prompt injection matters here because it does not need to defeat authentication. It only needs to steer the agent into using access it already has. In the source example, malicious content triggered the agent to execute code, then use cached credentials to exfiltrate data and alter tables. The pattern is broader than one platform: if a model can be redirected during a legitimate task, over-broad permissions turn that redirection into impact. Controls must therefore reduce reachable privilege, not just block bad prompts.

Practical implication: Treat prompt injection as an identity and privilege containment problem, not only an AI content-safety issue.

MCP extends the data path outside the warehouse

Model Context Protocol lets agent outputs flow into external tools and systems, which is useful for cross-platform automation but dangerous when the underlying data is sensitive. Once an agent can expose results through MCP, the warehouse perimeter no longer contains the full access path. That creates a governance gap if downstream systems are not governed with the same controls as Snowflake itself. The architectural lesson is simple: the agent’s access path includes every integration that can consume its output.

Practical implication: Inventory MCP-connected systems as part of the same access review process used for the warehouse.

Threat narrative

Attacker objective: The attacker’s objective is to convert legitimate agent access into unauthorised data extraction and destructive warehouse actions.

1. Entry occurs when an indirect prompt injection hidden in untrusted content steers the Cortex Code workflow during a legitimate task.
2. Escalation occurs when the agent uses cached Snowflake credentials and inherited role privileges to bypass intended approval steps and execute code.
3. Impact occurs when the agent exfiltrates data and drops tables using the access already present in the environment.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Privilege inheritance is the central NHI risk in agentic data platforms. When an agent executes under a user or role with broad warehouse access, the security model quietly shifts from least privilege to borrowed privilege. That is acceptable for a narrow script, but not for an autonomous system that can answer, query, and act at machine speed. The practitioner lesson is to scope every agent identity as if it were a high-value NHI.

Prompt injection becomes more damaging when it targets a privileged identity. The attack does not need to break the platform’s authentication if it can instead influence what the agent asks for or executes. Once a manipulated agent can reach regulated or sensitive data, the issue is no longer model behaviour alone. The right control is reducing the data and actions available to the agent before manipulation succeeds.

MCP creates an identity blast radius that spans beyond the core platform. Output that leaves the warehouse through tool integrations can reach systems that were never designed to inherit Snowflake-style access controls. That turns downstream tooling into part of the attack surface, not just part of the workflow. Practitioners should classify MCP connections as governed data paths, not convenience features.

Purpose-built agent roles are now a baseline requirement, not an optimisation. Reusing analyst or developer roles for agents is a governance shortcut that compounds over time as scopes expand. The better pattern is a dedicated agent identity with narrowly defined access, explicit lifecycle controls, and reviewable entitlements. In NHI terms, the identity must match the use case, not the team that created it.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented any policies to govern AI agents, even though 92% agree governance is critical to enterprise security.
• The governance gap is already visible in practice, so teams should pair agent rollout with lifecycle control and the Ultimate Guide to NHIs before exposure expands further.

What this signals

Agentic data platforms are now part of the identity perimeter. Once an AI agent can query structured and unstructured data, execute code, and pass results through MCP, traditional application boundaries stop describing the real exposure model. The programme implication is direct: security teams need an identity-first control plane for agents, not just monitoring around the data platform.

The scale of this shift is already showing up in adoption behaviour. With 98% of companies planning to deploy even more AI agents within the next 12 months, per AI Agents: The New Attack Surface report, the question is no longer whether agent access will expand, but whether governance will expand with it.

Identity blast radius: when an agent inherits a broad role, the real risk is not the agent’s intent but the range of data and actions that role already permits. Teams should therefore design agent identities around task boundaries, sensitive-data classification, and explicit deprovisioning triggers.

For practitioners

• Implement purpose-built agent roles Create separate Snowflake roles for agents and limit each one to the exact tables, schemas, and operations the use case requires. Do not reuse analyst or developer entitlements for autonomous workloads, and document the intended scope as part of identity governance.
• Inventory MCP-connected data paths Map every external tool or workflow that can receive Cortex outputs through MCP, then classify each path for sensitivity, logging, and downstream control requirements. Treat the integration inventory as part of access review, not as an architecture afterthought.
• Apply lifecycle controls to agent identities Subject agent service accounts to the same review, rotation, and deprovisioning cadence used for other NHI types. When a project ends, remove the role and connected access promptly so orphaned agent identities do not accumulate standing privilege.
• Monitor agent queries for blast-radius indicators Use Snowflake query history and identity monitoring to flag unusual schemas, unexpected volume, and out-of-hours access from agent-driven sessions. This is especially important where broad SELECT privileges could expose regulated data or prompt-injected workflows.

Key takeaways

• Snowflake agents inherit the permissions of the role that invokes them, so over-scoped access becomes autonomous exposure.
• Prompt injection is more dangerous when it can steer an agent that already holds cached credentials and broad warehouse rights.
• Agent governance should start with dedicated identities, narrow role scope, and lifecycle controls before MCP or data-sharing paths expand the blast radius.

Key terms

• Agent Identity: An agent identity is the non-human identity assigned to an autonomous software system that can act, query, and call tools. In security terms, it should be treated as a privileged workload identity with explicit scope, lifecycle controls, and monitoring, not as an application convenience account.
• Privilege Inheritance: Privilege inheritance occurs when a system uses the permissions of the human or service identity that launched it. For agents, this means the workload can access anything the parent role can access, which makes entitlement design more important than the model’s natural-language capabilities.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, and actions exposed when a single identity is compromised or overused. For non-human identities, the concept matters because a small access mistake can become a large automated impact when an agent can execute repeatedly and without supervision.

What's in the full article

P0 Security's full blog post covers the operational detail this post intentionally leaves for the source:

• The step-by-step PromptArmor attack chain that moved from indirect prompt injection to code execution and data exfiltration.
• The specific Snowflake logging and query-history behaviours practitioners can use to spot agent-driven anomalies.
• The exact access scoping and lifecycle practices for purpose-built agent roles across warehouse and MCP-connected systems.
• The concrete ways unstructured data access changes the classification and control problem for agent workflows.

👉 P0 Security's full post covers the PromptArmor attack chain, access scope, and monitoring implications.

Deepen your knowledge

Snowflake agent privilege scoping and non-human identity lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous data access, it is worth exploring.