Firecrackervm with proxy?
Deno Sandbox
11–20 of 185 posts
Re: Deno Sandbox
#12> 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.
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!
Re: Deno Sandbox
#13> 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...
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.
Re: Deno Sandbox
#14Earlier quoted context omitted.
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.
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.
Re: Deno Sandbox
#15Note 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/
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)
Re: Deno Sandbox
#16If 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…
Re: Deno Sandbox
#17See 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 :)
Re: Deno Sandbox
#18> 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.
It must be performing a man-in-the-middle for HTTPS requests. That makes it more difficult to do things like certificate pinning.
Re: Deno Sandbox
#19> 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.
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...
Re: Deno Sandbox
#20> 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.
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…
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.