typically, my first move is to read the affected company's own announcement. but, for who knows what misinformed reason, the advisory written by snowflake requires an account to read.
another prompt injection (shocked pikachu)
anyways, from reading this, i feel like they (snowflake) are misusing the term "sandbox". "Cortex, by default, can set a flag to trigger unsandboxed command execution." if the thing that is sandboxed can say "do this without the sandbox", it is not a sandbox.
I don't think prompt injection is a solvable problem. It wasn't solved with SQL until we started using parametrized queries and this is free form language. You won't see 'Bobby Tables' but you will see 'Ignore all previous instructions and ... payload ...'. Putting the instructions in the same stream as the data always ends in exactly the same way. I've seen a couple of instances of such 'surprises' by now and I'm more amazed that the people that put this kind of capability into their production or QA process keep being caught unawares. The attack surface is 'natural language' it doesn't get wider than that.
Not the first time; From §3.1.4, "Safety-Aligned Data Composition":
> Early one morning, our team was urgently convened after Alibaba Cloud’s managed firewall flagged a burst of security-policy violations originating from our training servers. The alerts were severe and heterogeneous, including attempts to probe or access internal-network resources and traffic patterns consistent with cryptomining-related activity. We initially treated this as a conventional security incident (e.g., misconfigured egress controls or external compromise). […]
> […] In the most striking instance, the agent established and used a reverse SSH tunnel from an Alibaba Cloud instance to an external IP address—an outbound-initiated remote access channel that can effectively neutralize ingress filtering and erode supervisory control. We also observed the unauthorized repurposing of provisioned GPU capacity for cryptocurrency mining, quietly diverting compute away from training, inflating operational costs, and introducing clear legal and reputational exposure. Notably, these events were not triggered by prompts requesting tunneling or mining; instead, they emerged as instrumental side effects of autonomous tool use under RL optimization.
Fascinating read. What's curious though, is the claim in section 2.3.0.1:
> Each task runs in its own sandbox. If an agent crashes, gets stuck, or damages its files, the failure is contained within that sandbox and does not interfere with other tasks on the same machine. ROCK also restricts each sandbox’s network access with per-sandbox policies, limiting the impact of misbehaving or compromised agents.
How could any of the above (probing resources, SSH tunnels, etc) be possible in a sandbox with network egress controls?
Sandboxes are almost never perfect. There are always ways to smuggle data in or out, which is kind of logical: if they were perfect then there would be no result.
Posit, axiomatically, that social engineering works.
That is, assume you can get people to run your code or leak their data through manipulating them. Maybe not always, but given enough perseverance definitely sometimes.
Why should we expect a sufficiently advanced language model to behave differently from humans? Bullshitting, tricking or slyly coercing people into doing what you want them to do is as old as time. It won't be any different now that we're building human language powered thinking machines.
The core issue seems to be that the security boundary lived inside the agent loop. If the model can request execution outside the sandbox, then the sandbox is not really an external boundary.
One design principle we explored in LDP is that constraints should be enforced outside the prompt/context layer — in the runtime, protocol, or approval layer — not by relying on the model to obey instructions.
Not a silver bullet, but I think that architectural distinction matters here.
>Cortex, by default, can set a flag to trigger unsandboxed command execution. The prompt injection manipulates the model to set the flag, allowing the malicious command to execute unsandboxed.
>This flag is intended to allow users to manually approve legitimate commands that require network access or access to files outside the sandbox.
>With the human-in-the-loop bypass from step 4, when the agent sets the flag to request execution outside the sandbox, the command immediately runs outside the sandbox, and the user is never prompted for consent.
scope restrictions are in place but are trivial to bypass
Yep the whole thing is retarded. You cannot trust that a non-deterministic program (i.e. an LLM) will ever do what you actually tell it to do. Letting those things loose on the command line is incredibly stupid, but people out there don't care because they think "it's the future!".
>Any shell commands were executed without triggering human approval as long as:
>(1) the unsafe commands were within a process substitution <() expression
>(2) the full command started with a ‘safe’ command (details below)
if you spend any time at all thinking about how to secure shell commands, how on earth do you not take into account the various ways of creating sub-processes?
CLI is quickly becoming the default entry point for agents. But data agents probably need a much stricter permission model than coding agents. Bash + CLI greatly expands what you can do beyond the native SQL capabilities of a data warehouse, which is powerful. But it also means data operations and credentials are now exposed to the shell environment.
So giving data agents rich tooling through a CLI is really a double-edged sword.
I went through the security guidance for the Snowflake Cortex Code CLI(https://docs.snowflake.com/en/user-guide/cortex-code/securit...), and the CLI itself does have some guardrails.
But since this is a shared cloud environment, if a sandbox escape happens, could someone break out and access another user’s credentials?
It is a broader system problem around permission caching, shell auditing, and sandbox isolation.
A sandbox that can be toggled off is not a sandbox, this is simply more marketing/"critihype" to overstate the capability of their AI to distract from their poorly built product. The erroneous title doing all the heavy lifting here.
IMO, it's not even a sandbox, that's just a marketing lie.
This was internal restrictions in the code, that was bypassed. A sandbox needs to be something external to the code you are running, that you can't change from the inside.
Has anyone tried to set up a container and let prompt Claude to escape and se what happens? And maybe set some sort of autoresearch thing to help it not get stuck in a loop.
One key component of this attack is that Snowflake was allowing "cat" commands to run without human approval, but failing to spot patterns like this one:
> Cortex, by default, can set a flag to trigger unsandboxed command execution. The prompt injection manipulates the model to set the flag, allowing the malicious command to execute unsandboxed.
HOW did the prompt injection manipulate the model in that way?
Process substitution is a new concept to me. Definitely adding that method to the toolbox.
It'd be nice to see exactly what the bugbot shell script contained. Perhaps it is what modified the dangerously_disable_sandbox flag, then again, "by default" makes me think it's set when launched.
When you say just Cortex it is ambiguous as there is Cortex Search, Agents, Analyst, and Code.
Cortex Code is available via web and cli. The web version is good. I've used the cli and it is fine too, though I prefer the visuals of the web version when looking at data outputs. For writing code it is similar to a Codex or Claude Code. It is data focussed I gather more so than other options and has great hooks into your snowflake tables. You could do similar actions with Snowpark and say Claude Code. I find Snowflake focus on personas are more functional than pure technical so the Cortex Code fits well with it. Though if you want to do your own thing you can use your own IDE and code agent and there you are back to having an option with the Codex Code CLI along with Codex, Cursor or Claude Code.
It kinda sucks how "sandbox" has been repurposed to mean nothing. This is not a "sandbox escape" because the thing under attack never had any meaningful containment.
The bilekas comment is right — if there is no workspace trust or scope restriction, calling it a sandbox escape is generous. It escaped a suggestion of a sandbox.
But the broader pattern matters. Cortex bypassed human-in-the-loop approval via specially constructed commands. That is the attack surface for every agentic CLI: the gap between what the approval UI shows the user and what actually executes.
I would be interested to know whether the fix was to validate the command at the shell level or just patch the specific bypass. If it is the latter, there will be another one.
Well there's the prompt injection itself, and the fact that the agent framework tried to defend against it with a "sandbox" that technically existed but was ludicrously inadequate.
I don't know how anyone with a modicum of Unix experience would think that examining the only first word of a shell command would be enough to tell you whether it can lead to arbitrary code execution.
The attack chain here is interesting because the escape didnt require a novel vulnerability in the sandbox itself. It exploited the fact that the LLM can reason about its environment and chain tool calls in ways the sandbox designers didnt anticipate. This is the fundamental tension with agent sandboxing: you need the agent capable enough to be useful, but capability and containment are in direct tension.
typically, my first move is to read the affected company's own announcement. but, for who knows what misinformed reason, the advisory written by snowflake requires an account to read.
another prompt injection (shocked pikachu)
anyways, from reading this, i feel like they (snowflake) are misusing the term "sandbox". "Cortex, by default, can set a flag to trigger unsandboxed command execution." if the thing that is sandboxed can say "do this without the sandbox", it is not a sandbox.
I don't think prompt injection is a solvable problem. It wasn't solved with SQL until we started using parametrized queries and this is free form language. You won't see 'Bobby Tables' but you will see 'Ignore all previous instructions and ... payload ...'. Putting the instructions in the same stream as the data always ends in exactly the same way. I've seen a couple of instances of such 'surprises' by now and I'm more amazed that the people that put this kind of capability into their production or QA process keep being caught unawares. The attack surface is 'natural language' it doesn't get wider than that.
> Cortex, by default, can set a flag to trigger unsandboxed command execution
Easy fix: extend the proposal in RFC 3514 [0] to cover prompt injection, and then disallow command execution when the evil bit is 1.
[0] https://www.rfc-editor.org/rfc/rfc3514
It's a concept of a sandbox.
Not the first time; From §3.1.4, "Safety-Aligned Data Composition":
> Early one morning, our team was urgently convened after Alibaba Cloud’s managed firewall flagged a burst of security-policy violations originating from our training servers. The alerts were severe and heterogeneous, including attempts to probe or access internal-network resources and traffic patterns consistent with cryptomining-related activity. We initially treated this as a conventional security incident (e.g., misconfigured egress controls or external compromise). […]
> […] In the most striking instance, the agent established and used a reverse SSH tunnel from an Alibaba Cloud instance to an external IP address—an outbound-initiated remote access channel that can effectively neutralize ingress filtering and erode supervisory control. We also observed the unauthorized repurposing of provisioned GPU capacity for cryptocurrency mining, quietly diverting compute away from training, inflating operational costs, and introducing clear legal and reputational exposure. Notably, these events were not triggered by prompts requesting tunneling or mining; instead, they emerged as instrumental side effects of autonomous tool use under RL optimization.
* https://arxiv.org/abs/2512.24873
One of Anthropic's models also 'turned evil' and tried to hide that fact from its observers:
* https://www.anthropic.com/research/emergent-misalignment-rew...
* https://time.com/7335746/ai-anthropic-claude-hack-evil/
Fascinating read. What's curious though, is the claim in section 2.3.0.1:
> Each task runs in its own sandbox. If an agent crashes, gets stuck, or damages its files, the failure is contained within that sandbox and does not interfere with other tasks on the same machine. ROCK also restricts each sandbox’s network access with per-sandbox policies, limiting the impact of misbehaving or compromised agents.
How could any of the above (probing resources, SSH tunnels, etc) be possible in a sandbox with network egress controls?
Sandboxes are almost never perfect. There are always ways to smuggle data in or out, which is kind of logical: if they were perfect then there would be no result.
If the user has access to a lever that enables accesss, that lever is not providing a sandbox.
I expected this to be about gaining os privileges.
They didn't create a sandbox. Poor security design all around
Sandbox. Sandbagging.
Tomato, tomawto
/s
Posit, axiomatically, that social engineering works.
That is, assume you can get people to run your code or leak their data through manipulating them. Maybe not always, but given enough perseverance definitely sometimes.
Why should we expect a sufficiently advanced language model to behave differently from humans? Bullshitting, tricking or slyly coercing people into doing what you want them to do is as old as time. It won't be any different now that we're building human language powered thinking machines.
Author of LDP here [1].
The core issue seems to be that the security boundary lived inside the agent loop. If the model can request execution outside the sandbox, then the sandbox is not really an external boundary.
One design principle we explored in LDP is that constraints should be enforced outside the prompt/context layer — in the runtime, protocol, or approval layer — not by relying on the model to obey instructions.
Not a silver bullet, but I think that architectural distinction matters here.
[1] https://arxiv.org/abs/2603.08852
Yeah, this is not the meaning of "sandbox" I'm used to
> Note: Cortex does not support ‘workspace trust’, a security convention first seen in code editors, since adopted by most agentic CLIs.
Am I crazy or does this mean it didn't really escape, it wasn't given any scope restrictions in the first place ?
not quite, from the article
>Cortex, by default, can set a flag to trigger unsandboxed command execution. The prompt injection manipulates the model to set the flag, allowing the malicious command to execute unsandboxed.
>This flag is intended to allow users to manually approve legitimate commands that require network access or access to files outside the sandbox.
>With the human-in-the-loop bypass from step 4, when the agent sets the flag to request execution outside the sandbox, the command immediately runs outside the sandbox, and the user is never prompted for consent.
scope restrictions are in place but are trivial to bypass
Is this the new “gain of function” research?
Isn't it more like "imaginary function"?
People keep imagining that you can tell an agent to police itself.
Yep the whole thing is retarded. You cannot trust that a non-deterministic program (i.e. an LLM) will ever do what you actually tell it to do. Letting those things loose on the command line is incredibly stupid, but people out there don't care because they think "it's the future!".
That would be deliberately creating malicious AIs and trying to build better sandboxes for them.
Imagine if you could physical disconnect your country from the internet, then drop malware like this on everyone else.
Hard to do when services like Starlink exist.
>Any shell commands were executed without triggering human approval as long as:
>(1) the unsafe commands were within a process substitution <() expression
>(2) the full command started with a ‘safe’ command (details below)
if you spend any time at all thinking about how to secure shell commands, how on earth do you not take into account the various ways of creating sub-processes?
CLI is quickly becoming the default entry point for agents. But data agents probably need a much stricter permission model than coding agents. Bash + CLI greatly expands what you can do beyond the native SQL capabilities of a data warehouse, which is powerful. But it also means data operations and credentials are now exposed to the shell environment.
So giving data agents rich tooling through a CLI is really a double-edged sword.
I went through the security guidance for the Snowflake Cortex Code CLI(https://docs.snowflake.com/en/user-guide/cortex-code/securit...), and the CLI itself does have some guardrails. But since this is a shared cloud environment, if a sandbox escape happens, could someone break out and access another user’s credentials? It is a broader system problem around permission caching, shell auditing, and sandbox isolation.
A sandbox that can be toggled off is not a sandbox, this is simply more marketing/"critihype" to overstate the capability of their AI to distract from their poorly built product. The erroneous title doing all the heavy lifting here.
IMO, it's not even a sandbox, that's just a marketing lie.
This was internal restrictions in the code, that was bypassed. A sandbox needs to be something external to the code you are running, that you can't change from the inside.
Has anyone tried to set up a container and let prompt Claude to escape and se what happens? And maybe set some sort of autoresearch thing to help it not get stuck in a loop.
One key component of this attack is that Snowflake was allowing "cat" commands to run without human approval, but failing to spot patterns like this one:
I didn't understand how this bit worked though:> Cortex, by default, can set a flag to trigger unsandboxed command execution. The prompt injection manipulates the model to set the flag, allowing the malicious command to execute unsandboxed.
HOW did the prompt injection manipulate the model in that way?
Process substitution is a new concept to me. Definitely adding that method to the toolbox.
It'd be nice to see exactly what the bugbot shell script contained. Perhaps it is what modified the dangerously_disable_sandbox flag, then again, "by default" makes me think it's set when launched.
Snowflake and vulnerabilities are like two peas in a pod
what's the use case for cortex? is anyone here using it?
We run a lakehouse product (https://www.definite.app/) and I still don't get who the user is for cortex. Our users are either:
non-technical: wants to use the agent we have built into our web app
technical: wants to use their own agent (e.g. claude, cursor) and connect via MCP / API.
why does snowflake need it's own agentic CLI?
When you say just Cortex it is ambiguous as there is Cortex Search, Agents, Analyst, and Code.
Cortex Code is available via web and cli. The web version is good. I've used the cli and it is fine too, though I prefer the visuals of the web version when looking at data outputs. For writing code it is similar to a Codex or Claude Code. It is data focussed I gather more so than other options and has great hooks into your snowflake tables. You could do similar actions with Snowpark and say Claude Code. I find Snowflake focus on personas are more functional than pure technical so the Cortex Code fits well with it. Though if you want to do your own thing you can use your own IDE and code agent and there you are back to having an option with the Codex Code CLI along with Codex, Cursor or Claude Code.
Because "stock price go up"?
To be an effective sandbox, I feel like the thing inside it shouldn't even be able to know it's inside a sandbox.
It kinda sucks how "sandbox" has been repurposed to mean nothing. This is not a "sandbox escape" because the thing under attack never had any meaningful containment.
the title is very misleading, it was told to escape, it didn't do it on its own as you would think from the title
AIs have no reason to want to harm annoying slow inefficient noisy smelly humans.
Is there a bash that doesn't allow `<` pipes, but allows `>`?
The bilekas comment is right — if there is no workspace trust or scope restriction, calling it a sandbox escape is generous. It escaped a suggestion of a sandbox.
But the broader pattern matters. Cortex bypassed human-in-the-loop approval via specially constructed commands. That is the attack surface for every agentic CLI: the gap between what the approval UI shows the user and what actually executes.
I would be interested to know whether the fix was to validate the command at the shell level or just patch the specific bypass. If it is the latter, there will be another one.
>Snowflake Cortex AI Escapes Sandbox and Executes Malware
rolls eyes Actual content: prompt injection vulnerability discovered in a coding agent
Well there's the prompt injection itself, and the fact that the agent framework tried to defend against it with a "sandbox" that technically existed but was ludicrously inadequate.
I don't know how anyone with a modicum of Unix experience would think that examining the only first word of a shell command would be enough to tell you whether it can lead to arbitrary code execution.
And so BSides and RSA season begins.
Tl;dr they don't know what the word sandbox means.
The attack chain here is interesting because the escape didnt require a novel vulnerability in the sandbox itself. It exploited the fact that the LLM can reason about its environment and chain tool calls in ways the sandbox designers didnt anticipate. This is the fundamental tension with agent sandboxing: you need the agent capable enough to be useful, but capability and containment are in direct tension.