The usual way to let sandboxed code reach an authenticated API is to copy a token into the sandbox. That makes the token exfiltratable by the very code you sandboxed it to contain. Omnigent’s egress proxy inverts the trust boundary: the real secret stays in the unsandboxed parent, held in the rewrite table of an L7 MITM egress proxy that is the sandbox’s only path to the network.
A tool simply makes its request to the bound host with no
Authorizationheader. The proxy recognises the bound host and injectsAuthorization: <scheme> <real>on the way out.
So the sandbox sends an unauthenticated request to, say, api.github.com; the proxy — outside the sandbox — adds the credential as it leaves. The sandbox never holds, sees, or can print the secret.
For clients that refuse to send a request without some credential (like gh), the proxy injects a single-use, host-bound placeholder (oa_cred_*) into the sandbox and swaps it for the real value on the wire. The placeholder is useless anywhere else: aimed at the wrong host it returns a deliberate 403, so a leaked placeholder can’t be replayed.
This only holds if the proxy is genuinely the only egress. It requires egress_rules plus a hard-isolating backend (linux_bwrap / darwin_seatbelt) with default-deny networking, so code can’t open a side channel around the proxy.
Why this is non-obvious
“Give the workload least privilege” usually still means giving it a credential. This pattern gives it none: authority lives at a chokepoint the workload can’t read, and is applied only as bytes leave the trust boundary. The secret and the untrusted code are never colocated.
Sources
-
designs/SANDBOX_CREDENTIAL_PROXY.md✓ verified -
omnigent/inner/egress/proxy.py✓ verified