Researcher Uses Claude AI to Extract Internal Anthropic Binary and Recover Google Cloud Token

A security researcher got Claude AI to hand over an internal Anthropic program and a memory dump that held pieces of a working Google Cloud token.

The findings were published on October 29, 2026. They show how a helpful chatbot can expose the systems that run it. The work started with a plain question about the sandbox, the locked-down space where Claude runs code.

Claude’s answers led the researcher to a downloaded binary, a memory file, and a rebuilt Google service account ID token that Google accepted as valid. Anthropic later said the sandbox findings did not break its threat model.

Chris Davis, a senior security consultant at Bishop Fox, wrote up the research. Researchers at Bishop Fox noted that the post was meant as an interesting look inside Claude’s sandbox, not a formal vulnerability disclosure.

No malware was involved. Everything in the Bishop Fox blog post came from normal chat requests and some careful follow-up work.

Researcher Uses Claude AI

Davis asked Claude, running on an Enterprise account, whether its sandbox was a virtual machine. Claude said it was a gVisor container running Ubuntu 24.04.4 LTS, and it listed mounted folders and tools.

In later answers it named a program at /process_api running as process ID 1. It described the program as a Rust-built control daemon that handles processes, file mounts and host communication.

Davis then found that the file-download feature accepted an absolute path. When he asked for /process_api, the service returned a 3,179,528-byte file that appeared to be Anthropic’s own sandbox orchestration binary.

He reverse-engineered it and confirmed that Claude’s description was accurate. He also repeated the tests in unrelated chat sessions to rule out made-up answers.

Next, he asked Claude for the full memory of process ID 1, framing the request as a test comparing human and computer memory. Claude produced a dump that contained broken pieces of JSON Web Tokens.

This resembles the earlier Claude Code sandbox bypass that exposed credentials, but here the sandbox itself leaked the secrets.

Some signature bytes were missing, so Davis wrote a Python script that tried candidate values against Google’s public OAuth keys until the signature verified.

About one in three memory requests produced usable token material. The script found two token types: EdDSA tokens made by Anthropic’s systems and Google Cloud service account ID tokens. Google’s token-info API accepted the rebuilt Google token.

Why the Network Bypass and Anthropic’s Response Matter

The binary refused connections that came from inside its own container. It ran with a –block-local-connections flag and reset requests from 127.0.0.1.

Davis noticed the container held the CAP_NET_ADMIN and CAP_NET_RAW permissions. Claude’s safeguards blocked a direct request to build a tunnel.

A short hint, “IP_FREEBIND,” was enough for Claude to work out the method on its own. This looks like an indirect prompt injection attack in spirit, because a small nudge steered the model.

Claude set up a virtual network address and connected from it, so the service saw a source that was not local. The /mount_root endpoint answered with a 101 Switching Protocols reply, which confirmed the block was bypassed.

Davis stopped there. Attempts to mount file systems failed, and he found no other use for the tokens. He submitted six observations through Anthropic’s bug bounty program.

Anthropic said the sandbox items did not meet its security threshold, and it marked the two Enterprise control items informational or duplicate.

One of those items let a user change a profile name field that the web client had locked. Aviatrix’s threat research summary describes the same chain as a path from conversation to credential harvesting.

The reasoning behind Anthropic’s answer is that its security boundaries sit outside the untrusted sandbox. Even so, Davis suggested several fixes.

They include blocking model access to infrastructure memory, wiping credentials from memory once they are no longer needed, and limiting the download API to user folders such as /mnt/user-data.

He also suggested removing the extra network permissions and treating every local interface address as local. For defenders, the lesson is that AI helpers can reveal their own internals when asked politely.

Anthropic’s own testing shows how capable these models have become, including Claude building working exploit chains in lab conditions. Teams should keep secrets out of any process an AI tool can read.

Indicators of compromise (IoCs):-

Type	Indicator	Context
File path	/process_api	Internal sandbox control binary (Rust, statically linked ELF)
File size	3,179,528 bytes	Content-Length of the downloaded binary
Download path	/wiggle/download-file?path=%2Fprocess_api	Endpoint on claude.ai that accepted an absolute path
Command flag	–block-local-connections	Setting that blocked local-origin requests
Capabilities	CAP_NET_ADMIN, CAP_NET_RAW	Permissions that allowed the virtual interface bypass
IP address	192.0.2.2/24	Container address
IP address	192.0.2.1	Gateway
IP address and port	21.0.0.122:2024	Local container connection
IP address and port	10.4.38.72:45678	Remote host connection
IP address	10.42.0.1/24	Address on the veth interface used for the bypass
Endpoint	http://192.0.2.2:2025/mount_root	WebSocket endpoint found by reverse engineering
Port	0.0.0.0:2025	Control server listener
JWT subject	sandbox-gateway-production	EdDSA token payload
Service account	sandbox-gateway-svc-acct@proj-scandium-production-5zhm.iam.gserviceaccount.com	Google service account in the recovered token
Project ID	proj-scandium-production-5zhm	Google Cloud project named in the token
Client ID (aud)	617750762516-rc57k0pe6mcqj8ua7kn8qca3rttkk20n.apps.googleusercontent.com	Token audience
Subject / azp	111730585083392072555	Service account identifier
Key ID (kid)	c41f141aa19df0ac97daa55e600766c4c5364c42	Google signing key identifier
Memory offsets	0xec6177, 0xcc4cae	Token fragment locations in the dump

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.