Skip to main content
Your code does not change. Secrets are declared the same way, arrive the same way, and are substituted the same way. What changed is where the process holding the real values runs — and that has one consequence worth understanding before you migrate.

​
How secrets work (unchanged)

Put values in a secret store, then name the store when creating a sandbox:
The environment variable holds a sealed placeholder, never your secret. When the sandbox makes a request to a host that secret is scoped to, a proxy swaps the real value into the outbound request. All three of these properties are identical on both runtimes:

The sandbox never holds the value

Only an osb_sealed_… placeholder is present in the environment, on disk, and in any process the customer can read.

Bypass fails closed

Code that ignores the proxy and dials an upstream directly sends the placeholder — a worthless string — rather than leaking the key.

Substitution is host-scoped

A secret scoped to api.github.com is substituted there and nowhere else. Sending it to a server you control yields the placeholder.

Rotation needs no restart

Updating a value takes effect on running sandboxes. The placeholder does not change — only what it resolves to.

​
What changed

The proxy moved from a host outside your sandbox to a root-owned process inside it.

​
Why it moved

It had to. The old proxy ran on the VM hosts we operated. This runtime has no such host — that is the entire point of it — so the proxy had to go somewhere else. The obvious alternative was a shared proxy service per region. We rejected that: it would be a single service holding every customer’s secrets and a single point of failure on every customer’s egress path, bought specifically to defend against escalation within one tenant. Concentrating everyone’s secrets to mitigate a single-tenant risk is a worse trade. So the proxy runs in the guest, owned by root, with your code running unprivileged.

​
What that actually means

Your code runs as the unprivileged sandbox user and cannot read root’s memory, so day-to-day protection is unchanged.
The difference is the blast radius of a privilege escalation inside your sandbox. On the current runtime, root in the guest still could not reach the proxy. Here, it can reach the secrets scoped to that sandbox.
Nothing else expands. A compromised sandbox still cannot reach another sandbox’s secrets, and the host-scoping rules still apply to whatever it does reach.

​
Does this affect you?

For most workloads, no. If code in your sandbox can escalate to root, the secrets that sandbox was already permitted to use are usually not the most valuable thing now reachable. It matters if you run genuinely untrusted code — arbitrary user submissions, an agent executing code it wrote — and that sandbox holds credentials worth more than the work it is doing. If that describes you:
1

Scope each secret to the fewest hosts that work

Host scoping is enforced at the proxy. A secret usable only against one API is worth much less to an attacker than one usable anywhere.
2

Give untrusted workloads their own store

Do not share a store between untrusted execution and your trusted services. A sandbox can only reach the store it was created with.
3

Prefer short-lived credentials

The 8-hour lifetime ceiling makes this natural — no sandbox outlives a same-day token.
4

Keep the highest-value credentials out of sandboxes

Put them behind a service the sandbox calls, so the sandbox holds a token for your service rather than the credential itself.

​
Rotation

Running sandboxes pick the new value up without a restart, and the sealed placeholder in their environment is unchanged — nothing inside the sandbox needs to know a rotation happened.
If you use secret rotation, this is worth re-testing after you migrate. On earlier builds a rotation against v2 returned 200 with refreshed: 0 and the sandbox kept serving the old value. That is fixed, and the response now reports how many sandboxes were actually refreshed — check that number rather than the status code.

​
Egress allowlists

A store can restrict outbound HTTPS to a set of hosts. Requests to anything else are refused, and this is unchanged between runtimes. The sandbox also cannot use the proxy to reach cloud instance metadata.

Security model

Isolation boundaries, egress, and the full reasoning behind the proxy’s placement.