71–80 of 185 posts
Those limitations from other tools was exactly why I made https://github.com/danthegoodman1/netfence for our agents
Earlier quoted context omitted.
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?
the value we sell with our cloud is scale, while our Sandboxes are a commodity that we have proudly open-sourced
Earlier quoted context omitted.
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 API…
> 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.
Earlier quoted context omitted.
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?
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
High scalability and VM isolation is what the Cloud (GCP/AWS, that E2B runs on) offers.
> evil.com That website does exist. It may hurt your eyes.
> 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.
Yeah, this is a really neat idea: https://deno.com/blog/introducing-deno-sandbox#secrets-that-... await using sandbox = await Sandbox.create({ secrets: { OPENAI_API_KEY: { hosts: ["api.openai.com"], value: process.env.OPENAI_API_KEY, }, }, }); await sandbox.sh`echo $OPENAI_API_KEY`; // DENO_SECRET_PLACEHOLDER_b14043a2f578cba75ebe04791e8e2c7d4002fd0c1f825e19... It doesn't prevent bad code from USING those secrets to d…
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
Earlier quoted context omitted.
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,…
we have 100% open-source Sandboxes at E2B git: https://github.com/e2b-dev/infra wiki: https://deepwiki.com/e2b-dev/infra
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.
> 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.
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.
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 ex…
> 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 e…