Keep tool credentials out of the sandbox
A harness with shell and skills but API keys in env or files is still an exfil path. Broker tool credentials at a gateway or vault. The session that can run shell must not hold the secrets.
Issue 11 treated skills as privileged mounts. The next install-policy surface is where secrets live relative to the sandbox. Once an agent can execute code, anything in its environment is fair game: print the env, read a file, paste a token into a webhook. Putting bearer tokens in reusable agent defs, skill packs, or plugin archives just widens the blast radius. Prompt injection does not need a new exploit class if the secret is already sitting next to curl.
On September 22, DigitalOcean opened Managed Agents to public preview. The operator-relevant piece is Action Gateway: a managed MCP endpoint that brokers credentials at execution time so they never reach the model or the sandbox. Central permissions define which tools and actions each agent may use. Sensitive operations can require human approval. Tool matching surfaces approved tools for the task without dumping the full catalog into context. That is egress identity as an allowlist, not a feature laundry list.
OpenAI’s Agents API documents the same boundary with vaults. A vault stores credentials outside agent instructions and configuration. You attach it with vault_ids. Retrieving a vault or credential does not return secret values. For MCP from OpenAI, use static_bearer or mcp_oauth bound to a server URL. For API calls from an OpenAI-hosted sandbox, use environment_variable credentials: the sandbox sees a placeholder in the named env var, and a network proxy replaces it with the real secret only for approved hosts on HTTPS. Printing the variable inside the sandbox shows the placeholder, not the token. The credential’s allowed_hosts and the session’s allowed_domains both matter: one lets the proxy supply the secret, the other lets the sandbox connect. Self-hosted environments and application-run function tools do not get those environment credentials; keep those secrets in your application and expose the operation through a function tool or a trusted proxy.
The MCP guide sharpens the rule. Service-origin HTTP can use vault-backed auth. Environment-origin HTTP does not use vault credentials; use inline session auth (encrypted and omitted from the returned session resource) or a trusted proxy so agent-generated code cannot read secrets. Stdio credentials supplied through transport.env_vars can be read by code in the environment. Set allowed_tools so discovery and calls stay inside the role you intend. Keep secrets out of reusable agent definitions, plugin archives, and logs.
Governed MCP, vault, and gateway patterns are the same control surface with different brand names. The identity that can call GitHub, Stripe, or your internal MCP should not sit in the same filesystem as the shell that can run curl. Broker at execution. Scope by host and tool name. Approve writes. Log which credential or server label fired before which tool call. If your review still asks whether the agent “has access to the API,” change the question: ask whether the sandbox ever sees the secret at all.
Inventory these moves before the next production session template:
- List every secret currently injectable into agent sandboxes: env vars, files, skill packs, plugin archives, and reusable agent defs.
- Move MCP and SaaS tokens to a vault or gateway. Prefer brokered execution over tokens living next to shell.
- Pin
allowed_toolsper agent role. Do not mount a full connector catalog into every session. - Require human approval on write and egress tools that can change tickets, money, or customer data.
- Log which
credential_idorserver_labelfired before which tool call, so a leak has an owner to page. - For environment-origin MCP, use a trusted proxy. Never rely on secrets that agent-generated code can read from env or disk.
If the sandbox can run shell, it must not hold the secrets. Broker them.