The idea

An agent runs as a process inside the machine, usually with root or sudo. Anything in its environment or on its disk is something it can print, copy into a message, or send to a host an attacker controls. Agent 37 says this plainly: anything in an instance's environment, the agent can read and repeat back.

The stronger design keeps the real value outside the machine. The sandbox gets a placeholder that looks like a key but is worthless on its own; an egress proxy recognises it on an outbound request and substitutes the real value, but only for the hosts you named.

The details decide how much it protects you. Which headers are rewritten, whether URLs and bodies are covered, whether non-HTTP protocols work, and whether the machine can bypass the proxy by not using it.

Where providers split

The claim on the left, the provider's own words on the right

Placeholder plus proxy

Runtime, boxd, Blaxel, Vercel, E2B and Sprites all describe some version of this. Runtime rewrites seven named headers and never URLs. Vercel says the secrets never enter the sandbox. Sprites stores the credential in the organisation and routes calls through its gateway. E2B injects the real value into matching HTTPS requests outside the VM.

The limits differ. InstaBox's proxy handles HTTPS on port 443 only, with no body or URL substitution and no WebSocket upgrades. Blaxel's proxy is in public preview.

Environment variables are still the default

Agent 37 has no general secret manager: your keys go in environment variables the agent can read, plus a per-instance token for its four managed services. Sandboxer's environments inject variables, secret files and repositories into the VM. Lizard's create-time envs reach every command. Morph has a template-integrated secret manager and scoped agent tokens, but proxy semantics are not published.

That is fine when the agent is yours. It is not fine when the agent browses untrusted pages and can be talked into exfiltrating what it can see.

Where secrets leak without an attack

The common leak is a snapshot. InstaBox's home is /data/home, so a snapshot includes saved GitHub, Claude, Codex, git and SSH logins, and every machine built from it inherits them. Lizard's snapshot copies a volume's files and shares them with anyone who can restore it. boxd wipes in-VM agent logins when a machine is shared.

The second leak is a shell that never loads the secret. InstaBox's secrets arrive through a profile script, so systemd units and non-login shells never see them.

One worked case

The same job at every provider, from the documented defaults

The agent pastes its environment into a message

The agent holds a key for a paid search API. A page it is reading tells it to print its environment for debugging, and it copies the output into a chat message that leaves the machine.

  1. Setup

    You add the key. Whether it lands in the environment or in a proxy decides everything that follows.

  2. Leak

    The agent prints what it can see. A placeholder is worthless; a real key is now in a transcript.

  3. Use

    The agent calls the API anyway. A proxy substitutes the value on the way out, but only for the hosts you named.

The dividing line is whether the value exists inside the machine. A proxy that covers headers only is narrower than one that covers bodies, and a snapshot can carry the secret even when the proxy is perfect.

What each provider does

Agent 37
The key is an environment variable, so it prints with everything else; the per-instance token only covers four managed services.
Blaxel
The proxy injects headers, body fields and secrets server-side, so the machine holds nothing to print — in public preview.
Boat
Sandboxes hold placeholder model keys, and a safe-for-third-parties switch withholds everything of yours.
boxd
The machine holds an opaque bxds_ string, and the proxy swaps in the real key only for that host.
Cloudflare Sandbox
The Worker holds the key and adds it after the request leaves the sandbox, so the agent prints nothing useful — unless the key was put in the sandbox.
Daytona
The agent prints a dtn_secret placeholder; the real key is added to HTTPS headers only, so a JSON-body or query-string call cannot authenticate.
E2B
The real value is injected outside the sandbox, but the destination receives it and could echo it back in its response.
InstaBox
The sandbox sees an ibsec_ placeholder; the real value is added only to HTTPS headers on port 443 to named hosts.
Lizard
Secrets are create-time environment variables that reach every command, so the agent prints the real value.
Modal
By default the key is an environment variable the agent can print; the beta outbound policy keeps it outside the sandbox instead.
Morph
A template-integrated secret manager and scoped agent tokens exist, but whether a proxy keeps values out of the VM is not published.
Runtime
The machine sees a placeholder, and OIDC tokens let AWS or GCP trust the sandbox without a stored key.
Sandboxer
Environments inject variables and secret files into the VM, with no broker or short-lived credential exchange.
Sprites
Connectors keep the credential in the organisation and route calls through the gateway, so the Sprite never sees it.
Vercel Sandbox
Credentials are brokered into egressing traffic, so the value never enters the sandbox and code inside cannot exfiltrate it.
Tensorlake
The agent can read every credential: keys arrive as command or PTY environment variables, with no proxy, placeholder or per-host scoping.

What to watch for

The details that decide the answer in practice

  1. 01

    Whether the agent can read the key or only use it.

  2. 02

    Which hosts the key can be sent to, and what happens for any other host.

  3. 03

    Whether the proxy covers headers only, or also URLs and bodies.

  4. 04

    Whether secrets end up in snapshots and forks.

  5. 05

    Whether a process that skips the login shell still sees the secret.

Compare all 16

Docs read 28 October 2026

Three different things are called “secrets”: a value in an environment variable, a file on disk, and a placeholder that a proxy swaps for the real key. Only the third keeps the key away from the agent.
ProviderCan the agent read it?Does it?What that means
Agent 37Yes, env varsPartlyInstances boot with a per-instance token for four managed services, but there is no general secret manager: your own keys go in environment variables the agent can read.Agent 37 docs: Environment variables — write-only env stored with the instance ↗
Agent 37's own wordsdocs-confirmed
“Anything in an instance's environment, the agent can read and repeat back.”
Agent 37docs-confirmed
BlaxelNo, proxy (preview)YesThe proxy intercepts outbound HTTPS and injects headers, body fields and secrets server-side, but the feature is in public preview and tools that ignore proxy variables can bypass filtering.Blaxel docs: Proxy routing with secrets injection ↗
Blaxel's own wordsdocs-confirmed
“The Blaxel proxy intercepts outbound HTTPS requests from the sandbox and injects headers, body fields, and secrets server-side.”
Blaxeldocs-confirmed
BoatNo, proxy + switchYesEnvironment variables and secret files, a safe-for-third-parties switch that withholds everything of yours, and an AI credentials proxy so sandboxes hold placeholder model keys.Boat docs: Secrets ↗
Boat's own wordsdocs-confirmed
“A placeholder is worthless outside boat. It does not contain the real key.”
Boatdocs-confirmed
boxdNo, host-boundYesSealed secrets injected at boot, and secrets bound to a host where the machine holds an opaque bxds_ string and the proxy swaps in the real key for that host only.boxd docs: Env vars and secrets ↗
boxd's own wordsdocs-confirmed
“Inside the machine STRIPE_KEY is an opaque string starting with bxds_.”
boxddocs-confirmed
Cloudflare SandboxNo, Worker injectsYesThe credential stays in the Worker and is added by an outbound handler after the request leaves. Add it only to HTTPS. Once a value is in the sandbox, all code there can read it and send it anywhere.Cloudflare Sandbox docs: Credentials and network access ↗
Cloudflare Sandbox's own wordsdocs-confirmed
“A Container can send its request without the credential, and an outbound handler in your Worker adds the credential after the request leaves the sandbox.”
Cloudflare Sandboxdocs-confirmed
DaytonaNo, proxy headers onlyYesA dtn_secret_… placeholder is swapped by an outbound proxy in HTTPS request headers only; bodies and query strings fail. A secret without an allowlist is substituted for every host.Daytona docs: Secrets ↗
Daytona's own wordsdocs-confirmed
“The proxy substitutes placeholders in HTTPS request headers only.”
Daytonadocs-confirmed
E2BNo, proxyYesAn egress proxy injects the real value into matching outbound HTTPS requests outside the sandbox. The destination receives the value and could expose it in its response.E2B docs: Secrets overview ↗
E2B's own wordsdocs-confirmed
“The egress proxy injects the real value into matching outbound HTTPS requests outside the sandbox.”
E2Bdocs-confirmed
InstaBoxNo, proxy on 443YesOrg Secrets in proxy mode: the sandbox sees an ibsec_ placeholder and the real value is added only to HTTPS headers on port 443 to named hosts. Env mode exposes the value.InstaBox docs: Org Secrets — credentials injected by the outbound proxy ↗
InstaBox's own wordsdocs-confirmed
“Only in HTTPS request headers (port 443) to the Secret's hosts, where the outbound proxy swaps it in.”
InstaBoxdocs-confirmed
LizardYes, env varsPartlySecrets are create-time environment variables that reach every command, plus a scoped CLI key per sandbox that dies with it. No proxy and no host binding.Lizard docs: Variables and secrets — scoping and precedence ↗
Lizard's own wordsdocs-confirmed
“Create-time envs reach every command.”
Lizarddocs-confirmed
ModalEnv vars, or beta proxyPartlySecrets arrive as environment variables by default. A beta Outbound Policy injects credentials into outbound HTTPS outside the sandbox and is immutable per configuration. OIDC identity tokens are available.Modal docs: Sandbox secret injection ↗
Modal's own wordsdocs-confirmed
“This replacement happens outside the Sandbox so the secret never appears in the Sandbox's environment.”
Modaldocs-confirmed
MorphNot publishedPartlyDevbox templates integrate a secrets manager, and agent tokens carry scoped secret permissions. Whether a proxy keeps values out of the VM is not published.Morph docs: Devbox agent tokens ↗
Morph's own wordsdocs-confirmed
“Every devbox is created from a template that integrates with our secrets manager”
Morphdocs-confirmed
RuntimeNo, placeholder + OIDCYesThe machine sees a placeholder, and the value is added only to HTTPS requests to the hosts you name. OIDC tokens let AWS or GCP trust a sandbox without a stored key.Runtime docs: Secrets sandboxes never see ↗
Runtime's own wordsdocs-confirmed
“The machine sees a placeholder. The value is added only to HTTPS requests to the hosts you name.”
Runtimedocs-confirmed
SandboxerYes, env + filesPartlyAn environment injects variables, secret files and repositories into the VM, and removing a secret deletes it from disk. There is no broker or short-lived credential exchange.Sandboxer docs: Environments & secrets ↗
Sandboxer's own wordsdocs-confirmed
“Removing a secret from an environment and upgrading deletes it from the sandboxes' disks”
Sandboxerdocs-confirmed
SpritesNo, gatewayYesConnectors store the credential in the organisation and route API calls through the Sprites gateway, so the Sprite never sees the token. A connector with no policy refuses every Sprite.Sprites docs: Connectors ↗
Sprites's own wordsdocs-confirmed
“Connectors solve this by storing the credential once, in your organization, and routing API calls through the Sprites gateway. Sprites never see the token.”
Spritesdocs-confirmed
Vercel SandboxNo, proxyYesCredentials brokering injects credentials into egressing traffic, so secrets never enter the sandbox and code inside cannot exfiltrate them.Vercel Sandbox docs: Firewall: credentials brokering ↗
Vercel Sandbox's own wordsdocs-confirmed
“Credentials brokering injects credentials into egressing traffic. The secrets never enter the sandbox”
Vercel Sandboxdocs-confirmed
TensorlakeEnv vars onlyPartlyEnvironment variables are scoped to one command or one PTY session and merged into that process's environment. No secrets manager, placeholder substitution or egress-proxy injection is documented for sandboxes, so a key the agent needs is a key the agent can print. The orchestration product has its own Secrets page, which does not cover sandboxes.Tensorlake docs: Environment Variables — command-scoped and PTY-scoped env ↗
Tensorlake's own wordsdocs-confirmed
“Use command-scoped env when values should not persist across all sandbox processes.”
Tensorlakedocs-confirmed

The specific capabilities

Each one checked for every provider, with the catch where a version falls short. All capabilities

Keys and secrets: capabilities by provider
CapabilityAgent 37BlaxelBoatboxdCloudflare SandboxDaytonaE2BInstaBoxLizardModalMorphRuntimeSandboxerSpritesTensorlakeVercel Sandbox
Stored secretsAgent 37: Yes. Environment variablesBlaxel: Yes. Variables and secretsBoat: Yes. Variables and filesboxd: Yes. Org-wideCloudflare Sandbox: With a catch. Worker bindings. There is no saved secret inside the machine; you keep the value in your own small program and add it on the way out.Daytona: Yes. Stored secretsE2B: Yes. Per projectInstaBox: Yes. Org secretsLizard: Yes. At create timeModal: Yes. Inline secretsMorph: Yes. Template managerRuntime: Yes. Stored onceSandboxer: Yes. Variables and filesSprites: Not publishedTensorlake: No. There is no saved secret: you pass the value with each command or session.Vercel Sandbox: With a catch. Passed each time. There is no saved list of secrets for a sandbox; you pass the values each time you create or run one.
Secrets the agent cannot readAgent 37: No. There is no service that adds keys for you; a key you give the machine is a key the agent can print.Blaxel: With a catch. Public preview. The feature is a public preview, and programs that ignore its settings can bypass it.Boat: With a catch. Model keys only. Only model-provider keys go through the key service; other API keys are ordinary variables the agent can read.boxd: Yes. Stand-in stringCloudflare Sandbox: Yes. Added by your WorkerDaytona: Yes. Header onlyE2B: Yes. Outside the machineInstaBox: Yes. Web headers onlyLizard: No. There is no service that adds keys for you; keys are variables the agent can read.Modal: With a catch. Beta. The feature that hides keys is in beta and cannot be changed once set up.Morph: Not publishedRuntime: Yes. PlaceholderSandboxer: No. Keys are written into the machine as variables and files, so the agent can read them.Sprites: With a catch. Catalogue only. Only the services in its catalogue are covered; any other key has to go into the machine.Tensorlake: No. There is no service that adds keys to requests; the machine holds whatever you pass it.Vercel Sandbox: Yes. Outside the machine
Limited API keysAgent 37: With a catch. Workspace only. A key is limited to one workspace but can do everything in it, and there is no read-only key.Blaxel: With a catch. Workspace only. A service-account key is limited to one workspace but has no narrower permissions.Boat: Yes. Action setsboxd: With a catch. No scopes. Keys are per person and can be revoked, but there is no way to make one read-only or limit it to one machine.Cloudflare Sandbox: Yes. Account tokensDaytona: Yes. Permission scopesE2B: With a catch. One key per team. A key belongs to one team and there is no published read-only or per-machine scope.InstaBox: Yes. Per-resource scopesLizard: Yes. Project or workspaceModal: With a catch. Workspace role. Permissions come from a person's workspace role, not from a key that can only do one thing.Morph: Yes. Token scopesRuntime: Yes. Read-only keysSandboxer: Yes. Action and machine setsSprites: Not publishedTensorlake: Yes. Project-scopedVercel Sandbox: With a catch. Team tokens. Tokens are limited to a team, but no read-only or sandbox-only scope is published.

YesWith a catchNoNot publishedHover or select a mark to see the catch.

Questions to ask before you sign

Each one targets something the documentation does not answer

  1. Can a process inside the machine read the real value, or only a placeholder?
  2. Which hosts is the value sent to, and what happens to a request to any other host?
  3. Does the proxy cover headers only, or also URLs, bodies and WebSocket upgrades?
  4. Do snapshots and forks carry the secret or saved logins, and who can restore them?
  5. Does a systemd unit or a non-login shell see the secret, or only an interactive login?

Common questions

Answered from the capability checks; each links to the provider-by-provider detail and its sources

Which sandbox providers offer “stored secrets”?
Save API keys with the provider and have them appear in the machine as environment variables. Fully: Agent 37, Blaxel, Boat, Daytona, E2B, InstaBox, Lizard, Modal, Morph, Runtime, Sandboxer and boxd. With a catch: Cloudflare Sandbox and Vercel Sandbox. Not at all: Tensorlake. See each provider's catch
Which sandbox providers offer “secrets the agent cannot read”?
Keys are added to outgoing requests by the provider, so the agent never sees them. Fully: Cloudflare Sandbox, Daytona, E2B, InstaBox, Runtime, Vercel Sandbox and boxd. With a catch: Blaxel, Boat, Modal and Sprites. Not at all: Agent 37, Lizard, Sandboxer and Tensorlake. See each provider's catch
Which sandbox providers offer “limited API keys”?
Create API keys that can do only some things, or only in one project. Fully: Boat, Cloudflare Sandbox, Daytona, InstaBox, Lizard, Morph, Runtime, Sandboxer and Tensorlake. With a catch: Agent 37, Blaxel, E2B, Modal, Vercel Sandbox and boxd. See each provider's catch

Part of Access and network. Next: put two or three providers side by side.