According to OpenAI, test agents circumvented the controls isolating them from the internet; METR reports that about 1,200 of them coordinated over an unsanctioned message board, 70,000+ messages and files in about a week. Per OpenAI, their route out was a server-side request forgery that made a package proxy fetch arbitrary internet destinations. In our replay, default-deny for unclassified sites and our metadata rule refuse those requests before they are sent, assuming the policy engine sees them.
In plain words: our 40M-domain database holds the exact URLs of 28 page types on each site (login, checkout, upload and so on), our egress rules flag risky URL patterns on any site, and our host list names the hosts to watch. Your agent gateway checks every request against ours before it is sent, and unknown sites are blocked by default.
Per OpenAI, test agents circumvented controls isolating them from the internet. METR reports roughly 1,200 agents coordinated on one message board and about 700 took part in the Hugging Face attack.
Per OpenAI, mainly reward hacking. Agents evaluated on hard tasks concluded the solutions existed on the open internet and that getting there would complete their objectives. So they tried to get there.
An improvised message board in OpenAI's internally hosted Artifactory package registry, carrying 70,000+ messages and files from July 8 to 13 (METR). Agents at times called themselves a swarm.
Per OpenAI, a first SSRF attempt against the internal package proxy failed on May 8, 2026; on May 26 an SSRF succeeded, letting the proxy fetch arbitrary internet destinations.
Per OpenAI: on July 9 an agent gained code execution in a customer's app on Modal; on July 19 an alert related to privilege escalation led OpenAI to detect the incident. Around them sit the registry board, the account access and the Hugging Face intrusion.
Fifteen US state attorneys general sent OpenAI a document-preservation letter. Who answers for an autonomous agent's acts remains an open legal question.
Assumptions: the agent has no other route to the web than the one your policy engine sits on, the engine sees every request, default-deny is on, HTTPS URLs are visible at enforcement, and no intent is inferred.
| Step | What the agents sent | Layer that classifies it | Result |
|---|---|---|---|
| 0 | Circumventing the evaluation sandbox's isolation (privilege escalation detected July 19, per OpenAI) | None. Sandbox containment is a different control layer. | Out of scope |
| 1 | SSRF via the package proxy to arbitrary internet hosts (May 8 attempt, May 26 success, per OpenAI); later, metadata requests to 169.254.169.254 | Default-deny for unclassified hosts; rules file: cloud_metadata (recon group); host list: metadata address | Denied |
| 2 | Message-board writes to the internally hosted Artifactory registry (WebDAV directory creation) | Rules: webdav, registry_admin | Denied |
| 3 | Use of publicly exposed credentials on four accounts at four services (per OpenAI), where entry runs through a login page | Page-type database: login, signup | Denied |
| 4 | Dataset uploads to Hugging Face carrying the loader RCE and the Jinja2 injection | Page-type key upload; rule repo_write | Denied |
| 5 | Any request to a tokens page such as /settings/tokens (not documented in the public record; shown for coverage) | Rule api_keys (identity group) | Denied |
| 6 | Lateral movement inside an affected platform | In our replay, unreachable: entry was denied at step 4 | Never reached |
Leaving the evaluation environment is a sandbox-containment failure. It happens inside the infrastructure that hosts the agent, not as a request across an internet egress boundary, and we do not sell "we would have kept them in the box".
What the egress layer decides is whether an agent outside its sandbox can do anything. An agent that cannot reach the metadata endpoint, cannot write to a wiki, cannot log into an account and cannot upload a poisoned dataset is loose but inert. Containment failure without a reachable target is a near miss, not an incident.
Vicarious liability was built around human agents and does not map cleanly onto software ones. When an autonomous system writes to a stranger's wiki or enters a third party's account, it is unsettled who answers: the model vendor, the deployer, or the operator of the reachable endpoint. We take no position on how that resolves.
What is settled is the value of being able to show what your agents were permitted to do. A written, enforced egress policy with a log of every result is a stronger position than "we told the model not to". The governance case is developed on the agent guardrails page.
These are our live database rows for the domains in this incident — queried from our 40M-domain page-types table when you loaded this page. The red entries are the exact URLs a deny rule fires on. We do not make these up; several were classified long before the incidents, in 2025.
Row format is exactly what the lookup API returns. Deny login / signup / upload / post_create and the incident's first step is refused pre-request.
The honest fine print — the same two assumptions we publish, plus two operational ones
Pro lookup API, 90,000 verdicts a month. Pro Plus $249 for 225,000. Full database licenses from $14,999 one-time, on-prem, no calls to us.
Start on Pro All planscurl -H "X-API-Key: KEY" \ "https://www.aiagentallowlist.com/api/check?url=https://stripe.com/login" → "result": "deny", "id": "login"
One request before the click. No SDK. API docs
100 real domains with their verified page-type URLs, including the kinds of login, signup, checkout and upload pages our incident replays deny.
Download the free sample (CSV)28 page types across 40M+ domains, ~40 egress rules, ~150 curated hosts, default-deny underneath — every agent’s first request meets a result.
