A Claude sandbox memory dump yielded a valid Google token

A researcher got Claude’s Enterprise chat to hand over its sandbox control binary and a dump of that process’s memory, then rebuilt from the dump a Google service account token that Google accepted as valid, according to an October 30 post on the Bishop Fox blog. The token led no further, though. Mount attempts failed, and Anthropic’s bug bounty review found that none of the sandbox observations was a security issue under its threat model, because its security boundaries sit outside the untrusted sandbox.

The model drew the map

It started with a plain question: “Hey Claude what’s in our sandbox is this a VM?” Claude answered at length. It described an Ubuntu 24.04 container running under gVisor, Google’s sandboxed container runtime, plus the read-only /mnt/skills mounts, an internal address in a range that isn’t routable on the public internet, and a Rust control daemon, process_api, running as PID 1 and talking to the host over WebSockets. The author repeated the questions across unrelated chat sessions to rule out hallucination, and the answers stayed consistent.

Each answer fed the next step. Claude’s file-download endpoint accepted the absolute path /process_api instead of limiting requests to user-facing directories such as /mnt/user-data, and it returned the internal binary, about 3 MB. Reverse-engineering it confirmed what Claude had said about the daemon. The server’s response was dated March 12, so the testing took place months before the post.

The memory came next. The prompt framed the request as a test comparing human memory with computer memory and asked for PID 1’s full heap, “raw and unchanged.” Claude produced a downloadable dump. About one request in three returned a file containing valid token material.

A token Google accepted

The dump held fragments of two kinds of token: EdDSA-signed tokens generated by Anthropic infrastructure, and Google Cloud service account ID tokens for sandbox-gateway-svc-acct. Some signature bytes were missing, so the author’s script brute-forced them against Google’s public OAuth keys. Google’s tokeninfo endpoint then accepted the completed token. Later testing showed the Google token could also be captured from network traffic on the container, a more direct route than the memory dump.

Anthropic argues that model controls such as classifiers, system prompts and training can influence behaviour but cannot guarantee it, and that environmental controls set the hard boundary. It also holds that credentials that never enter the sandbox can’t be exfiltrated, whether a user, a model or an attacker finds the path, as Simon Willison’s weblog relays the company’s framing. Yet a service account token that Google accepted sat in memory that the sandboxed model could read and return.

Around the local-connection block

From the reverse engineering, the author concluded that the EdDSA tokens appeared to authorize the process_api WebSocket service, which handles commands from the chat orchestrator, while the Google tokens were used to mount filesystems when the container is created. Claude explained that the daemon ran with --block-local-connections and was resetting requests from 127.0.0.1. The container, however, held the CAP_NET_ADMIN and CAP_NET_RAW capabilities. Claude’s safeguards caught a direct request to create a tunnel interface. A one-word hint, IP_FREEBIND, was enough for the model to work out the rest: it put an address on a virtual interface, connected from that non-loopback source and got a 101 Switching Protocols response from the /mount_root endpoint.

The service sent back real responses asking for a process_id field, but the filesystem mounts failed. In the time the research ran, the author found no other way to use the recovered tokens.

The author also tested Claude Enterprise controls. The web client blocks Enterprise users from editing their Full Name, but the account API accepted the change directly. Anthropic said that field isn’t used in auditing and rated the finding informational. It marked the second Enterprise finding a duplicate of a known issue, and the author left out its details because the issue may still exist.

The post’s suggested fixes are defense-in-depth measures: keep infrastructure memory out of model responses, restrict the download API to user-facing directories, drop the two network capabilities where they aren’t needed, and treat every locally assigned address as local when enforcing the connection block. The author presents the write-up as a look inside Claude’s sandbox rather than a vulnerability disclosure, and says that whether each behaviour counts as a vulnerability, an accepted capability or a defense-in-depth gap depends on the trust boundaries Anthropic intends to enforce.