01
why prompt rules can't protect a secret
if the real credential is inside the sandbox, any code that runs there can read it, log it, or send it somewhere. asking the agent nicely not to is not a control.
back to microsandbox
features / credentials
the agent gets a placeholder. the destination gets the key.
credentials are destination-bound. the sandbox works with a placeholder; the real value is substituted host-side into supported intercepted outbound requests, only for destinations on your allow-list. an approved destination still receives the real credential and could reflect or misuse it, so scope your allow-lists accordingly.
02
the agent holds a placeholder
credentials are destination-bound. the sandbox works with a placeholder; the real value is substituted host-side into supported intercepted outbound requests, only for destinations on your allow-list. an approved destination still receives the real credential and could reflect or misuse it, so scope your allow-lists accordingly.
03
scope it like you mean it
an allowlist with one destination is a strong control. an allowlist with everything on it is not. the guarantee is only as tight as the destinations you approve.
how it works
how substitution works
01
you register a secret
give the runtime the real value, the env var the code reads, and the destinations allowed to receive it.
02
the guest sees a placeholder
inside the sandbox the variable holds a placeholder, so dumping the environment does not reveal the secret.
03
the host substitutes on the way out
for an outbound request to an allowed destination, the host swaps the placeholder for the real value.
04
everything else gets the placeholder
a request to a destination you did not approve carries the useless placeholder, not the key.
common questions
where can i see how this is built?
the mechanism is described in our post on secrets that lie, with the enforcing runtime available to inspect in source.