Snowflake Cortex Executed Malware. Most of the Security Problem Predates AI.

The Snowflake Cortex AI sandbox escape documented by Simon Willison involves a language model, generated code, and AI agents. The AI framing is accurate, but it may be leading security teams toward AI-specific solutions when the core problems are mostly classical infrastructure security failures with decades of established mitigations.

This distinction matters practically. If you believe this is fundamentally an AI problem, you reach for AI-specific solutions: prompt injection classifiers, LLM output validation, model behavior guardrails. If you recognize the underlying failures as container isolation gaps and access control violations, you reach for different tools: container runtime patch management, network egress controls, service account privilege audits. Both responses are necessary, but the infrastructure set is more foundational, and many teams are underinvesting in it while focusing on AI-specific tooling.

Three Classical Failures Underneath the AI Layer

Strip away the AI components and the Snowflake Cortex situation reduces to three well-understood failure patterns.

Insufficient sandbox isolation

Snowflake’s Snowpark Python execution environment uses containerized runtimes to isolate customer code from the host and from other tenants. Container isolation has a well-documented vulnerability surface: kernel exploits that bypass namespaces (see CVE-2024-1086, a netfilter use-after-free that enabled container-to-host root access), misconfigured seccomp profiles that permit dangerous syscalls, and overlayfs vulnerabilities that allow privilege escalation from inside the container. These vulnerabilities affect any containerized execution environment, from CI/CD runners to serverless functions. The Snowflake AI layer is exposed to the same class of attack as every other cloud service running customer code in containers.

Overprivileged service identities

Cortex AI functions run within a Snowflake session context. That session holds a role, and that role has privileges. In typical enterprise Snowflake deployments, the roles used for analytics and AI workloads carry broad read access across schemas and sometimes write access to stages. If Cortex Analyst generates SQL that executes, or if Snowpark code runs as a step in a Cortex Agent workflow, the execution happens under whatever privileges the session holds. This is the confused deputy problem: a service that acts on behalf of a user inherits more privilege than any attacker who manipulates that service should be able to exercise. Least-privilege service accounts scoped tightly to the data they require is standard access control hygiene that predates LLMs by decades.

Insufficient network egress controls

Malware that executes inside a sandbox typically needs to reach external infrastructure: to download a second-stage payload, to exfiltrate data, or to report back to a command-and-control endpoint. If the Snowpark execution environment had no outbound network access beyond explicitly permitted endpoints, the malware’s utility would be severely limited even if it ran. Snowflake added configurable network rules for Snowpark to address this, but default configurations are permissive and many deployments have not restricted outbound access. Egress filtering is not an AI-specific control; it is basic network defense.

Where AI Does Add Something New

None of this means AI is irrelevant to the threat model. The AI layer contributes two capabilities that traditional execution environments do not have: autonomous code generation and susceptibility to prompt injection.

Code generation from an LLM is different from code execution by a human-written program because the code is not predetermined. A human deploying a malicious Snowpark UDF is a known attack vector with established defenses, including access controls on who can create and execute UDFs. An AI that generates Snowpark code dynamically as part of its reasoning process partially sidesteps those controls, because the code creation is a side effect of the AI’s normal operation rather than a distinct deployment action that triggers review.

Prompt injection, the technique of embedding adversarial instructions in data the AI will process, is a genuinely new attack vector. Simon Willison has written extensively on why indirect prompt injection is worse than it first appears, because it removes the requirement for an attacker to have direct access to the AI system. An attacker who can get data into any Snowflake table that a Cortex Agent reads, or into any document that Document AI processes, has a potential injection point. Customer feedback tables, third-party data feeds, uploaded invoices, and any other external data source in the pipeline all qualify.

But prompt injection only becomes a code execution vulnerability if the AI can execute code. Remove the code execution capability, and prompt injection in Cortex downgrades from “potential arbitrary code execution” to “potential unexpected data access through SQL.” That is still serious, but not malware.

The Attack Chain Step by Step

The chain that leads from prompt injection to malware execution maps directly onto the classical failures described above:

1. Attacker-controlled content enters a Snowflake table or document store (a customer form, a vendor invoice, a product review)
2. A Cortex workflow processes that content, passing it to an LLM with tool access
3. The attacker’s payload, embedded in the content, instructs the LLM to use its Python execution tool with attacker-specified code
4. The Snowpark container executes that code
5. The code exploits a container runtime vulnerability or performs harmful actions within the container’s existing access scope

Step 3 is the AI-specific vulnerability. Steps 1, 2, 4, and 5 are classical failures. A team that deploys a sophisticated prompt injection classifier while leaving steps 1, 2, 4, and 5 unaddressed has improved their posture against injection specifically but has not addressed most of the attack surface.

Why the Industry Is Getting the Balance Wrong

The pattern across cloud AI security incidents is that AI-specific mitigations get most of the attention because they are novel and because they are marketed by a growing AI security vendor ecosystem. Tools from vendors like Lakera, Rebuff, and Protect AI target AI-native threats. These products are legitimate and useful in their domain. The problem is that foundational infrastructure controls are not getting comparable investment.

Container runtime patching is boring. Service account privilege audits are tedious. Network egress rule reviews are slow. Prompt injection classifiers are new, interesting, and easy to demo. The result is that teams are often better prepared for AI-native attacks than for the classical vulnerabilities that make those attacks severe.

The OWASP Top 10 for LLM Applications lists prompt injection as its primary concern, and that is warranted for the AI-specific threat. But the infrastructure controls that determine what prompt injection can accomplish once it succeeds are not on that list, because they belong on the general infrastructure security checklists that teams were supposed to already be running.

What to Actually Audit Right Now

For teams running Snowflake Cortex in production, the Snowflake documentation for Snowpark security and network rules provides the operational controls. The audit checklist is not AI-specific:

• Which Cortex features are enabled, and which can be disabled without breaking workflows
• What roles execute Cortex operations, and what those roles can access beyond the tables they need
• What outbound network access is permitted from Snowpark execution environments
• Which external data sources flow into any Cortex prompt that has tool access
• What the container runtime patch level is, and when Snowflake last updated it (a question you can raise with their security team under your support agreement)

None of these questions require understanding LLMs, prompt injection theory, or AI agent architectures. They require the same infrastructure security rigor you would apply to any managed code execution environment.

The Snowflake Cortex sandbox escape is a genuinely novel incident in the sense that the attack vector, prompt injection through ingested data, is new. The vulnerabilities that made the attack consequential are old. Security teams that treat this primarily as an AI problem will patch the novel part and leave the old parts open. That is the wrong order of operations.