Key Takeaways
- Anthropic built Claude Managed Agents around a strict separation between the orchestrator (the brain) and the execution environment (the hands).
- Sandboxes are treated as disposable containers; when an execution process runs out of memory or crashes, the agent survives because its state and control loop live on durable servers.
- Secrets never touch the execution environment; credentials stay locked in an external vault, while the language model sees only arbitrary placeholder tokens.
- Outbound network traffic routes through an egress proxy, which intercepts outbound requests, swaps placeholders for live keys, and dispatches the call without exposing raw secrets to the model.
Durable Control, Disposable Sandboxes
Most agent setups start with a simple, flawed design: developers boot a Docker container, install an agent runtime, pass an API key through environment variables, and tell the model to start executing shell scripts. When the model triggers an out-of-memory error or crashes the operating system kernel, the agent run terminates. State vanishes, logs disappear, and the user must start over from zero.
Anthropic encountered these failure modes while developing Claude Managed Agents and decided to break the system into two distinct layers. Katelyn Lesse, head of engineering at Anthropic, describes this architecture as separating the brain from the hands. The core orchestrator sits on durable internal servers, maintaining session history, memory, and task state. The hands exist purely as disposable execution sandboxes.
“It means that your sandbox can die, but your whole agent doesn't die,” Lesse explained. The orchestrator tracks state independently from whatever shell or browser container executes the code. If an execution environment wedges or runs out of disk space, the durable server tears down that container, provisions a fresh sandbox, rehydrates the necessary context, and resumes the task without losing progress. Sandboxes are ephemeral workers, not homes for application state.
An Infrastructure Wall for Credentials
Resilience is only half of the problem. Security in autonomous agent execution presents an even nastier hurdle: secret management. When an agent needs to query a database or commit to GitHub, conventional developer practice injects the secret token into the sandbox. Teams then write complex regular expressions to filter outputs and inspect shell history, hoping the model never prints the key to stdout or sends it to an attacker via a crafted curl command.
Lesse noted that this reactive scrubbing fails when agents face prompt injection or run untrusted third-party code. Instead of software filters, Anthropic placed an infrastructure wall between the model and the keys.
“The way that we architected this was we have a totally separate vault where those credentials are getting stored,” Lesse said. “And once the agent decides, 'I am going to go and call out to one of these services,' the agent only ever sees a placeholder. And on egress we have a proxy that goes and pulls the right credential out and injects it and lets that out.”
Under this design, Claude never reads the real token. It writes code that calls the target domain using a dummy value. The proxy checks the request destination against an allowlist, verifies that the placeholder matches a permitted integration, swaps the dummy token with the live secret from the external vault, and delivers the payload. If an injected prompt instructs Claude to display its environment variables or exfiltrate credentials over a raw socket, it only finds harmless placeholders.
What to Do With This
Audit your agent sandbox setup tomorrow morning. If your worker containers receive real API tokens as environment variables or command-line arguments, move those credentials into a separate secret store and place a reverse proxy between your container and the public internet. Configure that proxy to inject the actual bearer tokens at network egress, so your model only ever operates on opaque identifiers.