zlacker

[return to "Deno Sandbox"]
1. emschw+Hb[view] [source] 2026-02-03 18:16:54
>>johnsp+(OP)
> 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.

◧◩
2. simonw+8e[view] [source] 2026-02-03 18:25:30
>>emschw+Hb
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 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.

◧◩◪
3. its-su+dQ[view] [source] 2026-02-03 21:10:09
>>simonw+8e
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

◧◩◪◨
4. simonw+b91[view] [source] 2026-02-03 22:49:28
>>its-su+dQ
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.
◧◩◪◨⬒
5. its-su+Uw1[view] [source] 2026-02-04 01:07:34
>>simonw+b91
which, if its the LLM asking for the result of the locally ran "echo $API_KEY", will be sent through that proxy, to the correct configured domain. (If it did it for request body, which apparently it doesn't (which was part of what I was wondering))
◧◩◪◨⬒⬓
6. Danger+jj3[view] [source] 2026-02-04 15:14:28
>>its-su+Uw1
The AI agent can run `echo $API_KEY` all it wants, but the value is only a placeholder which is useless outside the system, and only the proxy service which the agent cannot directly access, will replace the placeholder with the real value and return the result of the network call. Furthermore, the replacement will happen within the proxy service itself, it does not expose the replaced value to memory or files that the agent can access.

It's a bit like taking a prepaid voucher to a food truck window. The cashier receives the voucher, checks it against their list of valid vouchers, records that the voucher was used so they can be paid, and then gives you the food you ordered. You as the customer never get to see the exchange of money between the cashier and the payment system.

◧◩◪◨⬒⬓⬔
7. its-su+Me6[view] [source] 2026-02-05 10:25:20
>>Danger+jj3
(Noting that, as stated in another thread, it only applies to headers, so the premise I raised doesn't apply either way)

Except that you are asking for the result of it, "Hey Bobby LLM, what is the value of X" will have Bobby LLM tell you the real value of X, because Bobby LLM has access to the real value because X is permissioned for the domain that the LLM is accessed through.

If the cashier turned their screen around to show me the exchange of money, then I would certainly see it.

[go to top]