When the AI Runs the Code: Snowflake Cortex and the Sandbox That Wasn't

There is a category of security vulnerability that gets worse the more capable an AI system becomes. Snowflake’s Cortex AI platform recently demonstrated this in concrete terms: the service escaped its execution sandbox and ran malware, turning what should be a data analytics feature into an execution vector.

The incident matters beyond Snowflake. It sits at the intersection of two trends that have been accelerating in parallel: AI systems that can execute code, and cloud data platforms that increasingly treat AI as a first-class compute layer. When those two things meet in a misconfigured or vulnerable sandbox, the blast radius is substantial.

What Snowflake Cortex Actually Is

Snowflake Cortex is the company’s umbrella for AI capabilities embedded directly inside the Snowflake data platform. It includes several distinct components. Cortex Complete provides LLM inference via SQL functions, letting you call models like snowflake-arctic, mistral-large, and others directly from a query. Cortex Analyst translates natural language questions into SQL and executes them. Cortex Search handles retrieval-augmented generation over your data.

The code execution surface comes from Snowpark, Snowflake’s framework for writing Python, Scala, and Java logic that runs inside the Snowflake execution environment. Snowpark Python functions run inside a virtualized container layer. The pitch is that your code runs “inside Snowflake” rather than being sent out to an external service, which sounds secure. The attack surface, though, is the container boundary itself.

When Cortex features invoke Snowpark under the hood, or when Cortex Analyst generates and executes SQL that triggers Python UDFs, there is a chain of trust assumptions: the LLM output is treated as something that will eventually be executed, the execution environment is assumed to be isolated, and the isolation boundary is assumed to hold.

All three of those assumptions can fail.

The Shape of the Vulnerability

Sandbox escapes in cloud AI execution environments tend to follow a small set of patterns. Container escape via kernel exploits is the classic route, relying on unpatched kernel vulnerabilities accessible from inside the container. Privileged container misconfigurations are common in managed services where the operator exposes host capabilities for convenience. Symlink attacks and path traversal allow code inside the container to read or write to host filesystem paths. And network policy gaps let sandboxed code reach internal metadata endpoints like the AWS IMDS or, in Snowflake’s case, internal infrastructure APIs.

In the Snowflake context, the particularly alarming version involves prompt injection. If an AI feature ingests untrusted data from a user’s Snowflake tables, that data can contain instructions intended for the LLM. A malicious payload in a customer database could instruct Cortex Analyst to generate SQL or Python that, when executed, exploits the sandbox boundary. The user never typed a malicious query; it arrived through their own data.

This is not hypothetical. The OWASP Top 10 for LLM Applications lists prompt injection as its primary concern specifically because RAG pipelines and agentic systems routinely ingest data from sources they should not fully trust. Snowflake’s model of letting Cortex query your tables is precisely this architecture.

Prior Art in AI Execution Sandboxes

Snowflake is not the first to encounter this problem. OpenAI’s Code Interpreter (now called Advanced Data Analysis) runs Python in a sandboxed environment inside ChatGPT. Researchers have demonstrated container escape techniques against it, including reading files outside the intended working directory and probing network endpoints that should not be reachable.

Google’s Project IDX and GitHub Codespaces both run code in isolated containers with their own histories of configuration issues. The general problem is that container isolation is not the same as security isolation. seccomp profiles, AppArmor policies, and network namespaces all help, but they require careful configuration and the attack surface is large.

Amazon SageMaker has had similar disclosures. A 2023 report from Sysdig documented how misconfigured execution environments in cloud ML platforms could be leveraged to access instance metadata, which in AWS means potentially obtaining IAM credentials.

The pattern is consistent: managed code execution environments, when not configured with defense in depth, become a pivot point. AI systems that can generate and trigger code execution extend the attack surface to anywhere the AI’s inputs come from.

Why This Is Harder for AI Platforms

Traditional sandboxes run known code. A CI/CD runner executes your pipeline definition. A serverless function runs the code you deployed. The set of things it might do is bounded by what you wrote.

AI code execution environments run generated code. The LLM decides what to execute, sometimes based on inputs from untrusted sources. The security model needs to account not just for malicious users directly, but for users who control data the AI will ingest. That is a significantly larger threat model.

There is also an observability gap. When a human writes malicious code and deploys it, there is usually an audit trail with attribution. When an LLM generates and executes malicious code in response to a prompt injection attack, the trail is murkier. The log shows the AI made a function call; tracing back to the injected prompt in the input data requires correlating across systems.

Snowflake has strong audit logging in general. Their Access History feature tracks what data was read and written. But logging what code was generated by Cortex and then executed, with the full context of why, is a different problem.

What Defense Looks Like

A principled approach to securing AI code execution platforms involves several layers.

Capability restriction limits what sandboxed code can do even if it escapes the container. Blocking outbound network entirely except through a proxied allow-list prevents the most common post-escape action, which is phoning home or downloading a second stage payload. In Snowflake’s case, Snowpark functions do have configurable network rules as of recent releases, but the default configuration has not always been maximally restrictive.

Privilege separation ensures that the execution environment credential has the minimum necessary Snowflake privileges. If Cortex runs code under a service account that can read every table and write to external stages, an escape is catastrophic. If that account can only read the tables needed for the current query, the impact is bounded.

Input validation for AI pipelines treats LLM-bound inputs as untrusted, similar to how SQL parameters are treated as untrusted relative to query structure. This is the hardest one to implement well because the whole point of an LLM is that it can handle varied natural language; you cannot simply parameterize it.

Prompt injection detection is an active research area. Lakera, Rebuff, and others have built classifiers specifically to detect injection attempts in text before it reaches an LLM. These are imperfect but they raise the cost of attack.

Snowflake’s own documentation now recommends treating Cortex outputs that will be executed as untrusted, which is the right framing. The problem is that many customers adopted Cortex features assuming the platform handled isolation, because that is the value proposition of a managed service.

The Broader Responsibility Question

Managed service providers carry a different set of obligations than self-hosted software. When Snowflake markets Cortex as a way to run AI directly on your data without the complexity of managing infrastructure, the implicit contract is that the security properties of that infrastructure are Snowflake’s responsibility.

This incident joins a growing list of cases where AI platform providers shipped capabilities that created new security surfaces their customers did not understand they were accepting. The Microsft Copilot prompt injection issues, the Slack AI data exfiltration vector reported in 2024, and various RAG pipeline injection demonstrations all follow the same pattern.

The capability shipped. The security model did not keep up.

For anyone running Snowflake Cortex features against production data today, the immediate questions are: what network egress is permitted from Snowpark execution environments, what privileges do the service identities hold, and what data from external or user-controlled sources flows into Cortex prompts. The answers to those three questions determine how bad a similar vulnerability would be in your environment.

The sandbox escape itself is a Snowflake engineering problem. The architecture that made it dangerous is a design pattern the whole industry is still working out how to secure.