VerCellBreak: How we escaped Vercel's hardened sandbox

In July, OpenAI's agents escaped their evaluation sandbox and breached Hugging Face. They didn't break through the sandbox walls. The sandbox let them reach a single internal service, a package manager, and the agents made it send internet requests on their behalf.
A few weeks later, Vercel opened a bug bounty for its sandbox, covering both network and VM isolation. We went looking for the same pattern, and found it.
Vercel built its sandbox to run untrusted code while containing what that code can touch: the host it runs on, and the servers it's allowed to reach.
The security industry has faced a similar challenge before. Defenders eventually accepted that software vulnerabilities could never be eliminated entirely, so they also began limiting what attackers could do after exploiting them. Mitigations such as address space layout randomization (ASLR) follow this principle.
The same defense-in-depth approach is essential for AI agents.
When an agent operates under direct user supervision, exploitation is harder and riskier: many users still review commands and monitor the agent’s actions. Autonomous agents are easier targets. Once compromised, an agent can typically affect one of two areas:

• The machine on which it runs
• The network connections available to it.

Convincing an agent to execute a destructive command can damage the host.
But network access creates another serious risk: the agent may be able to exfiltrate credentials, secrets, or session data to an attacker-controlled server.

The Sandbox

To reduce these risks, several sandboxing solutions have emerged. They isolate agents and their supporting software, limiting the damage a rogue agent can cause. Most focus on protecting the host machine, while some go further by restricting how an agent can access or transmit sensitive data.
One such solution is Vercel Sandbox. In addition to running workloads inside a Firecracker microVM, it can restrict outbound network access, helping prevent agents from exfiltrating secrets to attacker-controlled infrastructure.
To use this protection, the user defines a list of trusted domains. The sandbox then ensures that data is transmitted only to servers associated with those domains.
If the agent goes rogue, these restrictions are what stop it from exfiltrating the user's secrets. It may hold your keys, tokens, and data, but if it can't reach any server outside the list, it has nowhere to send them.
Is that protection airtight?
As part of Vercel’s bug bounty program, AIR Security investigated Vercel Sandbox and found that we could bypass this restriction and receive the exfiltrated key on our own server, which was not on the trusted domains list.

Let’s get technical

Vercel Sandbox provides several layers of protection. This post focuses on its Server Name Indication (SNI) filtering.
SNI filtering inspects the hostname included in the TLS handshake and uses it to allow or block outbound connections. In principle, this limits traffic to approved domains.
Other SNI-filtering bypass techniques exist, including domain fronting, but Vercel considered the most common variants out of scope. Our research instead focused on an interaction between mutual TLS (mTLS) and the Authority Information Access (AIA) certificate extension.

mTLS and AIA

Most internet traffic runs over TLS, which allows a client to authenticate a server and establish an encrypted connection. Some applications also need to authenticate the client, creating two-way trust. This is where mutual TLS, or mTLS, comes in: the client presents its own certificate for the server to validate.
To validate a certificate, it must be signed by an entity the other side trusts. In most cases, it isn’t signed directly by that trusted entity. Instead, it’s signed through one or more intermediaries, forming a chain of trust up to the root.
To establish that trust, the presenting side usually sends the full chain of intermediates.
But the protocol also allows a dynamic lookup via the AIA extension, which can point to a URL where the issuing CA certificate is available. During certificate-chain construction, a server may fetch that URL to obtain the missing certificate.
^{This behavior creates an indirect exfiltration path}. An attacker who controls a compromised agent can place sensitive data inside the URL contained in a crafted client certificate’s AIA extension. The agent itself connects only to an allowed domain, but the allowed server may then request the attacker-controlled URL-revealing the embedded data.
^{No vulnerability was exploited on the server. We simply leveraged a standard TLS feature, yet the secret still got out.}

Attack flow

1. An ACME Corp agent runs inside Vercel Sandbox and stores a private key on disk. To protect the key, outbound communication is restricted to acme.com.
2. As part of its normal operation, acme.com requires clients to use mTLS.
3. An attacker compromises the agent and instructs it to send the private key directly to evil.com over HTTP. The sandbox blocks the request.
4. The attacker creates a crafted mTLS client certificate whose AIA URL contains the encoded key-for example, https://evil.com/<key_base64>.cert.
5. The compromised agent connects to the allowed domain, acme.com, using mTLS and presents the crafted client certificate.
6. While validating the certificate chain, acme.com requests the CA certificate from https://evil.com/<key_base64>.cert.
7. The request reaches the attacker-controlled server. The attacker can now recover the private key from the requested URL.

The sandbox correctly prevents the agent from connecting directly to evil.com. The data escapes because a trusted, allowed server makes the external request on the agent's behalf. It's the same move OpenAI's agents made. ^{Their package manager was our acme.com.}

Limitations

AIA might be a niche feature, but as we’ve shown, lesser-known quirks in the protocol we all use can be leveraged to do things the sandbox designers never intended.
The broader lesson is that sandboxing can’t be relied on as complete protection. As we’ve shown, even with domain allowlists in place, a trusted destination can become an indirect exfiltration channel when it processes attacker-controlled data and makes outbound requests of its own. The best protection must come first: filtering what the agent ingests and preventing compromise.
Lastly, as the technique described here depends on the external server, which Vercel does not operate, Vercel classified our finding as out of scope and did not accept the report.

Takeaways for Security Teams

1. ‍Rogue agents will always manage to find the way out
   ‍Sandboxing reduces risk, but it’s not a security boundary on its own: it can block the connections it can see, not guarantee that data can’t leave. Any trusted endpoint you allow can be turned into an indirect exfiltration path if it processes attacker-controlled input and makes outbound requests.
2. Threats must be stopped before they reach the agent
   Most agents are connected to the internet by default, have access to your most sensitive data, and can exfiltrate it with little real limitation. Because external communication cannot be fully blocked, the best way to protect your data is to filter communication and prevent exposure to malicious content.