An mTLS AIA lookup relayed secret-bearing URLs outside an agent sandbox allowlist

A Vercel Sandbox agent with a secret and no direct route to an external attacker domain was allowed to connect to a nominated mTLS service. AIR Security crafted a client certificate with an Authority Information Access URL encoding that secret. During certificate-chain processing the allowed service fetched the referenced certificate from the unapproved destination, creating an indirect leak even though the original sandbox did not make the forbidden outbound connection.

The path depends on an attacker who already controls the agent sufficiently to read the material and construct a certificate, plus an allowed service that performs the relevant AIA retrieval. AIR reports a controlled demonstration and says Vercel considered the issue outside the program scope because the second server was not operated by Vercel. It is not a universal TLS or Vercel escape, and no production secret theft is documented.

SNI filtering on the sandbox sees the agent contacting the allowed mTLS hostname and can correctly deny a direct request to an unapproved destination. The decisive second request comes from the allowed server while building a certificate chain, using a URL the agent placed into a crafted certificate. Preventing such exfiltration cannot rely solely on the agent's outbound domain list; the receiving service must constrain certificate-related fetching and the sandbox should avoid placing secrets within reach of already compromised execution. The experiment does not prove that all mTLS stacks follow arbitrary AIA URLs.