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.
features / credentials
give sandboxed agents placeholders instead of raw API keys. microsandbox substitutes the real value host-side into supported intercepted requests to approved destinations.



01
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.
02
bind a secret to the environment variable your application expects. the guest receives a placeholder and uses it in its requests; the host checks the destination before substituting the real value.
03
an allowlist with one destination is a strong control. an allowlist with everything on it is not. an approved endpoint receives the real credential and could return it to the guest. credentials supplied separately to the guest are outside this protection.
how it works
01
give the runtime the real value, the env var the code reads, and the destinations allowed to receive it.
02
inside the sandbox the variable holds a placeholder, so dumping the environment does not reveal the secret.
03
for an outbound request to an allowed destination, the host swaps the placeholder for the real value.
04
a detected placeholder in a supported intercepted request is blocked and logged by default when substitution is not allowed. explicit passthrough rules let trusted destinations receive the unchanged placeholder.
common questions
a normal environment variable exposes the raw value to code inside the sandbox. a secret binding puts a placeholder there and substitutes the value host-side only when the request meets the binding rules.
no. secret bindings require intercepted TLS by default, and body substitution is opt-in with format and size limits. bypassed TLS cannot be inspected for placeholders. see the secret handling documentation for the full boundary.