The Snowflake Cortex AI sandbox escape documented by PromptArmor is getting framed as a security incident, which is accurate. It is also something more useful: a concrete demonstration that cloud access control models were not designed for AI agents, and the gap between what those models verify and what actually determines an AI agent’s behavior is where the attack lives.
The Access Control Chain and Where It Ends
Classical cloud access control is built on a chain of principals. A human authenticates. The identity maps to a role. The role carries permissions. Requests against resources are evaluated against those permissions. Audit logs record who did what, when, and under what authorization.
This model handles confused deputy problems reasonably well. If an application processes user input and uses it to query a database, the application runs under a scoped service identity, not under the user’s broader credentials. The service account defines the blast radius, and the access control system enforces it.
AI agents introduce a link the model was not designed for: a language model that interprets inputs and generates actions based on those inputs. The inputs arrive from sources that are not principals in the access control system. A vendor invoice is not a principal. A customer support ticket is not a principal. A product review scraped from an external feed is not a principal.
Yet when those documents flow into a Cortex Agent that has tool access to the Snowpark execution environment, their contents become instructions the agent acts on. The access control system can only ask whether the agent is authorized to execute Python. It has no way to ask whether the execution was induced by an untrusted document that should not have been issuing instructions at all.
The Confused Executor
The confused deputy problem describes a trusted intermediary being manipulated into using its authority to benefit an unauthorized party. The Cortex case is a variation with an important distinction: it is not just that Cortex’s authority was misdirected toward an attacker’s goals, but that Cortex generated and ran attacker-specified code using its own execution environment as the runtime. The attacker did not need to get code into the system through a deployment pipeline or an upload interface. They needed to get it into any table, document, or record that a Cortex workflow would process.
When that injected payload caused Cortex to execute malware in the Snowpark container, the container was running as the Cortex service identity with the Cortex network policy and the Cortex role permissions. From the access control system’s perspective, nothing unusual happened: an authorized service performed authorized operations in an authorized environment. The effective “attacker” who directed those operations was embedded in an invoice that nobody’s security team reviewed before it entered the data pipeline.
The access control model has no concept of intent. It verifies that an actor is permitted to perform an action. It does not verify whether the actor’s decision to perform that action was derived from a legitimate instruction or from an adversarial payload embedded in untrusted data.
Why This Differs From the 2024 Snowflake Breach
It is worth placing this next to the 2024 Snowflake credential breach, which affected hundreds of enterprise customers through stolen credentials and absent MFA enforcement. That breach’s remediation was straightforward in principle: require MFA, rotate credentials, improve session controls. The authentication model was sound; the enforcement of it was weak.
MFA is completely irrelevant to the Cortex AI sandbox escape. The AI service was fully authenticated. Its credentials were not stolen. It acted under a legitimate session with legitimate permissions. The authorization model held perfectly. The problem is that neither authentication nor authorization captures what actually determined what the AI did, which was attacker-controlled text in a database record.
This distinction matters because it means the industry playbook for cloud credential security does not apply here. You cannot fix this by hardening the authentication layer or rotating service account credentials. The attack surface is the AI’s input, and the AI’s input is every document, record, and data source it was designed to process.
What Intent-Scoped Execution Would Look Like
There is no standard security primitive for verifying whether an AI agent’s actions are consistent with its operator’s intent. But you can approximate it at the execution layer through a combination of existing controls applied more deliberately than most deployments bother with.
The most direct control is separating execution capability from data processing capability within Snowflake’s role system. A Cortex workflow that reads vendor invoices and extracts structured fields does not need access to Snowpark Python execution. Granting it only read access on the relevant stage and write access to the output schema means that even a successful injection can only produce unexpected SQL reads, not arbitrary code execution. The Snowflake privilege model supports this level of granularity; most deployments do not use it this way because the default path is to run everything under a broad analytical role.
Configuring network rules for Snowpark compute to restrict outbound connections to an explicit allowlist addresses the post-execution phase. Malware running inside a container that cannot reach external infrastructure loses most of its utility as an exfiltration or command-and-control endpoint, regardless of how it got there.
For higher-trust operations, requiring human confirmation before executing generated code closes the gap between what the AI decided to do and what the operator intended. This is operationally expensive and conflicts with the autonomy value proposition of agentic AI, but it is the closest practical analog to what parameterized queries did for SQL injection: removing the ability for untrusted input to determine execution at the point where execution happens.
The Market Selects Against the Fix
None of these controls are technically novel. Role separation, network restriction, and approval gates are standard infrastructure security practice. The reason they are not the default configuration for Cortex Agent deployments is that default configurations optimize for time-to-value, not for adversarial inputs.
The competitive pressure compounds this. Google BigQuery’s Gemini integration, Microsoft Fabric Copilot, and Databricks Mosaic AI agents all face the same architecture problem: an LLM with tool access, a code execution primitive, and a large corpus of data that includes content from external sources. The product direction across all of them is toward more autonomy, more tool access, and more seamless integration. The first platform to ship meaningful capability restrictions by default will introduce configuration burden that competitors do not have. The market, evaluated on onboarding friction, selects against the secure configuration.
This is a familiar dynamic from the early history of web application security. Default database configurations were maximally permissive. Default web server setups exposed more than they needed to. Changing defaults required accepting that some users would encounter friction, and platform vendors consistently deferred that friction until after incidents made it unavoidable.
The Structural Gap
The Cortex incident exposes an access control gap that is not Snowflake-specific and is not solvable by hardening what platforms already have. The standard cloud security model was designed for a world where the actors performing actions are humans and the systems acting on their behalf. AI agents acting on instructions derived from data sources are a different kind of actor, and the authorization model for them needs to account for where their instructions actually come from, not just whether they are permitted to act.
Until cloud platforms build input provenance and intent scoping into their AI execution primitives as first-class concepts, the security boundary for AI agents defaults to wherever the execution environment’s existing access controls happen to land. For most production deployments, that boundary is considerably broader than what any reasonable threat model would call adequate for a system that processes untrusted external data and executes code based on what it finds there.