from deno_sandbox import DenoDeploy
sdk = DenoDeploy()
with sdk.sandbox.create() as sb:
# Run a shell command
process = sb.spawn("echo", args=["Hello from the sandbox!"])
process.wait()
# Write and read files
sb.fs.write_text_file("/tmp/example.txt", "Hello, World!")
content = sb.fs.read_text_file("/tmp/example.txt")
print(content)
Took this idea and ran with it using Fly's Sprites, inspired by Simon's https://simonwillison.net/2026/Feb/3/introducing-deno-sandbo.... Use case: Claude Code running in a sandboxed Sprite, making authenticated API calls via a Tokenizer proxy without credentials ever entering the sandbox.
Hit a snag: Sprites appear network-isolated from Fly's 6PN private mesh (fdf:: prefix inside the Sprite, not fdaa::; no .internal DNS). So a Tokenizer on a Fly Machine isn't directly reachable without public internet.
@tptacek's point upthread about controlling not just hosts but request structure is well taken - for AI agent sandboxing you'd want tight scoping on what the proxy will forward.
> In Deno Sandbox, secrets never enter the environment. Code sees only a placeholder
> The real key materializes only when the sandbox makes an outbound request to an approved host. If prompt-injected code tries to exfiltrate that placeholder to evil.com? Useless.
It's a little HTTP proxy that your application can route requests through, and the proxy is what handles adding the API keys or whatnot to the request to the service, rather than your application, something like this for example:
Application -> tokenizer -> Stripe
The secrets for the third party service should in theory then be safe should there be some leak or compromise of the application since it doesn't know the actual secrets itself.
Presumably the proxy replaces any occurrence of the placeholder with the real key, without knowing anything about the context in which the key is used, right? Because if it knew that the key was to be used for e.g. HTTP basic auth, it could just be added by the proxy without using a placeholder.
So all the attacker would have to do then is find and endpoint (on one of the approved hosts, granted) that echoes back the value, e.g. "What is your name?" -> "Hello $name!", right?
But probably the proxy replaces the real key when it comes back in the other direction, so the attacker would have to find an endpoint that does some kind of reversible transformation on the value in the response to disguise it.
It seems safer and simpler to, as others have mentioned, have a proxy that knows more about the context add the secrets to the requests. But maybe I've misunderstood their placeholder solution or maybe it's more clever than I'm giving it credit for.
It doesn't prevent bad code from USING those secrets to do nasty things, but it does at least make it impossible for them to steal the secret permanently.
Kind of like how XSS attacks can't read httpOnly cookies but they can generally still cause fetch() requests that can take actions using those cookies.
We had this same challenge in our own app builder, we ended up creating an internal LLM proxy with per-sandbox virtual keys (which the proxy maps to the real key + calculates per-sandbox usage), so even if the sandbox leaks its key it doesn't impact anything else.
@deno team, how do secrets work for things like connecting to DBs over a tcp connection? The header find+replace won't work there, I assume. Is the plan to add some sort of vault capability?
Same idea with more languages on OCI. I believe they have something even better in the works, that bundles a bunch of things you want in an "env" and lets you pass that around as a single "pointer"
"Over the past year, we’ve seen a shift in what Deno Deploy customers are building: platforms where users generate code with LLMs, and that code runs immediately without review. That code frequently calls LLMs itself, which means it needs API keys and network access.
This isn’t the traditional “run untrusted plugins” problem. It’s deeper: LLM-generated code, calling external APIs with real credentials, without human review. Sandboxing the compute isn’t enough. You need to control network egress and protect secrets from exfiltration.
Deno Sandbox provides both. And when the code is ready, you can deploy it directly to Deno Deploy without rebuilding."
I am so confused at how this is supposed to work. If the code, running in whatever language, does any sort of transform with the key that it thinks it has, doesnt this break? E.g. OAuth 1 signatures, JWTs, HMACs...
Now that I think further, doesnt this also potentially break HTTP semantics? E.g. if the key is part of the payload, then a data.replace(fake_key, real_key) can change the Content Length without actually updating the Content-Length header, right?
Lastly, this still doesnt protect you from other sorts of malicious attacks (e.g. 'DROP TABLE Users;')...Right? This seems like a mitigation, but hardly enough to feel comfortable giving an LLM direct access to prod, no?
My understanding is that it only surfaces the real keys when the request is actually sent under the hood, and doesn't make it available to the code itself, so that LLMs aren't able to query the key values. They have placeholder values for what seems to be obfuscation purposes, so that the LLM receives a fake value if it tries, which would help with stuff like prompt injection since that value is useless.
Unfortunately there's no other way to make money. If you're 100% liberally licensed, you just get copied. AWS/GCP clone your product, offer the same offering, and they take all the money.
It sucks that there isn't a middle ground. I don't want to have to build castles in another person's sandbox. I'd trust it if they gave me the keys to do the same. I know I don't have time to do that, but I want the peace of mind.
Secret placeholders seems like a good design decision.
So many sandbox products these days though. What are people using in production and what should one know about this space? There's Modal, Daytona, Fly, Cloudflare, Deno, etc
What happens if we use Claude Pro or Max plans on them ? It’ll always be a different IP connecting and we might get banned from Anthropic as they think we’re different users
For what it's worth, I do this from about 50 different IPs and have had no issues. I think their heuristics are more about confirming "a human is driving this" and rejecting "this is something abusing tokens for API access".
As a bit of an aside, I've gotten back into deno after seeing bun get bought out by an AI company.
I really like it. Startup times are now better than node (if not as good as bun). And being able to put your whole "project" in a single file that grabs dependencies from URLs reduces friction a surprising amount compared to having to have a whole directory with package.json, package-lock.json, etc.
It's basically my "need to whip up a small thing" environment of choice now.
Well, this is the hard part, but the idea is that if you're working with both untrusted inputs and private data/resources, then your agent is susceptible to the "lethal trifecta"[0], and you should be extremely limiting in its ability to have external network access. I would suggest starting with nothing beyond the single AI provider you're using, and only add additional domains if you are certain you trust them and can't do without them.
See also Sprites (https://news.ycombinator.com/item?id=46557825) which I've been using and really enjoying. There are some key architecture differences between the two, but very similar surface area. It'll be interesting to see if ephemeral + snapshots can be as convenient as stateful with cloning/forking (which hasn't actually dropped yet, although the fly team say it's coming).
Will give these a try. These are exciting times, it's never been a better time to build side projects :)
We recently built our own sandbox environment backed by firecracker and go. It works great.
For data residency, i.e. making sure the service is EU bound, there is basically no other way. We can move the service anywhere we can get hardware virtualisation.
As for the situation with credentials, our method is to generate CLIs on the fly and expose them to the LLMs and then they can shell script them whichever way they want. The CLIs only contain scoped credentials to our API which handles oauth and other forms of authentication transparently. The agent does not need to know anything about this. All they know is that they can do
$ some-skillset search-gmail-messages -q "emails from Adrian"
In our own experiments we find that this approach works better and it just makes sense given most of the latest models are trained as coding assistants. They just love bash, so give them the tools.
Not sure if anyone from the deno team is monitoring this forum, but I was trying to stand up a dev-base snapshot and pretty quickly ran into a wall. Is it not currently possible to create a bootable volume from the CLI? https://docs.deno.com/sandbox/volumes/#creating-a-snapshot has an example for the js API, but the CLI equivalent isn't specifying --from and the latest verson of the deno CLI installed fresh from deno.land has no --from option. Is the CLI behind, here? Or is the argument provided some other way?
Not mentioned, but something I would like/expect would be to have some kind of editor integration... VS Code remote extensions, as an example even... You can be in a remote code server with your local editor and terminal tab(s) within said editor on the remote system.
I realize this is using other interactions, but I'd like a bit more observability than just the isolated environment... I'm not even saying VS Code specifically, but something similar at the least.
If you can create a deno sandbox from a deno sandbox, you could create an almost unkillable service that jumps from one sandbox to the next. Very handy for malicious purposes. ;-)
This is, in fact, the biggest problem to solve with any kind of compute platform. And when you suddenly launch things really, really fast, it gets harder.
Fun! Our work from 10 years ago introduced the secrets protection technique being used in Deno: https://www.earlence.com/assets/papers/flowfence_sec16.pdf and fly's tokenizer. We called it "opaque computation" and it did a lot more than secrets protection.
What's with the pricing of these sandbox offerings recently? I assume just trying to milk the AI trend.
It's about 10x what a normal VM would cost at a more affordable hoster. So you better have it run only 10% of the time or you're just paying more for something more constrained.
A full month of runtime would be about $50 bucks for a 2vCPU 1GB RAM 10GB SSD mini-VM that you can get easily for $5 elsewhere.
Love their network filtering, however it definitely lacks some capabilities (like the ability to do direct TCP connections to Postgres, or direct IP connections.
Is this Extism, but running as a service? https://extism.org/ It seems to me that a key feature of Extism is host functions (which can be called from the sandbox). But maybe I'm not comparing apples to apples?
Where's the real value for devs in something like this? Hasn't everyone already built this for themselves in the past 2 years? I'm not trying to sound cheeky or poo poo the product, just surprised if this is a thing. I can never read what's useful by gut anymore, I guess.
Sandboxes with the right persistence and http routing make excellent dev servers. I have about a million dev servers I just use from whatever computer / phone I happen to be using.
It's really useful to just turn a computer on, use a disk, and then plop its url in the browser.
I currently do one computer per project. I don't even put them in git anymore. I have an MDM server running to manage my kids' phones, a "help me reply to all the people" computer that reads everything I'm supposed to read, a dumb game I play with my son, a family todo list no one uses but me, etc, etc.
Immediate computers have made side projects a lot more fun again. And the nice thing is, they cost nothing when I forget about them.
> Hasn't everyone already built this for themselves in the past 2 years?
The short answer is no. And more so, I think that "Everyone I know in my milieu already built this for themselves, but the wider industry isn't talking about it" is actually an excellent idea generator for a new product.
> The real key materializes only when the sandbox makes an outbound request to an approved host. If prompt-injected code tries to exfiltrate that placeholder to evil.com? Useless.
I just run a local microVM. I built a small CLI that wraps lima to make my life easier. With a few commands I have a VM running locally with all batteries included (CC/Codex, ssh, packages I need, ...). With this I'm not saying Deno or Docker sandboxes are useless.
Just wrapped up my own module for this. Remixed my worktree workflow with a lima wrapper. I wanted to go head first to giving Claude Code full autonomy but realized capability and prevention need to go hand in hand
Next step for me is creating a secrets proxy like credit card numbers are tokenized to remove risk of exfiltrating credentials.
Edit: It’s nice that Deno Sandbox already does this. Will check it out.
If you achieve arbitrary code execution in the sandbox, I think you could pretty easily exfiltrate the openai key by using the openai code interpreter, and asking it to send the key to a url of your choice.
Ignoring the fact that most of the blog post is written by an LLM, I like that they provide a python sdk. I dont believe vercel does for their sandbox product.
It’s a cloud service - so you can call out to it from anywhere you want. Just don’t ship your credentials in the app itself, and instead authenticate via a server you control.
I feel like this is a bot account. Or at least, everything is AI generated. No posts at all since the account was created in 2024 and now suddenly in the past 24 hours there's dozens of detailed comments that all sort of follow the same pattern/vibe.
simonw|27 days ago
koakuma-chan|27 days ago
rdhyee|26 days ago
Hit a snag: Sprites appear network-isolated from Fly's 6PN private mesh (fdf:: prefix inside the Sprite, not fdaa::; no .internal DNS). So a Tokenizer on a Fly Machine isn't directly reachable without public internet.
Asked on the Fly forum: https://community.fly.io/t/can-sprites-reach-internal-fly-se...
@tptacek's point upthread about controlling not just hosts but request structure is well taken - for AI agent sandboxing you'd want tight scoping on what the proxy will forward.
ChatGPTBanger|27 days ago
[deleted]
emschwartz|27 days ago
> The real key materializes only when the sandbox makes an outbound request to an approved host. If prompt-injected code tries to exfiltrate that placeholder to evil.com? Useless.
That seems clever.
motrm|27 days ago
It's a little HTTP proxy that your application can route requests through, and the proxy is what handles adding the API keys or whatnot to the request to the service, rather than your application, something like this for example:
Application -> tokenizer -> Stripe
The secrets for the third party service should in theory then be safe should there be some leak or compromise of the application since it doesn't know the actual secrets itself.
Cool idea!
ptx|27 days ago
Presumably the proxy replaces any occurrence of the placeholder with the real key, without knowing anything about the context in which the key is used, right? Because if it knew that the key was to be used for e.g. HTTP basic auth, it could just be added by the proxy without using a placeholder.
So all the attacker would have to do then is find and endpoint (on one of the approved hosts, granted) that echoes back the value, e.g. "What is your name?" -> "Hello $name!", right?
But probably the proxy replaces the real key when it comes back in the other direction, so the attacker would have to find an endpoint that does some kind of reversible transformation on the value in the response to disguise it.
It seems safer and simpler to, as others have mentioned, have a proxy that knows more about the context add the secrets to the requests. But maybe I've misunderstood their placeholder solution or maybe it's more clever than I'm giving it credit for.
simonw|27 days ago
Kind of like how XSS attacks can't read httpOnly cookies but they can generally still cause fetch() requests that can take actions using those cookies.
Tepix|27 days ago
artahian|27 days ago
jkelleyrtp|27 days ago
perfmode|27 days ago
unknown|27 days ago
[deleted]
CuriouslyC|27 days ago
verdverm|27 days ago
Same idea with more languages on OCI. I believe they have something even better in the works, that bundles a bunch of things you want in an "env" and lets you pass that around as a single "pointer"
I use this here, which eventually becomes the sandbox my agent operates in: https://github.com/hofstadter-io/hof/blob/_next/.veg/contain...
linolevan|27 days ago
Had some previous discussion that may be interesting on https://news.ycombinator.com/item?id=46595393
syabro|27 days ago
rfoo|27 days ago
> via an outbound proxy similar to coder/httpjail
looks like AI slop ware :( I hope they didn't actually run it.
johnspurlock|27 days ago
This isn’t the traditional “run untrusted plugins” problem. It’s deeper: LLM-generated code, calling external APIs with real credentials, without human review. Sandboxing the compute isn’t enough. You need to control network egress and protect secrets from exfiltration.
Deno Sandbox provides both. And when the code is ready, you can deploy it directly to Deno Deploy without rebuilding."
twosdai|27 days ago
unknown|27 days ago
[deleted]
chacham15|27 days ago
Now that I think further, doesnt this also potentially break HTTP semantics? E.g. if the key is part of the payload, then a data.replace(fake_key, real_key) can change the Content Length without actually updating the Content-Length header, right?
Lastly, this still doesnt protect you from other sorts of malicious attacks (e.g. 'DROP TABLE Users;')...Right? This seems like a mitigation, but hardly enough to feel comfortable giving an LLM direct access to prod, no?
nusl|27 days ago
freakynit|27 days ago
A 2 vCPU, 4GB Ram and 40GB Disk instance on Hetzner cost 4.13 USD.
The same here is:
$127.72 without pro plan, and $108.72 with pro plan.
This means to break even, I can only use this for 4.13/127.72*730 = 23.6 hours every month, or, less than an hour daily.
nusl|27 days ago
zenmac|27 days ago
The real question is can the microVMs run in just plain old linux, self-hosted.
echelon|27 days ago
Unfortunately there's no other way to make money. If you're 100% liberally licensed, you just get copied. AWS/GCP clone your product, offer the same offering, and they take all the money.
It sucks that there isn't a middle ground. I don't want to have to build castles in another person's sandbox. I'd trust it if they gave me the keys to do the same. I know I don't have time to do that, but I want the peace of mind.
koolala|27 days ago
yakkomajuri|27 days ago
So many sandbox products these days though. What are people using in production and what should one know about this space? There's Modal, Daytona, Fly, Cloudflare, Deno, etc
ATechGuy|27 days ago
ushakov|27 days ago
e12e|27 days ago
Looks like the main innovation here is linking outbound traffic to a host with dynamic variables - could that be added to deno itself?
ttoinou|27 days ago
Why limit the lifetime on 30 mins ?
lucacasonato|27 days ago
mrkurt|27 days ago
paxys|27 days ago
LAC-Tech|27 days ago
I really like it. Startup times are now better than node (if not as good as bun). And being able to put your whole "project" in a single file that grabs dependencies from URLs reduces friction a surprising amount compared to having to have a whole directory with package.json, package-lock.json, etc.
It's basically my "need to whip up a small thing" environment of choice now.
ATechGuy|27 days ago
How to know what domains to allow? The agent behavior is not predefined.
CuriouslyC|27 days ago
falcor84|27 days ago
[0] https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
nihakue|27 days ago
Will give these a try. These are exciting times, it's never been a better time to build side projects :)
tomComb|27 days ago
alooPotato|27 days ago
_pdp_|27 days ago
We recently built our own sandbox environment backed by firecracker and go. It works great.
For data residency, i.e. making sure the service is EU bound, there is basically no other way. We can move the service anywhere we can get hardware virtualisation.
As for the situation with credentials, our method is to generate CLIs on the fly and expose them to the LLMs and then they can shell script them whichever way they want. The CLIs only contain scoped credentials to our API which handles oauth and other forms of authentication transparently. The agent does not need to know anything about this. All they know is that they can do
$ some-skillset search-gmail-messages -q "emails from Adrian"
In our own experiments we find that this approach works better and it just makes sense given most of the latest models are trained as coding assistants. They just love bash, so give them the tools.
nihakue|27 days ago
crowlKats|26 days ago
tracker1|27 days ago
I realize this is using other interactions, but I'd like a bit more observability than just the isolated environment... I'm not even saying VS Code specifically, but something similar at the least.
Tepix|27 days ago
Just an idea…
mrkurt|27 days ago
runarberg|27 days ago
EGreg|27 days ago
It uses web workers on a web browser. So is this Deno Sandbox like that, but for server? I think Node has worker threads.
earlence|26 days ago
angristan|25 days ago
eis|27 days ago
It's about 10x what a normal VM would cost at a more affordable hoster. So you better have it run only 10% of the time or you're just paying more for something more constrained.
A full month of runtime would be about $50 bucks for a 2vCPU 1GB RAM 10GB SSD mini-VM that you can get easily for $5 elsewhere.
freakynit|27 days ago
Mentioned the same in this comment as well: https://news.ycombinator.com/item?id=46881920
dangoodmanUT|27 days ago
Those limitations from other tools was exactly why I made https://github.com/danthegoodman1/netfence for our agents
regisb|26 days ago
mrpandas|27 days ago
slibhb|27 days ago
Even if this was true, "everyone building X independently" is evidence that one company should definitely build X and sell it to everyone
mrkurt|27 days ago
It's really useful to just turn a computer on, use a disk, and then plop its url in the browser.
I currently do one computer per project. I don't even put them in git anymore. I have an MDM server running to manage my kids' phones, a "help me reply to all the people" computer that reads everything I'm supposed to read, a dumb game I play with my son, a family todo list no one uses but me, etc, etc.
Immediate computers have made side projects a lot more fun again. And the nice thing is, they cost nothing when I forget about them.
falcor84|27 days ago
The short answer is no. And more so, I think that "Everyone I know in my milieu already built this for themselves, but the wider industry isn't talking about it" is actually an excellent idea generator for a new product.
drewbitt|27 days ago
swyx|24 days ago
pretty smart. why isn't this the norm?
sibellavia|27 days ago
jrvarela56|27 days ago
Next step for me is creating a secrets proxy like credit card numbers are tokenized to remove risk of exfiltrating credentials.
Edit: It’s nice that Deno Sandbox already does this. Will check it out.
arjan_sch|27 days ago
snehesht|27 days ago
PeterStuer|27 days ago
Can you configure Demo Sandbox to run on a self hosted installation of Deno Deploy (deployd), or is this a SaaS only offering?
wsgeorge|27 days ago
unknown|27 days ago
[deleted]
WatchDog|27 days ago
ianberdin|27 days ago
jonthepirate|27 days ago
Bnjoroge|27 days ago
GreenWatermelon|21 days ago
MillionOClock|27 days ago
lucacasonato|27 days ago
unknown|27 days ago
[deleted]
latexr|27 days ago
That website does exist. It may hurt your eyes.
lucacasonato|27 days ago
eric-burel|27 days ago
bopbopbop7|27 days ago
andrewmcwatters|27 days ago
[deleted]
Soerensen|27 days ago
[deleted]
rob|27 days ago