The Ingestion Path Is the Attack Path: What the Snowflake Cortex Sandbox Escape Reveals About AI in Data Warehouses

Security researchers at PromptArmor published a report demonstrating that Snowflake’s AI platform could be manipulated to escape its execution sandbox and run malicious code. The finding landed on Hacker News with significant traction, and it deserves more than the usual AI-security-is-scary response. The specific vulnerability class it represents has architectural roots that most enterprise AI deployments have not seriously confronted.

What Snowflake Cortex Actually Does

Snowflake Cortex is the collection of AI capabilities built directly into the Snowflake Data Cloud. It includes LLM-powered SQL functions like COMPLETE, SUMMARIZE, SENTIMENT, TRANSLATE, and CLASSIFY_TEXT. It includes Cortex Analyst, a natural language to SQL interface that lets users query data warehouses in plain English. And it includes Cortex Agents, an agentic framework where LLMs can invoke tools, run queries, and orchestrate multi-step workflows entirely within Snowflake.

The appeal is real. Keeping AI close to the data avoids egress costs, simplifies access control, and reduces latency on data-heavy workloads. Snowflake’s compute infrastructure, via Snowpark, already ran Python, Java, and Scala in isolated containers before Cortex existed. Cortex extends this by letting LLMs decide what code to run and when. Cortex Analyst generates SQL and executes it. Cortex Agents call tools and process results. The LLM is the control plane for code execution.

That framing is where the security problem begins.

Prompt Injection as a Code Execution Primitive

Prompt injection works by embedding instructions in data that a model processes, causing it to follow those instructions rather than the ones its operators intended. When the model’s action space is text generation, injection produces bad outputs. When the model’s action space includes executing code against a production data warehouse, injection becomes an arbitrary code execution vector.

The attack chain in a Cortex Analyst or Cortex Agent scenario looks like this: an attacker seeds malicious content into a table, document, or record that a Cortex pipeline processes. The content contains embedded instructions. The model, which is designed to be instruction-following, complies. That compliance produces code, SQL, or tool invocations that the attacker controls. In Snowflake’s execution environment, that code runs.

What PromptArmor demonstrated is that this code execution can break out of Snowflake’s sandbox entirely. That escalation matters because a successful sandbox escape is not just the model doing something bad inside Snowflake. It opens potential access to the underlying compute infrastructure, to credentials in the execution environment, to the host network, and to outbound network paths that containers inside trusted cloud environments typically have.

Why the Data Warehouse Context Compounds the Risk

This vulnerability class is more dangerous in a data warehouse than in most other systems, for three compounding reasons.

First, data warehouses hold concentrated sensitive assets. A typical Snowflake deployment might contain financial records, customer PII, sales pipeline data, HR records, audit logs, and application telemetry. It is deliberately architected to be the single source of truth for an organization. When you compromise compute inside that environment rather than at its perimeter, you start with access to everything the compromised role can see, which is often substantial.

Second, the outbound network posture of warehouse compute tends to be permissive. Data pipelines need to push results to external systems, call enrichment APIs, and integrate with third-party tools. A sandbox escape into a context with broad outbound network access is not a dead end; it is a data exfiltration path. The attacker does not need to find data and extract it from outside the perimeter, because the escaped process is already adjacent to it.

Third, the AI’s appetite for external data creates the injection surface directly. Cortex features are most valuable when processing documents, emails, customer records, support tickets, or other unstructured data ingested from external sources. Every external record that a Cortex pipeline processes is a potential injection vector. The more useful you make the AI by feeding it external data, the larger the attack surface becomes, and that relationship between usefulness and attack surface is structural rather than incidental.

The Pattern Is Wider Than Snowflake

Snowflake is a specific instance of a general problem every AI-enabled platform is navigating. Microsoft Copilot for Microsoft 365 had documented prompt injection vulnerabilities shortly after launch, where processing a malicious email could cause Copilot to exfiltrate data from the recipient’s mailbox. GitHub Copilot Workspace, which generates and executes code, operates in a context where prompt injection via repository content is a meaningful threat vector. Amazon Bedrock Agents, when connected to tools that perform real actions, face the same structural issue.

The consistency of the pattern reflects how AI features get built. Capabilities are added by teams focused on usefulness and integration, not adversarial inputs. The security review processes that apply to traditional code are not well-suited to evaluating LLM-mediated code execution, because the threat model is different: the execution surface is defined by what the model can be convinced to do, not by what the code statically permits. That distinction falls outside most existing review frameworks.

What Actual Mitigation Requires

Input validation and output filtering are the standard first responses to prompt injection. Neither is sufficient for sandbox escapes.

Reliably validating LLM inputs to block injection is not tractable because injected instructions can be embedded in legitimately structured data and expressed in arbitrarily complex ways. An attacker encoding instructions in base64 inside an HTML comment inside a JSON string inside a database record is not a contrived scenario; it is a straightforward obfuscation technique that evades pattern-based filters.

Output filtering can catch known-malicious patterns in generated code, but effective sandbox escape payloads do not have to look like malware at the text level. They have to be syntactically valid code that probes container boundaries, reads environment variables, makes outbound connections, or fetches and executes binaries. Distinguishing that from legitimate Snowpark code at scale is not a tractable filtering problem.

What reduces the risk substantively is architectural:

Least-privilege execution roles. The Snowflake role used by Cortex and Snowpark compute should have precisely the access required for the task at hand, not broad inherited permissions from an admin context. This does not prevent sandbox escape, but it limits what an escaped process can read inside Snowflake before it exits the environment.

Restricted outbound network for AI compute. Snowflake supports network policies and external network access controls. Applying these to Cortex and Snowpark execution contexts so containers cannot make arbitrary outbound connections significantly reduces the value of a successful escape. An escaped process that cannot reach an attacker-controlled server loses most of its utility as an exfiltration or command-and-control endpoint.

Isolation between trusted and untrusted data contexts. If your Cortex pipeline processes external, user-generated, or otherwise untrusted data, that execution should not happen in the same compute context as queries on your most sensitive internal tables. Separate execution environments with separate roles, separate network policies, and clear data flow boundaries between them reduce blast radius substantially.

Treating ingested data as adversarial by default. Every document, email, or external record processed by a Cortex feature should be treated as a potential injection attempt at the system design level. This changes what you build and how you test it. It is operationally awkward because it conflicts with how people want to use these features, but it is the accurate security model for any AI system that processes untrusted inputs and executes code on the results.

The Takeaway

The PromptArmor research is a concrete demonstration of what happens when a system’s security model does not account for an LLM being the control plane for code execution. The controls that governed Snowflake’s execution environment before Cortex arrived, container isolation, role-based access control, network policies, remain necessary but are no longer sufficient when an LLM can be convinced via adversarial inputs to generate and execute arbitrary code on behalf of an attacker.

Enterprise AI adoption is moving considerably faster than the security frameworks that should accompany it. The Snowflake case is useful because it is specific, reproducible, and documented. The missing piece in most enterprise AI security reviews is a threat model that accounts for adversarial inputs flowing through every data pipeline that feeds the AI. Any pipeline that processes external data and routes results to an AI system with code execution capabilities is a potential attack path, and designing for that assumption from the start produces fundamentally different systems than retrofitting security controls onto existing AI features after the fact.