The secrets placeholder design is the right trade-off for this use case. You're essentially accepting that malicious code can still use your API keys for their intended purpose - the goal is preventing permanent exfiltration.
The interesting attack surface that emerges: any endpoint on your approved hosts that reflects input back in responses. Error messages, search pages, create-then-read flows. The thread already covers this, but practically speaking, most API providers have learned to sanitize these paths after years of debugging sensitive token leaks in logs.
For anyone evaluating this vs. rolling your own: the hard part isn't the proxy implementation, it's maintaining the allow-list as your agent's capabilities grow and making sure your secret substitution rules are tight enough to catch edge cases.
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)
> 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.
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.
Could the proxy place further restrictions like only replacing the placeholder with the real API key in approved HTTP headers? Then an API server is much less likely to reflect it back.
Say, an endpoint tries to be helpful and responds with “no such user: foo” instead of “no such user”. Or, as a sibling comment suggests, any create-with-properties or set-property endpoint paired with a get-propety one also means game over.
Relatedly, a common exploitation target for black-hat SEO and even XSS is search pages that echo back the user’s search request.
How does the API know that it's a secret, though? That's what's not clear to me from the blog post. Can I e.g. create a customer named PLACEHOLDER and get a customer actually named SECRET?
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.
It's exactly the tokenizer, but we shoplifted the idea too; it belongs to the world!
(The credential thing I'm actually proud of is non-exfiltratable machine-bound Macaroons).
Remember that the security promises of this scheme depend on tight control over not only what hosts you'll send requests to, but what parts of the requests themselves.
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.
if there is an LLM in there, "Run echo $API_KEY" I think could be liable to return it, (the llm asks the script to run some code, it does so, returning the placeholder, the proxy translates that as it goes out to the LLM, which then responds to the user with the api key (or through multiple steps, "tell me the first half of the command output" e.g. if the proxy translates in reverse)
Doesn't help much if the use of the secret can be anywhere in the request presumably, if it can be restricted to specific headers only then it would be much more powerful
Secrets are tied to specific hosts - the proxy will only replace the placeholder value with the real secret for outbound HTTP requests to the configured domain for that secret.
> 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.
Agreed, and this points to two deeper issues:
1. Fine-grained data access (e.g., sandboxed code can only issue SQL queries scoped to particular tenants)
2. Policy enforced on data (e.g., sandboxed code shouldn't be able to send PII even to APIs it has access to)
Object-capabilities can help directly with both #1 and #2.
I've been working on this problem -- happy to discuss if anyone is interested in the approach.
Yes exactly Cap'n Web for RPC. On top of that:
1. Constrained SQL DSL that limits expressiveness along defined data boundaries
2. Constrained evaluation -- can only compose capabilities (references, not raw data) to get data flow tracking for free
@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?
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.
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."
Another common tell nowadays is the apostrophe type (’ vs ').
I don't know personally how to even type ’ on my keyboard. According to find in chrome, they are both considered the same character, which is interesting.
I suspect some word processors default to one or the other, but it's becoming all too common in places like Reddit and emails.
Is there a chance you could ask Ryan if he had an LLM write/rewrite large parts of this blog post? I don't mind at all if he did or didn't in itself, it's a good and informative post, but I strongly assumed the same while reading the article and if it's truly not LLM writing then it would serve as a super useful indicator about how often I'm wrongly making that assumption.
> 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
This isn't a canonical use of a colon (and the dependent clause isn't even grammatical)!
> This isn’t the traditional “run untrusted plugins” problem. It’s deeper: LLM-generated code, calling external APIs with real credentials, without human review.
Another colon-offset dependent paired with the classic, "This isn't X. It's Y," that we've all grown to recognize.
> Sandboxing the compute isn’t enough. You need to control network egress and protect secrets from exfiltration.
More of the latter—this sort of thing was quite rare outside of a specific rhetorical goal of getting your reader excited about what's to come. LLMs (mis)use it everywhere.
> Deno Sandbox provides both. And when the code is ready, you can deploy it directly to Deno Deploy without rebuilding.
Good writers vary sentence length, but it's also a rhetorical strategy that LLMs use indiscriminately with no dramatic goal or tension to relieve.
'And' at the beginning of sentences is another LLM-tell.
Can it be that after reading so many LLM texts we will just subconciously follow the style, because that's what we are used to?
No idea how this works for native English speakers, but I know that I lack my own writing style and it is just a pseudo-llm mix of Reddit/irc/technical documentation, as those were the places where I learned written English
Yes, I think you're right—I have a hard time imagining how we avoid such an outcome. If it matters to you, my suggestion is to read as widely as you're able to. That way you can at least recognize which constructions are more/less associated with an LLM.
When I was first working toward this, I found the LA Review of Books and the London Review of Books to be helpful examples of longform, erudite writing. (edit - also recommend the old standards of The New Yorker and The Atlantic; I just wanted to highlight options with free articles).
I also recommend reading George Orwell's essay Politics and the English Language.
Yeah, I feel like this is really the smoking gun. Because it's not actually deeper? An LLM running untrusted code is not some additional level of security violation above a plugin running untrusted code. I feel like the most annoying part of "It's not X, it's Y" is that agents often say "It's not X, it's (slightly rephrased X)", lol, but it takes like 30 seconds to work that out.
It's unfortunate that, given the entire corpus of human writing, LLMs have seemingly been fine-tuned to reproduce terrible ad copy from old editions of National Geographic.
(Yes, I split the infinitive there, but I hate that rule.)
As someone that has a habit of maybe overusing em dashes to my detriment, often times, and just something that I try to be mindful of in general. This whole thing of assuming that it's AI generated now is a huge blow. It feels like a personal attack.
"—" has always seemed like an particularly weak/unreliable signal to me, if it makes you feel any better. Triply so in any content one would expect smart quotes or formatted lists, but even in general.
RIP anyone who had a penchant for "not just x, but y" though. It's not even a go-to wording for me and I feel the need to rewrite it any time I type it out of fear it'll sound like LLMs.
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
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.
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".
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.
Love their network filtering, however it definitely lacks some capabilities (like the ability to do direct TCP connections to Postgres, or direct IP connections.
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.
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 :)
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.
Not sure what your customers look like, but I'd for one also be fine with "fair source" licenses (there are several - fair source, fair code, Defold license, etc.)
These give customers 100% control but keep Amazon, Google, and other cling-on folks like WP Engine from reselling your work. It avoids the Docker, Elasticsearch, Redis fate.
"OSI" is a submarine from big tech hyperscalers that mostly take. We should have gone full Stallman, but fair source is a push back against big tech.
when we were starting out we figured there was no solution that would satisfy our requirements for running untrusted code. so we had to build our own.
the reason we open-sourced this is because we want everyone to be able to run our Sandboxes - in contrast to the majority of our competitors who’s goal is to lock you in to their offering.
with open-source you have the choice, and luckily Manus, Perplexity, Nvidia choose us for their workloads.
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.
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.
You will be astonished to know it'a a whole lot of sqlite.
Everything I want to pay attention to gets a token, the server goes and looks for stuff in the api, and seeds local sqlites. If possible, it listens for webhooks to stay fresh.
Mostly the interface is Claude code. I have a web view that gives me some idea of volume, and then I just chat at Claude code to have it see what's going on. It does this by querying and cross referencing sqlite dbs.
I will have claude code send/post a response for me, but I still write them like a meatsack.
It's effectively: long lived HTTP server, sqlite, and then Claude skills for scripts that help it consistently do things based on my awful typing.
> 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.
In the last one year, we have seen several sandboxing wrappers around containers/VMs and they all target one use case AI agent code execution. Why? perhaps because devs are good at building (wrappers around VMs) and chase the AI hype. But how are these different and what value do they offer over VMs? Sounds like a tarpit idea, tbh.
Here's my list of code execution sandboxing agents launched in the last year alone: E2B, AIO Sandbox, Sandboxer, AgentSphere, Yolobox, Exe.dev, yolo-cage, SkillFS, ERA Jazzberry Computer, Vibekit, Daytona, Modal, Cognitora, YepCode, Run Compute, CLI Fence, Landrun, Sprites, pctx-sandbox, pctx Sandbox, Agent SDK, Lima-devbox, OpenServ, Browser Agent Playground, Flintlock Agent, Quickstart, Bouvet Sandbox, Arrakis, Cellmate (ceLLMate), AgentFence, Tasker, DenoSandbox, Capsule (WASM-based), Volant, Nono, NetFence
I'm not saying sandboxes are not needed, I'm saying VMs/containers already provide the core tech and it's easy to DIY a sandbox. Would love to understand what value E2B offers over VMs?
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.
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.
The secrets placeholder design is the right trade-off for this use case. You're essentially accepting that malicious code can still use your API keys for their intended purpose - the goal is preventing permanent exfiltration.
The interesting attack surface that emerges: any endpoint on your approved hosts that reflects input back in responses. Error messages, search pages, create-then-read flows. The thread already covers this, but practically speaking, most API providers have learned to sanitize these paths after years of debugging sensitive token leaks in logs.
For anyone evaluating this vs. rolling your own: the hard part isn't the proxy implementation, it's maintaining the allow-list as your agent's capabilities grow and making sure your secret substitution rules are tight enough to catch edge cases.
Note that you don't need to use Deno or JavaScript at all to use this product. Here's their Python client SDK: https://pypi.org/project/deno-sandbox/
Looks like the API protocol itself uses websockets: https://tools.simonwillison.net/zip-wheel-explorer?package=d...> 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.
That seems clever.
Yes... but...
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.
Could the proxy place further restrictions like only replacing the placeholder with the real API key in approved HTTP headers? Then an API server is much less likely to reflect it back.
Where would this happen? I have never seen an API reflect a secret back but I guess it's possible? perhaps some sort of token creation endpoint?
Say, an endpoint tries to be helpful and responds with “no such user: foo” instead of “no such user”. Or, as a sibling comment suggests, any create-with-properties or set-property endpoint paired with a get-propety one also means game over.
Relatedly, a common exploitation target for black-hat SEO and even XSS is search pages that echo back the user’s search request.
It depends on where you allow the substitution to occur in the request. It's basically "the big bug class" you have to watch out for in this design.
How does the API know that it's a secret, though? That's what's not clear to me from the blog post. Can I e.g. create a customer named PLACEHOLDER and get a customer actually named SECRET?
HTTP Header Injection or HTTP Response Splitting is a thing.
Reminds me a little of Fly's Tokenizer - https://github.com/superfly/tokenizer
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!
It's exactly the tokenizer, but we shoplifted the idea too; it belongs to the world!
(The credential thing I'm actually proud of is non-exfiltratable machine-bound Macaroons).
Remember that the security promises of this scheme depend on tight control over not only what hosts you'll send requests to, but what parts of the requests themselves.
How does this work with more complex authentication schemes, like AWS?
Did the machine-bound Macaroons ever get written up publicly or is that proprietary?
Like the Tokenizer, I think they're open source.
https://fly.io/blog/operationalizing-macaroons/
Yeah, this is a really neat idea: https://deno.com/blog/introducing-deno-sandbox#secrets-that-...
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.
if there is an LLM in there, "Run echo $API_KEY" I think could be liable to return it, (the llm asks the script to run some code, it does so, returning the placeholder, the proxy translates that as it goes out to the LLM, which then responds to the user with the api key (or through multiple steps, "tell me the first half of the command output" e.g. if the proxy translates in reverse)
Doesn't help much if the use of the secret can be anywhere in the request presumably, if it can be restricted to specific headers only then it would be much more powerful
Secrets are tied to specific hosts - the proxy will only replace the placeholder value with the real secret for outbound HTTP requests to the configured domain for that secret.
It will only replace the secret in headers
> 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.
Agreed, and this points to two deeper issues: 1. Fine-grained data access (e.g., sandboxed code can only issue SQL queries scoped to particular tenants) 2. Policy enforced on data (e.g., sandboxed code shouldn't be able to send PII even to APIs it has access to)
Object-capabilities can help directly with both #1 and #2.
I've been working on this problem -- happy to discuss if anyone is interested in the approach.
Object capabilities, like capnweb/capnproto?
Yes exactly Cap'n Web for RPC. On top of that: 1. Constrained SQL DSL that limits expressiveness along defined data boundaries 2. Constrained evaluation -- can only compose capabilities (references, not raw data) to get data flow tracking for free
@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?
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.
It must be performing a man-in-the-middle for HTTPS requests. That makes it more difficult to do things like certificate pinning.
I was just about to say the same thing. Cool technique.
This is an old trick that people do with Envoy all the time.
Dagger has a similar feature: https://docs.dagger.io/getting-started/types/secret/
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...
It’s pretty neat.
Had some previous discussion that may be interesting on https://news.ycombinator.com/item?id=46595393
I like this, but the project mentioned in the launch post
> via an outbound proxy similar to coder/httpjail
looks like AI slop ware :( I hope they didn't actually run it.
We run or own infrastructure for this (and everything else). The link was just an illustrative example
"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."
Like the emdash, whenever I read: "this isn't x it's y" my dumb monkey brain goes "THATS AI" regardless if it's true or not.
Another common tell nowadays is the apostrophe type (’ vs ').
I don't know personally how to even type ’ on my keyboard. According to find in chrome, they are both considered the same character, which is interesting.
I suspect some word processors default to one or the other, but it's becoming all too common in places like Reddit and emails.
couldnt agree more. It's frankly very fatiguing
I can confirm Ryan is a real human :)
Is there a chance you could ask Ryan if he had an LLM write/rewrite large parts of this blog post? I don't mind at all if he did or didn't in itself, it's a good and informative post, but I strongly assumed the same while reading the article and if it's truly not LLM writing then it would serve as a super useful indicator about how often I'm wrongly making that assumption.
There are multiple signs of LLM-speak:
> 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
This isn't a canonical use of a colon (and the dependent clause isn't even grammatical)!
> This isn’t the traditional “run untrusted plugins” problem. It’s deeper: LLM-generated code, calling external APIs with real credentials, without human review.
Another colon-offset dependent paired with the classic, "This isn't X. It's Y," that we've all grown to recognize.
> Sandboxing the compute isn’t enough. You need to control network egress and protect secrets from exfiltration.
More of the latter—this sort of thing was quite rare outside of a specific rhetorical goal of getting your reader excited about what's to come. LLMs (mis)use it everywhere.
> Deno Sandbox provides both. And when the code is ready, you can deploy it directly to Deno Deploy without rebuilding.
Good writers vary sentence length, but it's also a rhetorical strategy that LLMs use indiscriminately with no dramatic goal or tension to relieve.
'And' at the beginning of sentences is another LLM-tell.
Can it be that after reading so many LLM texts we will just subconciously follow the style, because that's what we are used to? No idea how this works for native English speakers, but I know that I lack my own writing style and it is just a pseudo-llm mix of Reddit/irc/technical documentation, as those were the places where I learned written English
Yes, I think you're right—I have a hard time imagining how we avoid such an outcome. If it matters to you, my suggestion is to read as widely as you're able to. That way you can at least recognize which constructions are more/less associated with an LLM.
When I was first working toward this, I found the LA Review of Books and the London Review of Books to be helpful examples of longform, erudite writing. (edit - also recommend the old standards of The New Yorker and The Atlantic; I just wanted to highlight options with free articles).
I also recommend reading George Orwell's essay Politics and the English Language.
> It’s deeper: LLM-generated code, calling external APIs with real credentials, without human review.
This also follows the rule of 3s, which LLMs love, there ya go.
Yeah, I feel like this is really the smoking gun. Because it's not actually deeper? An LLM running untrusted code is not some additional level of security violation above a plugin running untrusted code. I feel like the most annoying part of "It's not X, it's Y" is that agents often say "It's not X, it's (slightly rephrased X)", lol, but it takes like 30 seconds to work that out.
It's not just different way of saying something, it's a whole new way to express an idea.
It's unfortunate that, given the entire corpus of human writing, LLMs have seemingly been fine-tuned to reproduce terrible ad copy from old editions of National Geographic.
(Yes, I split the infinitive there, but I hate that rule.)
As someone that has a habit of maybe overusing em dashes to my detriment, often times, and just something that I try to be mindful of in general. This whole thing of assuming that it's AI generated now is a huge blow. It feels like a personal attack.
"—" has always seemed like an particularly weak/unreliable signal to me, if it makes you feel any better. Triply so in any content one would expect smart quotes or formatted lists, but even in general.
RIP anyone who had a penchant for "not just x, but y" though. It's not even a go-to wording for me and I feel the need to rewrite it any time I type it out of fear it'll sound like LLMs.
> RIP anyone who had a penchant for "not just x, but y" though
I felt that. They didn’t just kidnap my boy; they massacred him.
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
These are all wrappers around VMs. You could DIY these easily by using EC2/serverless/GCP SDKs.
Factory, Nvidia, Perplexity and Manus are using E2B in production - we ran more than 200 million Sandboxes for our customers
The free plan makes me want to use it like Glitch. But every free service like this ever has been burned...
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.
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
Why limit the lifetime on 30 mins ?
We'll increase the lifetime in the next weeks - just some tech internally that needs to be adjusted first.
What's the use case for this? Trying to get raw API access through a monthly plan? Or something else?
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".
All the time with the same computer ? Maybe it is looking at others metadata, for example local MAC addresses
All the time with a bunch of different sandboxes.
> allowNet: ["api.openai.com", "*.anthropic.com"],
How to know what domains to allow? The agent behavior is not predefined.
The idea is to gate automatic secret replacement to specific hosts that would use them legitimately to avoid exfiltration.
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.
[0] https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
Love their network filtering, however it definitely lacks some capabilities (like the ability to do direct TCP connections to Postgres, or direct IP connections.
Those limitations from other tools was exactly why I made https://github.com/danthegoodman1/netfence for our agents
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.
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 :)
Yes, sprites looks great too – would certainly be interested in a comparison.
what are the key architectural differences?
>Deno Sandbox gives you lightweight Linux microVMs (running in the Deno Deploy cloud)
The real question is can the microVMs run in just plain old linux, self-hosted.
Everyone wants to lock you in.
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.
we have 100% open-source Sandboxes at E2B
git: https://github.com/e2b-dev/infra
wiki: https://deepwiki.com/e2b-dev/infra
This is what I like to see!
Not sure what your customers look like, but I'd for one also be fine with "fair source" licenses (there are several - fair source, fair code, Defold license, etc.)
These give customers 100% control but keep Amazon, Google, and other cling-on folks like WP Engine from reselling your work. It avoids the Docker, Elasticsearch, Redis fate.
"OSI" is a submarine from big tech hyperscalers that mostly take. We should have gone full Stallman, but fair source is a push back against big tech.
we aren’t worried about that.
when we were starting out we figured there was no solution that would satisfy our requirements for running untrusted code. so we had to build our own.
the reason we open-sourced this is because we want everyone to be able to run our Sandboxes - in contrast to the majority of our competitors who’s goal is to lock you in to their offering.
with open-source you have the choice, and luckily Manus, Perplexity, Nvidia choose us for their workloads.
(opinions my own)
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. ;-)
Just an idea…
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.
Isn’t that basically how zip-bombs work?
Not really, no
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.
> Hasn't everyone already built this for themselves in the past 2 years?
Even if this was true, "everyone building X independently" is evidence that one company should definitely build X and sell it to everyone
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.
I'd love to know more about that "help me reply to all the people" one! I definitely need that.
You will be astonished to know it'a a whole lot of sqlite.
Everything I want to pay attention to gets a token, the server goes and looks for stuff in the api, and seeds local sqlites. If possible, it listens for webhooks to stay fresh.
Mostly the interface is Claude code. I have a web view that gives me some idea of volume, and then I just chat at Claude code to have it see what's going on. It does this by querying and cross referencing sqlite dbs.
I will have claude code send/post a response for me, but I still write them like a meatsack.
It's effectively: long lived HTTP server, sqlite, and then Claude skills for scripts that help it consistently do things based on my awful typing.
> 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.
In the last one year, we have seen several sandboxing wrappers around containers/VMs and they all target one use case AI agent code execution. Why? perhaps because devs are good at building (wrappers around VMs) and chase the AI hype. But how are these different and what value do they offer over VMs? Sounds like a tarpit idea, tbh.
Here's my list of code execution sandboxing agents launched in the last year alone: E2B, AIO Sandbox, Sandboxer, AgentSphere, Yolobox, Exe.dev, yolo-cage, SkillFS, ERA Jazzberry Computer, Vibekit, Daytona, Modal, Cognitora, YepCode, Run Compute, CLI Fence, Landrun, Sprites, pctx-sandbox, pctx Sandbox, Agent SDK, Lima-devbox, OpenServ, Browser Agent Playground, Flintlock Agent, Quickstart, Bouvet Sandbox, Arrakis, Cellmate (ceLLMate), AgentFence, Tasker, DenoSandbox, Capsule (WASM-based), Volant, Nono, NetFence
don't forget runloop!
why? because there’s a huge market demand for Sandboxes. no one would be building this if no one would be buying.
disclaimer: i work at E2B
I'm not saying sandboxes are not needed, I'm saying VMs/containers already provide the core tech and it's easy to DIY a sandbox. Would love to understand what value E2B offers over VMs?
making a local sandbox using docker is easy, but making them work at high volume and low latency is hard
we offer secure cloud VMs that scale up to 100k concurrent instances or more.
the value we sell with our cloud is scale, while our Sandboxes are a commodity that we have proudly open-sourced
> we offer secure cloud VMs that scale up to 100k concurrent instances or more.
High scalability and VM isolation is what the Cloud (GCP/AWS, that E2B runs on) offers.
Has everyone really built their own microVMs? I don’t think so.
Saw quite bit on HN.
A quick search this popped up:
https://news.ycombinator.com/item?id=45486006
If we can spin up microVM so quickly, why bother with Docker or other containers at all?
I think a 413 commit repo took a bit of time.
That's just over one day worth of commits in a few friends' activity at this point. Thanks to Anthropic.
10 seconds is actually not that impressive. we spin up Sandboxes around 50-200ms at E2B
50/200 Gb free plus $0.5 / Gb out egress data seems expensive when scaling out.
Can this be used on iOS somehow? I am building a Swift app where this would be very useful but last time I checked I don't think it was possible.
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.
Looks promising. Any plans for a version that runs locally/self-host able?
Looks like the main innovation here is linking outbound traffic to a host with dynamic variables - could that be added to deno itself?
> evil.com
That website does exist. It may hurt your eyes.
We honestly should have just linked to oracle.com instead of evil.com
Firecrackervm with proxy?
seems it.
Can it be used to sandbox an AI agent, like replacing eg Cursor or Openclaw sandboxing system?
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.
We already have a pretty good sandbox in our platform: https://github.com/Qbix/Platform/blob/main/platform/plugins/...
It uses web workers on a web browser. So is this Deno Sandbox like that, but for server? I think Node has worker threads.
Now I see why he was on twitter saying that the era of coding is over and hyping up LLMs, to sell more shovels...