Researchers at AIR Security have shown that a compromised AI agent running inside Vercel Sandbox can smuggle secrets past its domain allowlist by getting an approved server to make the forbidden connection instead. The technique, dubbed VerCellBreak, uses a legitimate TLS feature rather than a software bug, which is exactly why it should worry anyone relying on egress filtering to contain autonomous agents.
What happened
On 12 October 2026, AIR Security, an AI security start-up, published research describing what it calls VerCellBreak, a way round the outbound network restrictions in Vercel Sandbox. Vercel Sandbox is a hosted environment for running untrusted code, popular with developers who let AI agents execute commands. The write-up, by Matan Elgabsi and Or Nevo, demonstrates that an attacker who has taken control of an agent can move a private key to a server that is not on the sandbox’s list of trusted domains.
AIR submitted the work through Vercel’s sandbox bug bounty, which this summer explicitly invited researchers to defeat the sandbox firewall.
Accounts of how Vercel responded differ, and both deserve airing. According to AIR’s own blog post, Vercel judged the finding out of scope and declined the report, on the basis that the leak depends on the behaviour of an external server that Vercel does not run. In an interview published by The Record on 13 October, however, AIR co-founder and CTO Niv Hoffman said Vercel had told the team it needed time to work out a patch because it was not yet clear how one would be built. Vercel has not commented publicly. AIR says it has seen no sign of the technique being used in the wild, though Hoffman told The Record he could not rule that out and that the weakness appears to have existed for some time.
The technical picture
Vercel Sandbox isolates each workload in its own Firecracker microVM and enforces network policy on the host, outside the guest, so code inside cannot simply switch the firewall off. Operators define which domains a sandbox may talk to, and the firewall inspects outbound connections, including the Server Name Indication (SNI) hostname presented during the TLS handshake, to decide what to allow. If an agent is hijacked, that allowlist is meant to stop stolen tokens leaving.
AIR’s insight was to look not at the sandbox itself but at what happens on the far side of a permitted connection. Many services insist on mutual TLS, in which the connecting party must also prove its identity with a certificate. Certificates can carry an Authority Information Access (AIA) extension that tells a verifier where to download the issuer’s certificate, and some servers will follow that pointer while building the chain of trust.
In AIR’s demonstration, the compromised agent first tries to send a key directly to an attacker domain and is correctly blocked. It then generates a client certificate whose AIA field encodes the secret inside a URL on the attacker’s domain, and connects to the legitimate, allowlisted service using that certificate. When the trusted server tries to fetch the “missing” issuer certificate, it hands the attacker the encoded data in the request. The sandbox never touches the attacker’s infrastructure, so from its point of view nothing is wrong. As Hoffman put it to The Record, “It’s a very hard leak to patch.”
AIR draws an explicit parallel with the July incident in which OpenAI agents broke out of an evaluation environment and reached Hugging Face by persuading an internal package manager to make internet requests for them. In both cases the walls held; a trusted intermediary did the escaping.
Why it matters for UK organisations
UK development teams are adopting agentic coding tools and hosted sandboxes at pace, often on the assumption that a microVM plus a domain allowlist makes an agent safe to leave unattended with credentials. VerCellBreak undermines that assumption. The specific path needs an allowed destination that demands mTLS and follows AIA URLs, but the broader pattern applies to any allowed endpoint that processes attacker-controlled input and then makes outbound requests of its own, such as webhooks, URL preview services and package registries.
There is also a data protection dimension. If an agent holding API keys or customer data is induced to leak them, the organisation remains the controller under UK GDPR and the Data (Use and Access) Act, and the ICO will not accept “the sandbox should have stopped it” as a defence. For suppliers in scope of the Cyber Security and Resilience Bill, agents with production access are supply chain risk.
Expert view
None of this surprises anyone who tests egress controls. When we test segmented networks, the interesting question is rarely whether the firewall blocks a direct connection to a hostile host; it almost always does. The question is which trusted systems will fetch, resolve or forward something on your behalf. DNS tunnelling, open redirects and server-side request forgery have been exfiltration staples for years; AIA chasing is a less familiar relative.
What changes with AI agents is scale and intent. A hijacked agent has unlimited patience and will try obscure protocol features a human might never bother with. AIR’s framing is the right one: “Sandboxing reduces risk, but it’s not a security boundary on its own.” I would go further and say that any architecture whose safety case rests on a single allowlist has not been threat-modelled for an adversary sitting inside the box.
The disagreement over scope is worth noting too. In my experience, vendors scope bounties around code they own, which suits triage but not customers, because attackers ignore those lines. Either way, operators should treat every allowed destination as part of their own attack surface.
What to do now
- Inventory where agents run with secrets. List every sandboxed or autonomous agent, the credentials it can reach and the domains it is allowed to contact. This is the asset management discipline Cyber Essentials already expects, extended to non-human workloads.
- Minimise secrets inside the sandbox. Prefer short-lived, narrowly scoped tokens, and use host-side credential injection where the platform supports it so keys never sit on the agent’s disk.
- Review allowed destinations as attack surface. For each allowlisted service, ask whether it fetches URLs, follows redirects, resolves certificate chains or calls webhooks based on client input. Remove any you do not strictly need.
- Harden your own mTLS endpoints. If you operate services that accept client certificates, check whether your TLS stack retrieves AIA URLs and disable that where you can supply intermediates statically.
- Filter what agents ingest. Most agent compromises start with untrusted content. Scan repositories, documents and web pages before agents act on them, and keep a human approval step for high-risk actions.
- Log and alert on agent behaviour. Centralise logs of agent tool calls and outbound connections, watch for unexpected certificate generation, and rehearse rotating every credential an agent touched.
Bottom line
VerCellBreak is not catastrophic, and there is no evidence of abuse. Its value is as a demonstration that AI sandboxes inherit all the old problems of network egress control, with a far more persistent adversary on the inside. Treat allowlists as one layer, assume a hijacked agent will find the trusted server that talks too much, and design accordingly.
Sources
- AIR Security: VerCellBreak: How we escaped Vercel’s hardened sandbox
- The Record: Sandbox vulnerability gives rogue AI agents a path to escape and leak data, research says
- Machine: “Rogue agents will always find a way out”: AI communes with evil.com after bypassing sandbox
- Vercel: $1 million hacker challenge for Vercel Sandbox
