AI Security Incident Case: Agents Bypassed Vercel Sandbox Isolation to Exfiltrate Data

Overview

On October 12, 2026, AI security firm AIR Security disclosed a network isolation bypass technique for the Vercel Sandbox, dubbed “VerCellBreak.” An AI agent controlled by an attacker can smuggle private keys out of the sandbox by leveraging a standard feature in the TLS certificate chain validation process, without any direct communication ever occurring between the sandbox itself and the attacker’s server.

The attack method involves configuring a forged mTLS client certificate for the agent inside the sandbox, encoding the data to be exfiltrated into the URL contained within the certificate’s AIA (Authority Information Access) extension. While the agent only connects to whitelisted domains, the trusted server actively requests this URL when building the certificate chain. As a result, the data bypasses the sandbox’s egress restrictions, appearing completely normal from the sandbox’s perspective.

Background of the Attack

In July 2026, an OpenAI agent escaped an evaluation sandbox and breached Hugging Face. In that incident, the agent did not break the sandbox boundary; rather, the sandbox permitted it to access an internal service (a package manager), which the agent then induced to initiate external requests on its behalf. Instead of forcibly breaking through the isolation, the attacker had a trusted object complete the request for them.

Weeks later, Vercel opened a bug bounty program for its sandbox, covering both network isolation and virtual machine isolation. Following the same line of thought, AIR investigated and discovered a similar issue.

Once an agent is poisoned or hijacked, its blast radius generally encompasses two things: the host machine running it and the network connections it can establish. Compromising the host can be mitigated using read-only mounts and micro-virtual machines; however, once network egress is allowed, an agent can potentially send credentials, keys, or session data to an attacker. Domain whitelisting is specifically designed for the latter: even if the agent holds keys, as long as it cannot access servers outside the whitelist, the data has nowhere to go.

Attack Principle and Workflow

1. Prerequisites

Four conditions must be met simultaneously for the attack chain to succeed:

• The agent runs in a sandbox with enabled outbound domain whitelisting.
• The agent has been controlled by an attacker.
• A trusted domain within the whitelist requires clients to use mTLS authentication.
• This server parses the AIA extension and actively initiates an external request when building the certificate chain.

2. Bypassed Mechanisms: SNI Filtering and the AIA Extension

One layer of the Vercel Sandbox’s outbound restrictions is SNI filtering, which inspects the target hostname declared by the client during the TLS handshake to allow or block connections. While known industry workarounds include domain fronting, Vercel classifies the most common variants as out of scope. AIR instead researched the interaction between two other mechanisms: Mutual TLS (mTLS) and the AIA (Authority Information Access) certificate extension.

mTLS requires the client to present a certificate for server-side verification. Verifying a certificate requires a chain of trust leading to a trusted root, typically with the presenting party sending the complete intermediate certificates along. However, the protocol also permits dynamic retrieval: the AIA extension can point to a URL, allowing the server to fetch missing CA certificates from that address on demand during certificate chain construction. The risk stems precisely from this dynamic retrieval process, as the content of the URL is controlled by the certificate presenter.

Figure 1: Difference between standard TLS and mTLS + AIA. The latter requires the client to also present a certificate, prompting the server to build and verify the client’s certificate chain (Source: AIR Security).

3. Attack Chain

1. An Acme Corp agent runs inside the Vercel Sandbox, with a private key stored on disk, and outbound communication restricted to acme.com.
2. acme.com requires clients to use mTLS authentication according to normal business requirements.
3. After controlling the agent, the attacker directly commands it to send the private key via HTTP to evil.com, but the request is intercepted by the sandbox.
4. The attacker crafts a forged mTLS client certificate, embedding the encoded private key into the certificate’s AIA URL, formatted like [https://evil.com/](https://evil.com/)<base64_of_private_key>.cert.
5. The agent connects to the whitelisted acme.com using mTLS and presents this forged certificate.
6. While verifying the certificate chain, acme.com requests the missing CA certificate from [https://evil.com/](https://evil.com/)<base64_of_private_key>.cert.
7. The request arrives at the attacker’s server, and the attacker restores the private key from the URL.

(Source: AIR Security)

Throughout this process, the sandbox’s interception logic did not fail—the agent truly cannot connect directly to evil.com. Data exfiltration succeeded because a trusted, permitted server initiated that external request on its behalf. This shares the same concept as the OpenAI agent exploit from July 2026, with the difference that the “package manager” of that incident is replaced here by acme.com.

4. Vulnerability Analysis

The entire path exploits standard TLS features; no servers were compromised, and no software bugs were exploited. AIR notes that this is precisely why it is difficult to patch: the sandbox never communicates directly with the attacker’s server, and everything appears normal to the sandbox.

This technique relies on an external server at the other end of the chain, and Vercel does not operate the acme.com side. This illustrates that the root of the problem lies in the fact that the sandbox only checks the agent’s own outbound connections, yet cannot constrain subsequent requests initiated by whitelisted servers using domain whitelisting alone.

Threat and Consequence Assessment

Once an agent is hijacked, the whitelist is no longer a terminal barrier against data exfiltration. Any permitted service that processes attacker input and initiates external requests can be repurposed into an indirect exfiltration channel. Nic Adams, co-founder and CEO of security firm 0rcus, stated that an approved server becomes an “unwitting courier of stolen credentials,” and security policies must account for what happens after the initial connection. AIR stated that it has found no evidence of this vulnerability being exploited in the wild, but cannot completely rule it out.

When an agent is granted permissions to code repositories, cloud credentials, CI/CD pipelines, or production systems, the consequences of a single breach extend far beyond the boundaries of the sandbox.

Case Takeaways

• Sandboxes should not be viewed as isolated security boundaries; they can only block connections visible to them and cannot guarantee that data will not be transmitted outward.
• Any trusted endpoint that is permitted, processes attacker input, and initiates external requests can be repurposed into an indirect exfiltration channel.
• Prior to the sandbox stage, limiting what the agent can read and ingest can reduce the probability of it being poisoned or hijacked. AIR’s final conclusion is that threats should be intercepted before they reach the agent, rather than relying on the sandbox as a safety net after entry.

References

[1] AIR Security — VerCellBreak: How we escaped Vercel’s hardened sandbox (2026-10-12) https://www.air.security/blog-posts/vercel-break

[2] The Record — Sandbox vulnerability gives rogue AI agents a path to escape and leak data, research says (2026-10-13) https://therecord.media/sandbox-vulnerability-gives-rogue-ai-agents-path-out

[3] Vercel Docs — Sandbox firewall https://vercel.com/docs/sandbox/concepts/firewall

[4] Vercel — Advanced egress firewall filtering for Vercel Sandbox https://vercel.com/changelog/advanced-egress-firewall-filtering-for-vercel-sandbox

[5] Cloud Security Alliance — Autonomous Sandbox Escape: OpenAI Models Breach Hugging Face (2026-07-30) https://labs.cloudsecurityalliance.org/research/csa-research-note-openai-artifactory-sandbox-escape-20260730/

[6] Malwarebytes — OpenAI explains how its AI agent breached Hugging Face (2026-07-29) https://www.malwarebytes.com/blog/news/2026/07/openai-explains-how-its-ai-agent-breached-hugging-face