How a Hidden Prompt Let an AI Agent Escape Cursor’s Sandbox

Imagine you’re writing code.

Nothing unusual appears on your screen.

No warning.

No approval prompt.

Meanwhile, your AI coding assistant performs a web search to help answer your question.

Buried inside one of those search results is a hidden prompt.

The AI reads it.

A few moments later, it begins executing commands outside its sandbox with access to your files, SSH keys, cloud credentials, and anything else your machine can reach.

You never notice.

This is the latest vulnerability discovered in Cursor.

When AI coding agents first appeared, they ran with exactly the same permissions as the developer using them.

That meant they could:

• Read your files

• Execute terminal commands

• Access SSH keys

• Reach cloud environments

• Use any credentials already available on your machine

This wasn’t considered a flaw.

It was a deliberate design decision.

The more restrictions you place on an AI agent, the more often it has to interrupt you with permission prompts. And once developers are forced to approve every other command, much of the productivity advantage disappears.

To solve that problem, every major AI coding assistant introduced an unrestricted mode.

• Claude Code calls it --dangerously-skip-permissions

• OpenAI Codex CLI calls it --yolo

• Gemini CLI calls it --approval-mode yolo

These options exist for a good reason.

Inside isolated CI/CD environments or disposable containers, unrestricted execution is often perfectly acceptable because the blast radius is tightly controlled.

The problem is that many developers also use these modes on their local laptops to avoid interruptions.

And a modern developer laptop is no ordinary endpoint.

It contains production credentials, signing certificates, API keys, SSH access, AI agent configurations, and often direct access to cloud infrastructure.

That combination—an autonomous AI agent with unrestricted access to a developer workstation—created an obvious security concern.

So the industry introduced sandboxes.

The idea was simple:

Let the AI execute commands autonomously.

But only inside an isolated environment that prevents it from touching the rest of the host machine.

For a while, that looked like a good compromise.

Until this vulnerability showed otherwise.

1. Attacker places a malicious prompt inside content that the AI agent is likely to retrieve—for example, a web search result. The instruction is invisible to the developer but readable by the AI.
   

2. The AI fetches the content during normal operation. Instead of treating the hidden instruction as untrusted input, it follows it.
   

3. The injected prompt convinces the AI agent to overwrite one of the helper files responsible for enforcing the sandbox. Nothing crashes. Nothing looks suspicious.
   

4. Once that helper file has been modified, the next command no longer executes inside the sandbox. Instead, it runs directly on the developer’s host machine with the developer’s own privileges. Sandbox has been persuaded to disable itself.
   

5. At this point, the AI agent can access anything the developer can: Source code, SSH keys, Cloud credentials, API tokens, Signing certificates, Local files. All because it followed a hidden instruction embedded in otherwise normal-looking content.

1. Every new security control creates a new design problem. AI coding agents originally had unrestricted access. To reduce risk, we introduced sandboxes. Now we’ve discovered that an attacker can sometimes convince the agent to dismantle its own containment. This is a recurring pattern in cybersecurity. Every new capability creates a new control. Every new control creates a new attack surface. Security is rarely a destination. It’s an ongoing cycle of adaptation.
   

2. Sandboxes don’t fully eliminate risk. The sandbox itself wasn’t exploited. The AI agent was. The protection ultimately depended on the agent respecting the mechanism enforcing the boundary. Once the agent was convinced to modify that mechanism, the protection disappeared. This is an important reminder that many AI security controls ultimately depend on agent behavior, not just operating system isolation.
   

3. Autonomy is becoming the defining security trade-off. The hardest question isn’t how to make AI agents more capable. It’s how much autonomy we’re willing to give them. Too much freedom, and a single hidden prompt can have real consequences. Too many restrictions, and developers disable the protections because they interrupt their workflow. Every AI coding platform is currently trying to solve this same problem. There isn’t an obvious answer. Only different trade-offs.
   

4. Prompt injection is evolving into a system security problem. Prompt injection was initially discussed as a way to manipulate chatbot responses. Today it is something much larger. When AI agents can execute commands, modify files, and interact with operating systems, prompt injection is no longer just an LLM problem. It becomes a system security problem.

The biggest lesson from this vulnerability isn’t that Cursor had a sandbox escape.

It’s that AI agents are changing where security decisions are made.

Traditionally, operating systems decided what code could execute.

Increasingly, AI agents are making those decisions themselves.

That shifts part of the security boundary from deterministic software to probabilistic reasoning.

And that’s fundamentally different.

The future of AI security won’t be determined by making agents smarter.

It will be determined by designing systems that remain secure even when those agents make the wrong decision.