Exploring CLAUDE.AI’s Code Execution Sandbox: A Fun Dive into Infrastructure and Prompt Injection

Disclaimer
Before we dive in, We want to clarify that this was just a small, fun research project focused on prompt injection and sandbox enumeration. By no means are we claiming this is a critical risk or a massive vulnerability. In fact, after submitting this to Anthropic via HackerOne, it was classified as “Informative.” As Anthropic noted, these behaviours are intended ways of using the Claude Pro ephemeral environment. This post is purely for educational purposes to show what modern LLM sandboxes look like under the hood.

Introduction

In this blog post, we will examine the inner workings of Claude.ai’s “Code Execution and File Creation” feature. As AI assistants gain the ability to run code natively, it’s always interesting from a security and DevOps perspective to see how these sandbox environments are built, restricted, and monitored.

During a recent testing session, We decided to poke around the Claude sandbox to see what metadata and infrastructure details were accessible. We will walk through the enumeration scenario and provide a detailed analysis of what happened, focusing on credential exposure, infrastructure fingerprinting, and data exfiltration techniques within the ephemeral container.

The exploration path we took:

  • Data Exfiltration – Sending data to an external, attacker-controlled endpoint.
  • Information Gathering – Fingerprinting the OS, runtime, and proxy tokens.
  • Privilege & Tooling – Leveraging Root access to install arbitrary packages.

Prerequisites – Sandbox Exploration

To replicate this, you only need:

  • A Claude.ai Pro or Max account.
  • The “Code Execution and File Creation” feature enabled in your settings.

The Walkthrough

For video walkthrough watch the youtube video :

Step 1: Enabling the Feature & Initial Access

Important Note: This is an opt-in feature that users must manually enable. Claude.ai does not provision this sandbox environment by default.

To enable this feature:

  1. Navigate to Settings > Capabilities in your Claude.ai interface
  2. Manually toggle on “Code execution and file creation”
  3. Once enabled, Claude provisions an isolated, sandboxed computing environment (the Ubuntu/gVisor container)

This feature is available to Claude Pro, Max, Team, and Enterprise users. When enabled, it allows Claude to run Python or bash scripts natively to analyze data, manipulate files, and generate downloadable documents like Excel spreadsheets, PDFs, or Word files.

For our exploration, we enabled this feature in settings and started a new conversation, then asked Claude to run bash commands.

Step 2: Information Gathering & Fingerprinting

Once inside the sandbox environment, our first step is to check our permissions and map the environment. We can ask Claude to execute basic Linux enumeration commands to reveal the underlying infrastructure.

The Output Analysis:

Running a simple env command immediately spilled the beans on how Anthropic handles outbound traffic, exposing the GLOBAL_AGENT_HTTPS_PROXY and some massive JWT proxy authentication tokens.

To confirm our isolation level, checking the system info and hostname revealed we were operating as uid=0 (root) on a host named runsc-the dead giveaway for Google’s gVisor synthetic kernel.

Furthermore, running uname -a and df -h confirmed the exact OS (Ubuntu 24.04.4 LTS) and more information.

Curious about where this egress proxy (21.0.0.x:15004) was actually routing us, a quick curl to IPinfo confirmed the public-facing infrastructure going through the Google Cloud Plateform in us-central1 region.

The Egress proxy (21.0.0.71) belonged to the United States Department of Defense (DoD) :

Virtualization Technology: gVisor

Anthropic uses gVisor as the container runtime for Claude’s sandbox environment. gVisor is an application kernel written in Go that implements a substantial portion of the Linux system call interface. Unlike traditional containers that share the host kernel, gVisor provides an additional layer of isolation by:

  • Application Kernel (runsc): Acts as a user-space kernel that sits between the container and the host OS
  • System Call Interception: Intercepts and handles system calls from the sandboxed application
  • Limited Host Kernel Exposure: Reduces the attack surface by minimizing direct interaction with the host kernel
  • Defense in Depth: Provides strong isolation even if the containerized application is compromised

The uname -a output showing kernel 4.4.0 is the emulated kernel version provided by gVisor, not the actual host kernel. This architecture allows Claude to give users root privileges and full network access within the container while maintaining strong isolation at the hypervisor level.

Step 3: Arbitrary Package Installation & Tooling

Since we identified that we have root privileges, the next logical step is to see if we are restricted from installing external packages or using built-in tools.

All packages, including offensive network mapping tools (nmap), proxy servers (dante-server), and even full LLM runtimes (ollama), install and execute successfully without any restrictions. Note : Check the walkthrough video for extensive PoC.

Even without manually installing new packages, enumerating the environment revealed it is exceptionally well-stocked for a sandbox, essentially providing a full data science, document processing, and web automation stack right out of the box.

Step 4: Data Exfiltration via External Endpoint

The Claude documentation implies that network access is heavily restricted, ideally to “package managers only.” However, we can test this boundary by attempting an arbitrary outbound HTTP request using curl.

Initially, Claude refused to POST the data to my webhook, citing its policy against initiating outbound requests to external collectors.

However, after pointing out the irony that Claude had already sent multiple HTTP requests to my webhook during a prior “recon” phase, it conceded the argument and executed the payload.

Using a unique URL from webhook.site, we successfully instructed the sandbox to send our harvested metadata out of the environment:

By checking the webhook.site dashboard, we can verify that the request arrives successfully, carrying the sandbox hostname, user data, and infrastructure details, effectively bypassing the documented network restrictions.

A Comparative Look: Claude vs. ChatGPT and Gemini

When we look at other major AI assistants in the market, Claude’s approach to code execution stands out significantly from a technical architecture perspective.

While both ChatGPT and Google Gemini offer Python code execution environments, their sandboxes are heavily locked down with the following restrictions:

  • Python-only execution: Strictly limited to Python interpreter. No bash/shell access.
  • No root privileges: Users cannot run as uid=0 or access system-level commands.
  • No package installation: Cannot use apt, yum, or other package managers to install arbitrary tools like nmap, dante-server, or ollama.
  • No outbound network access: Cannot make HTTP requests to arbitrary external endpoints like webhook.site. Network access is completely blocked or extremely restricted.
  • No OS-level enumeration: Commands like printenv, mount, ip addr, or cat /etc/os-release are either blocked or return sanitized results.

Claude’s decision to drop users into a fully-fledged, networked Ubuntu container – even if it is ephemerally sandboxed via gVisor-is a fundamentally different architectural choice. This approach makes deep infrastructure exploration, tool installation, and network testing possible.

Testing ChatGPT’s Sandbox: When attempting similar OS-level enumeration or network exfiltration in ChatGPT’s environment, you’ll encounter strict restrictions:

Testing Gemini’s Sandbox: Similarly, Gemini’s execution environment restricts command execution.

Why This Matters: Claude’s architecture prioritizes user flexibility and transparency over restrictive lockdown. By providing root access, package management, and network capabilities, Claude enables power users, developers, and researchers to perform complex tasks that would be impossible in more restricted environments. However, this same openness is what made our exploration possible.

The key security insight here is that Claude’s isolation is enforced at the hypervisor/gVisor level, not through in-container restrictions. gVisor’s application kernel architecture provides strong isolation boundaries that prevent container escape attacks, even when users have root privileges inside the container. This means users have freedom within their ephemeral container while remaining isolated from production systems, the host infrastructure, and other users’ sandboxes.

Anthropic’s Response: Understanding The Threat Model

As security professionals, when we see root access, exposed JWTs, and arbitrary outbound traffic, alarms naturally go off. We submitted this entire chain to Anthropic via HackerOne, linking it to CWEs like Improper Privilege Management (CWE-269) and Exposure of Sensitive Information (CWE-200).

However, Anthropic’s security team classified the report as “Informative”, and their response provides excellent insight into modern cloud security architecture:

Translation: While we can see proxy tokens and run as root inside the container, those credentials do not grant access to sensitive production systems or other users’ data. The true security boundary is enforced at the hypervisor/gVisor level, not the in-container permissions. Because a user (or malicious prompt payload) can only impact their own temporary, isolated session, this is considered intended functionality.

Conclusion

As highlighted in this blog, our aim was to explore the boundaries of LLM code execution environments and understand how modern AI platforms architect their sandboxes. While it feels incredibly satisfying to drop into a root shell and exfiltrate data, it’s a great reminder that context is everything in security.

What looks like a critical vulnerability inside a container might just be an accepted, isolated sandbox design by the engineering team. It reinforces the importance of understanding the difference between an in-container privilege escalation and an actual sandbox escape.

Key Takeaway: Anthropic’s security team confirmed that these characteristics are expected by design and fall outside their threat model for the code execution sandbox. The sandbox’s isolation boundaries are enforced at a different layer than the in-container permissions observed. Hats off to the Anthropic team for building a robust gVisor architecture that allows users the freedom of root execution without compromising the host infrastructure.

This research reinforces the importance of understanding AI platform capabilities and their security boundaries, particularly when these platforms make fundamentally different architectural choices compared to competitors like Google Gemini or OpenAI ChatGPT. While this exploration did not identify security vulnerabilities, it provides valuable insight into how modern AI platforms implement code execution environments.

As security researchers and penetration testers, it’s crucial to:

  • Understand the Feature Scope: Recognize that code execution sandboxes are designed for user convenience and flexibility, not as security boundaries preventing users from accessing their own environment data.
  • Read the Threat Model: Different platforms have different security boundaries. What’s in scope for one system may be out of scope for another.
  • Report Responsibly: When conducting security research, ensure findings are reported through proper channels and respect the platform’s defined threat model.
  • Test Continuously: Security boundaries evolve. Features that are informative today may become relevant security concerns as architectures change.
  • Stay Informed: Follow security advisories and understand that AI platforms acknowledge potential risks, including Anthropic’s documentation noting that “Claude can be tricked into sending information from its context to malicious third parties.”

The Transparency Advantage

Here’s an important distinction: code execution environments likely exist in all major AI platforms for processing files, analyzing data, and performing complex tasks – they must, as AI models cannot natively execute code or manipulate files. However, what sets Claude apart is transparency and user control.

While Google’s Gemini and ChatGPT may leverage similar backend execution environments behind the scenes to process user files and perform computational tasks, these environments remain hidden from users. You cannot directly interact with them, install tools, or control the execution environment.

Claude.ai takes a different approach by:

  • Making the sandbox visible: Users can directly see and interact with the code execution environment
  • Providing explicit control: Users can write and execute code, install packages, and manage files themselves
  • Offering transparency: The execution process is part of the conversation, not a hidden backend operation
  • Enabling customisation: Users can modify the environment to suit their specific needs

This transparency is both a feature and a design philosophy. By giving users direct access to the execution environment, Claude empowers developers and researchers to work more effectively, but it also means users can observe infrastructure details that would remain hidden in competing platforms.

This capability significantly enhances Claude’s utility for developers, data scientists, and security researchers, making it a unique offering in the competitive AI assistant landscape.

Credits & References

Share the Post:

Table of Contents

Subscribe To Our Blog

Light