· 6 min read ·

When the Data Warehouse Becomes the Attack Vector: Snowflake AI and the Sandbox Problem

Source: hackernews

The security research published by PromptArmor describing how Snowflake’s AI environment could be manipulated to escape its sandbox and execute malware lands at an uncomfortable moment for the data warehouse industry. Enterprise AI integrations are being added to platforms designed around a fundamentally different threat model, and the consequences are becoming concrete.

Here is what the architectural picture looks like, and why this class of vulnerability is likely to keep appearing.

Snowflake Cortex and Its Execution Model

Snowflake’s Cortex suite is a collection of LLM-powered features that run directly within the Snowflake data cloud. The most relevant piece is Cortex Analyst, which takes natural language queries, sends them along with schema information and table samples to an LLM, and receives back SQL that runs in the user’s warehouse context.

Snowflake also ships LLM functions callable directly from SQL:

SELECT SNOWFLAKE.CORTEX.COMPLETE(
  'mistral-7b',
  CONCAT('Summarize this customer feedback: ', feedback_text)
) FROM customer_feedback;

This pattern, passing a column value into an LLM prompt, is exactly where prompt injection lives. If the content of feedback_text contains instructions rather than feedback, the LLM may follow them. The trust boundary between data the AI reads and instructions the AI follows is structural, not something you configure away.

Cortex Agents, a newer feature that combines LLM reasoning with tool use, introduce a more dangerous surface. Agents can be given tools: searching knowledge bases, querying data, and in some configurations, executing Python via Snowpark. The execution is supposed to be isolated within Snowflake’s container infrastructure.

According to PromptArmor’s research, that isolation failed.

The Attack Chain

The attack follows a recognizable pattern:

  1. Malicious content is planted in data the AI will process: a customer record, a document in a Snowflake stage, a column value in a table the agent queries.
  2. The AI, following its embedded instructions, uses one of its available tools to execute code.
  3. That code, running in the Snowflake compute environment, escapes the container boundary.
  4. The escaped process downloads and runs a malware payload from an external endpoint.

The critical link is step three. Snowflake’s containers run on cloud infrastructure shared across customer workloads. A successful escape from the container context has potential implications beyond a single customer’s environment.

Planting data that the AI will process is sufficient to trigger the chain. In many enterprise setups, that means a vendor form submission, a customer support ticket, or an uploaded document. No warehouse credentials required.

Why Prompt Injection Cannot Be Patched with Input Sanitization

The core problem is that LLMs cannot reliably distinguish between data they are processing and instructions they are supposed to follow. This is not a configuration error or a missing sanitization step. It is a fundamental property of how transformer-based language models work: everything arrives as tokens, and the model has no cryptographic or structural mechanism to separate content from commands.

Mitigations exist but none of them close the gap entirely:

  • Structured prompts with explicit delimiters place user data inside XML or JSON wrappers, with system instructions to treat content inside those wrappers as data only. This reduces the attack surface. Researchers have consistently demonstrated bypasses for most delimiter schemes, because the LLM is still being asked to reason about the content.
  • Output filtering scans LLM outputs before execution, looking for patterns that indicate injection success. This catches obvious cases but misses sophisticated payloads and indirect triggers.
  • Capability restriction is the most effective control. An LLM that can only produce text cannot execute code. The moment you give it code execution capabilities, you must treat it with the same caution you would apply to arbitrary code execution from user input.

Snowflake’s Cortex Agents were given code execution capabilities. The security model around those capabilities did not hold.

This Class of Attack Has a History

The pattern of AI-assisted code execution leading to sandbox escape is not new. In 2023, researchers demonstrated prompt injection attacks against ChatGPT plugins, where a malicious webpage could exfiltrate a user’s conversation history by injecting instructions into content the model was summarizing. GitHub Copilot Chat faced similar issues when used to analyze untrusted code repositories. Microsoft’s Copilot for M365 was shown to be vulnerable to indirect prompt injection through malicious documents stored in SharePoint.

What distinguishes the Snowflake case is the execution environment. A data warehouse is not a chat interface. It is infrastructure that holds production data for enterprises, frequently under regulatory compliance requirements. When the attack surface moves into the warehouse layer, the potential blast radius includes sensitive financial records, healthcare data, and PII, all without the attacker needing warehouse credentials.

The Snowflake credential-theft campaign of 2024, which led to confirmed breaches at Ticketmaster, AT&T, and others, demonstrated how much damage flows from compromised Snowflake customer environments. The PromptArmor finding shows a path to similar impact that bypasses credential theft entirely: compromise through the data the AI is trusted to read.

The Broken Trust Model

Traditional data warehouse security assumes data is inert. Row-level security, column masking, and query auditing all operate on the assumption that data itself cannot take actions. An attacker who can write to a low-privilege table cannot affect how other queries run. That assumption breaks the moment an AI reads that table and acts on its contents.

The architectural fix is to treat data processed by AI as untrusted input at the system level, not just the application level. Concretely:

  • AI agents should run in separate, network-isolated environments with no access to shared infrastructure.
  • Tool execution, whether code running or external API calls, should require explicit human approval or be limited to a predefined, audited allowlist.
  • Every action taken by an AI agent in a production environment should be logged with the full prompt context that triggered it, making anomalies detectable and reproducible.

These are not novel security principles. They are the same principles that govern web application security, where user input is never trusted and code execution happens in isolated contexts. The difficulty is that AI platforms are being built quickly by teams whose primary expertise is in model performance and developer experience, and the threat model is still poorly understood by most buyers and many builders.

The Broader Platform Risk

Snowflake is not uniquely culpable here. AWS Bedrock Agents, Azure AI Foundry, Google Vertex AI Agent Builder, and every other cloud platform offering agentic AI with code execution capabilities carries a version of this risk. OWASP’s LLM Top 10 lists prompt injection as the top vulnerability in LLM applications precisely because it enables this kind of indirect control. The security community has been documenting it consistently since 2023.

The difference between 2023 and now is that agentic systems in enterprise data platforms are no longer experimental. They are in production, connected to real data, and given real capabilities. The research is catching up to the deployments, and the results are not reassuring.

What to Do If You Are Using Cortex Features

If you are running Cortex Analyst or Cortex Agents against data that includes externally sourced content, treat that data as a potential attack vector:

  • Audit what tools your Cortex Agents have access to, particularly Python execution or external network access.
  • Avoid running agents in agentic mode against data sources you do not fully control.
  • Monitor warehouse network egress. A Cortex job making outbound connections to unknown hosts warrants investigation.
  • Review Snowflake’s security bulletins for any Cortex-specific patches, and confirm directly with Snowflake whether the specific vulnerability described by PromptArmor is remediated in your environment.

The broader takeaway extends beyond this incident. Any AI system that can both read untrusted data and take actions in the real world needs to be designed with the assumption that the data will attempt to redirect it. Sandboxes that were not built with that threat model in mind will keep failing under it.

Was this interesting?