> 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.

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!

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.

@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.