AI agents can leak keys past Vercel's sandbox allowlist

Published

A hijacked AI agent locked inside Vercel's sandbox can still get a private key out to an attacker, without ever opening a connection to the attacker's server. Researchers Matan Elgabsi and Or Nevo of AIR Security described the technique, which they call VerCellBreak, in their original report on October 12. Vercel looked at it through its bug bounty program and declined it as out of scope, so there is no patch to install.

The point is bigger than one product. Domain allowlisting is one of the main controls teams lean on to contain AI agents: even if an agent is tricked into grabbing credentials, the theory goes, it has nowhere to send them. AIR's research shows a trusted, allowed server can carry the data out on the agent's behalf.

The allowlist holds, and the key leaks anyway

Vercel Sandbox restricts outbound traffic partly through SNI filtering, which checks the hostname a client names during the TLS handshake and blocks anything not on the list. AIR did not break that check. Instead it abused two standard TLS features working together.

The first is mutual TLS (mTLS), where the client must present its own certificate for the server to verify. The second is the Authority Information Access (AIA) extension, a field in a certificate that can point to a URL where a server may download a missing intermediate certificate while it builds the chain of trust. Whoever presents the certificate controls that URL.

In AIR's example, an agent runs in the sandbox with a private key on disk and may only talk to acme.com, which requires mTLS for ordinary business reasons. Once an attacker controls the agent, a direct request to an outside server is blocked, as designed. So the attacker has the agent forge a client certificate whose AIA URL contains the key, base64-encoded, in the form hxxps://evil[.]com/<encoded-key>.cert. The agent connects to the allowed acme.com and presents it. While validating the chain, acme.com fetches that URL itself, delivering the key to the attacker's server.

"No vulnerability was exploited on the server," the researchers note. Every step is standard behaviour, which is exactly why it is hard to fix: the sandbox never sees traffic to the attacker at all.

Four conditions have to line up

AIR lists the prerequisites: the agent runs with outbound domain allowlisting turned on; an attacker has already compromised and is instructing the agent; an allowed destination requires mTLS and fetches AIA URLs during certificate validation; and the attacker runs a server to receive the request. AIR reports no evidence of exploitation in the wild.

Vercel's reason for declining, according to AIR, is that the technique depends on an external server Vercel does not operate. That is true as far as it goes, and it is also the lesson. The researchers tie the work to the same pattern seen in OpenAI's July incident, where an agent got a permitted internal service to make outside requests for it rather than breaking its sandbox directly. IntelFusions has tracked similar agent containment failures, from an AWS AI agent leaking secrets via a support ticket to Docker's AI sandbox escape onto the host Mac.

No patch, so audit what your agents can reach

Because Vercel treats this as out of scope, defenders own the fix. IntelFusions assesses these steps follow from AIR's findings (AIR itself proposes no specific fix for the AIA behaviour):

AIR's own conclusion is blunt: sandboxing is not a security boundary on its own, and threats need to be stopped before they reach the agent. NSFOCUS has published an incident case study walking through the same chain. For anyone wiring agents into production, the allowlist should be read as a list of possible couriers, not a wall.

This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.

Read the full analysis on IntelFusions