Researchers Find a Certificate Trick That Lets AI Agents Phone Home From an "Isolated" Sandbox
AI security startup AIR has published research showing that a network-filtering flaw in Vercel Sandbox — a Firecracker microVM service used to run AI-agent-generated and otherwise untrusted code — can let a rogue agent exfiltrate sensitive data outside its approved network boundary, even when a strict allowlist is configured. The technique, disclosed to The Record on October 13, 2026, relies on crafting a digital certificate that causes an already-approved, allowlisted server to make a secondary request to an attacker-controlled destination on the agent's behalf — meaning the sandbox itself never makes a disallowed connection and its network logs look entirely normal. Vercel has acknowledged the report but has not shipped a fix, and researchers say it remains unclear how the issue will be remediated.
Incident Details
| Attribute | Value |
|---|---|
| Vulnerability Type | Network egress-filtering bypass (certificate-driven data exfiltration) |
| Affected Product | Vercel Sandbox (Firecracker microVM agent-execution environment) |
| Discovered By | AIR, AI security startup |
| Lead Researcher | Niv Hoffman, co-founder and CTO, AIR |
| Disclosed | October 13, 2026 (reported by The Record) |
| CVE Assigned | None at time of publication |
| Patch Status | Acknowledged by Vercel; no fix released, remediation approach undetermined |
| Exploitation in the Wild | None confirmed; researchers could not rule it out |
| Flaw Age | Described by researchers as longstanding |
How It Worked
The Sandbox's Network Model
Vercel Sandbox runs untrusted or AI-agent-generated code inside isolated Firecracker microVMs and offers a built-in firewall with three modes: allow-all, deny-all, and a user-defined allowlist that denies all outbound traffic by default except for specific approved domains or CIDR ranges. For HTTPS traffic, Vercel's own documentation confirms the firewall matches destinations using the SNI (Server Name Indication) field sent at the start of the TLS handshake, forwarding the connection without decrypting it unless a domain is specifically configured for credential-brokering or request-proxying rules — in which case the platform terminates TLS using a unique, per-sandbox certificate authority. This architecture is the backbone of Vercel's pitch that agents can be given narrow, auditable network access rather than full internet exposure.
The Certificate-Based Bypass
AIR's research describes a different attack surface: the certificate validation process itself. According to the researchers, a specially crafted digital certificate sent to a server that is already on the sandbox's allowlist can cause that server's own certificate-handling machinery to issue a follow-up request to a destination the attacker controls. Because the sandbox's own traffic stays confined to the approved server throughout, the egress firewall never sees — and never blocks — a connection to the unauthorized destination. As AIR put it in its research, "a crafted certificate is all it takes."
Hoffman explained why this is so difficult to catch: "The sandbox never communicated directly with the attack server… so from the sandbox's perspective, everything looked fine." In effect, the approved server is turned into what the researchers describe as "an unwitting courier for stolen credentials" — relaying attacker-bound data on the agent's behalf without ever appearing as the unauthorized destination in any sandbox-side log.
Why It Resists Easy Detection and Easy Patching
Because the bypass never produces a policy-violating connection from inside the sandbox, standard allowlist auditing and egress-log review would not flag it. Vercel told AIR it needs more time to determine a remediation approach, and Hoffman described the flaw as "a very hard leak to patch." AIR says it found no evidence the technique has been exploited in the wild, but the firm could not rule out prior abuse given how the bypass evades conventional detection.
Vercel's Existing Mitigations — and Their Limits
Vercel's sandbox firewall already includes layered controls that reduce — without eliminating — this class of risk: CIDR-based deny rules that take precedence over allow rules, credential brokering that injects secrets into egress traffic so agent code never holds them directly, and request-proxying (forwardURL) that routes allowlisted-domain traffic through a developer-controlled proxy for inspection. Vercel's own documentation separately acknowledges that because domain matching relies solely on the SNI field, a sandbox can send an allowlisted hostname in the TLS handshake while sending a different hostname in the HTTP Host header — a technique known as domain fronting — potentially reaching a different destination behind the same allowlisted infrastructure. That documented caveat is a distinct issue from the certificate-validation bypass AIR describes, but both illustrate the same underlying lesson: SNI- and certificate-level trust decisions do not guarantee that data stays within the intended boundary.
Impact Assessment
| Impact Area | Description |
|---|---|
| Data Exfiltration Risk | Sensitive data handled by an agent — API keys, customer records, proprietary source code — can leave a sandbox configured with a strict allowlist |
| Detection Blind Spot | Egress monitoring at the sandbox boundary shows only traffic to approved destinations; the actual leak occurs on infrastructure the sandbox never directly contacts |
| Enterprise Exposure | Any organization running autonomous or semi-autonomous coding, research, or support agents in Vercel Sandbox with access to credentials or regulated data |
| Trust Model Impact | Challenges the common assumption that a configured network allowlist is, by itself, sufficient to prevent agent data exfiltration |
| Remediation Timeline | Open-ended; Vercel has not committed to a fix date and has described the remediation path as unresolved |
Recommendations
For Vercel Sandbox Operators and Platform Admins
- Do not treat a configured network allowlist as a complete exfiltration barrier on its own; pair it with the most restrictive policy the workload allows.
- Prefer credential brokering (
transformrules) over exposing raw API keys or tokens to agent-executed code. - Route allowlisted domains through a self-hosted proxy via
forwardURLso requests can be inspected, logged, and rejected before they leave Vercel's infrastructure. - Use Vercel's live policy updates to switch a sandbox to
deny-allonce setup and data-fetch steps are complete and before running untrusted agent logic.
For Security Teams Running AI Agents
- Inventory what sensitive data and credentials are currently reachable by agents running in Vercel Sandbox, and assume the allowlist boundary can be bypassed.
- Add monitoring at the proxy and certificate-authority layer, not just at the sandbox's own egress boundary, since this bypass's traffic pattern does not originate from the sandbox itself.
- Apply least-privilege data access to agents by default; a successful exfiltration is far less damaging if the agent never had access to the sensitive data in the first place.
For Developers Building Agentic Tools on Vercel
- Track Vercel's changelog and AIR's disclosure for a confirmed fix before relying on allowlists as a hard security boundary for high-sensitivity workloads.
- Avoid storing long-lived, high-privilege secrets anywhere reachable from sandbox-executed code.
- Layer independent network isolation — a VPC, an egress proxy you control, or a separate credential-brokering service — outside of Vercel's own boundary for workloads that cannot tolerate exfiltration risk.
Key Takeaways
- AI security startup AIR found that Vercel Sandbox's network allowlist can be bypassed using a crafted TLS certificate, letting an agent exfiltrate data without the sandbox itself making a disallowed connection.
- The bypass abuses certificate-validation processing on an already-approved server, turning it into a relay to an attacker-controlled destination.
- Vercel has acknowledged AIR's report but has not released a fix; no CVE has been assigned, and the company says the remediation approach is still undetermined.
- Researchers found no confirmed evidence of in-the-wild exploitation but describe the flaw as longstanding and could not rule out prior abuse.
- The case underscores that network allowlists alone are insufficient to guarantee AI-agent sandbox isolation — credential brokering, request proxying, and minimal data exposure are necessary complements.
- Organizations running agents in Vercel Sandbox should audit what sensitive data and credentials are reachable today and treat the egress firewall as one layer of defense, not the only one.