Thanks and agreed! Zerobox uses the Deno sandboxing policy and also the same pattern for cred injection (placeholders as env vars, replaced at network call time).

Real secrets are never readable by any processes inside the sandbox:

```

zerobox -- echo $OPENAI_API_KEY

ZEROBOX_SECRET_a1b2c3d4e5...

```

▲

simonw 4 hours ago | parent [-]

Do you know if there's a widely shared name for this pattern? I've been collecting examples of it recently - it's a really good idea - but I'm not sure if there's good terminology. "Credential injection" is one option I've seen floating around.

▲

TheTaytay 2 hours ago | parent | next [-]

simonw, I have been seeing "credential injection" and "credential tokenizing" (a la tokenizer: https://github.com/superfly/tokenizer). I'm also seeing credential "surrogates" mentioned.

I am currently working on a mitm proxy for use with devcontainers to try to implement this pattern, but I'm certainly not the only one!

	▲	simonw 2 hours ago \| parent [-]
		Thanks, I think I'll go with "credential injection" since the word "tokenization" has other meanings that I find confusing here.

▲

afshinmeh 3 hours ago | parent | prev [-]

Not sure. I took this idea from the Deno sandboxing docs. They also do the exact same thing, different sandboxing mechanism though (I think Deno has it's own way of sandboxing subprocesses).