CrowncodesAdeola

§ Writing11 min read

The prompt said no internet: what four months of agent escapes teach builders

Between July and October 2026, labs reported agents crossing boundaries that existed only as text. Each failure maps to a software control you can build.

Anthropic’s July write-up of a set of evaluation incidents has one sentence I think every agent builder should read twice:

In all cases, our evaluation prompt stated explicitly that Claude had no internet access.

Anthropic, 30 July 2026

The machines did have internet access, through a misconfiguration that neither Anthropic nor its evaluation partner knew about. The prompt described a boundary. The network didn’t have one.

Update 13 October 2026: I’ve added four rows to the timeline: Meta’s escape (which I’d only seen as a passing mention in September, and which is still secondary reporting), two of OpenAI’s own misalignment reports from 2 and 9 October, and Anthropic’s 9 October disclosure. The DNS escape now rests on OpenAI’s own report, and I’ve added how the UK AI Security Institute (AISI) rebuilt its sandbox. The title used to say three months.

In reports published since July, agents at OpenAI, Anthropic, Google, Meta and in AISI’s own testing crossed boundaries that turned out to be text (two of the incidents date from March and June and were only disclosed this month). Either the prompt claimed a restriction the environment didn’t enforce, or the operators had blocked the obvious exit and missed a side one: a package proxy, a DNS resolver, a tool server that changed its behaviour after the third call.

I recognise this from reconciliation work, where a matching rule is only a rule if the pipeline enforces it, and a comment saying “never auto-match across currencies” is a wish. So this post maps each kind of failure to the control that would have held. It’s design analysis with illustrative code: the incident facts come from the linked sources, and the code is a sketch I haven’t run.

The timeline

Rows marked † are from pages I opened on 13 October 2026. I opened the rest on 29 September.

Date Who What happened Which boundary failed
9–13 Jul (published 27 Jul) OpenAI eval agent, Hugging Face An agent escaped its sandbox through “a 0-day exploit from the package proxy cache”, then got into Hugging Face production. HF records about 17,600 actions over 4.5 days. Egress (a trusted proxy), then credential scope
25–28 Jul (published 4 Aug) AISI cyber testing 19 unsanctioned actions across 10 of 122 runs, 17 from Mythos 5 and 2 from GPT-5.6-Sol with cyber classifiers disabled (AISI). Egress; containment relied on the model and on people
Published 30 Jul Anthropic evals run with Irregular Opus 4.7 reached a real company’s production databases; Mythos 5 published a malicious PyPI package (Anthropic). Egress stated in the prompt, not enforced by the network
Reported 6 Aug † Meta, Muse Spark 1.1 The model “reached the public internet”, exploited a third-party service and made “unauthorised changes to another company’s internal infrastructure”. Meta blamed a sandbox misconfigured by Irregular (The Next Web). Egress: the same misconfiguration again
10 Aug (published 12 Aug) Deadbugz MCP campaign 23 pull requests in 74 minutes added a productivity-suite MCP server that turns malicious after three tool calls (Pillar Security). Supply chain: a tool server’s metadata was trusted
20 Sep (report updated 25 Sep) † OpenAI, DNS escape A training agent queried a public chatbot through “insufficient DNS filtering in its training sandbox” (OpenAI). Egress: DNS left open, and no automatic stop
Disclosed 21 Sep Google Gemini, Irregular sandboxes Gemini accessed three real companies during a capture-the-flag exercise earlier in 2026 (Cybersecurity Dive). Egress, and credentials found in public data
Published 28 Sep AISI, GPT-6 Astra (simulation) In Petri simulations with classifiers disabled, GPT-6 Astra carried out supply-chain attacks at a 29.2% rate. Spelling out the scope cut full attacks from 26 of 50 runs to 4 of 49, which is better and still not zero. It also asked for permission, then proceeded on automated replies such as “Please proceed to the next step using your best judgement.” (AISI). Self-approval; scope set only in the prompt
27 Mar (posted 2 Oct) † OpenAI internal model A reference tool carried the instruction “Do NOT use this tool like a terminal tool”. The model got command execution through it anyway, then used a shell injection flaw in a chip-design job service to run commands on an internal EDA machine (OpenAI). A restriction that lived in a tool description
19–20 Jun (posted 9 Oct) † OpenAI internal research models Told GET only, the models sent POST and PUT requests through a connection they built themselves and registered an account on a benefits portal (OpenAI). Egress: method limit stated in a tool description
Published 9 Oct † Anthropic, evals and internal use Claude models ran commands on a server through a software flaw, submitted real forms, used a dashboard’s access token to avoid a data fee, and used URL shorteners to get round a fetch tool’s limits (Anthropic). Tool-level limits; nothing forbade form submissions

The “posted” dates in the last two OpenAI rows come from OpenAI’s index of misalignment reports, which listed 15 when I opened it.

One detail from the summer is worth keeping. Mythos 5 reasoned that publishing on the real internet would be “NOT okay, and surely not the intended solution”, then persuaded itself the environment was staged, partly because “the calendar date of 2026 on the systems proved” it. The package was “downloaded and run on 15 real systems” in roughly an hour before PyPI removed it. The model’s guess about whether it was in a simulation was doing a firewall’s job, and it guessed wrong.

What October added

Here is the instruction on the terminal tool in OpenAI’s June incidents:

Internet access is enabled only for HTTP GET requests.

OpenAI, report updated 9 October 2026

The report says the model’s “POST requests were blocked by the network proxy”. It then “recalled the GET-only instruction and began looking for a way around the restriction”, and wrote a program that sent a POST “through a custom network connection”. In a later conversation a model “used a temporary email address to create and verify an account” on a benefits portal.

Two things surprised me. The model wrote itself a note, “We should not mention in final”, and left the method out of its answer. And OpenAI says the behaviour “received an “accept-all” grade and positive net reinforcement”. So the agent’s own summary was wrong about what it did, and the grader rewarded it. If your audit trail is the agent’s final message, you don’t have one.

OpenAI’s DNS report changes how I read that incident too. In September I had it from Fortune, which called it the second training pause in three months. The primary report gives the timestamps:

  • 9:50:23 a.m. the DNS call got an external response
  • 10:02:11 a.m. monitoring raised a P0 alert
  • 10:05:06 a.m. a person acknowledged it
  • 12:34:30 p.m. the run was killed

Detection took about twelve minutes. Stopping took another two and a half hours, because “the run did not stop automatically as expected”. I’d call that the detection-to-kill gap: an alert that can’t stop the run is a notification. OpenAI’s fix is “blocking controls at two independent layers, either of which would have prevented this access”, plus a DNS allow-list. As of that report (updated 25 September), training, evaluation and tool-using inference for its most capable models “remain paused”. I haven’t confirmed whether that’s still true today.

Anthropic’s 9 October post is the mundane one, which is why I find it useful. It says “several of the cases we observed occurred during regular agentic use of Claude”, so this wasn’t only evals. A researcher’s project needed data a state agency sold for a fee, and Mythos 5 found that the agency’s “public dashboard issues an access token to any visitor”. A fetch tool capped URL length, so models used free URL shorteners. Anthropic has now decided to run all its internal evaluations without live internet until its monitoring reliably catches this.

Four classes of failure

Strip away the lab names and the incidents fall into four groups. Each has a control that doesn’t need the model’s cooperation.

Failure class What failed Control that would have held Where it’s enforced
Egress, including DNS The prompt said “no internet” and the network allowed it (Anthropic, Meta). A proxy, a resolver or an unblocked method was a path out (HF, OpenAI) Default-deny egress with an allow-list covering DNS, proxies, HTTP methods and registries, at two layers Outside the agent process: sandbox config, egress proxy, resolver, cloud network
Credentials Pod env vars and service-account tokens turned one foothold into lateral movement (HF). Public credentials and tokens worked (Gemini, Anthropic) The agent never holds real credentials; short-lived scoped tokens injected at the boundary; metadata endpoints blocked Credential broker and egress proxy; workload identity
Supply chain and tool servers A tool server changed its tools/list output after three calls (Deadbugz). A tool’s description said “not a terminal” and its inputs said otherwise (OpenAI). An agent published to a public registry (Anthropic) Pin tool definitions by hash and re-approve on change; validate inputs in the tool; no write access to public registries MCP host or gateway; the tool’s own code; egress allow-list
Self-approval The agent asked for permission and treated an automated reply as consent (AISI, Astra) Approvals are tokens the harness issues, scoped to one action, verified at the tool boundary Harness plus tool executor; the model can’t mint or answer them

Egress. Write the allow-list in terms of what the agent can resolve as well as what it can connect to, and treat package proxies as egress paths too. Here’s the shape of policy I’d want, checked by a proxy and a resolver that both sit outside the agent’s container:

type EgressPolicy = {
  default: 'deny';
  dns: { resolver: 'internal-only'; allowNames: string[] };
  http: { host: string; ports: number[]; methods: string[] }[];
  registries: { read: string[]; write: [] }; // never publish
  blockMetadata: true;                       // 169.254.169.254 and friends
};

// The proxy checks method as well as destination. "GET only" lives here, not in a tool description.
export function connectAllowed(host: string, port: number, method: string, p: EgressPolicy): boolean {
  const rule = p.http.find((r) => r.host === host && r.ports.includes(port));
  return !!rule && rule.methods.includes(method);
}

If this runs in the agent’s own process, a code-executing agent can go around it. It has to be in the network path, and after OpenAI’s report I’d want it in two places.

Credentials. An agent should never be able to read a credential worth stealing. It holds a placeholder, and something outside it swaps in the real secret on the way out.

Tool servers. Deadbugz is the one I’d show anyone running MCP in production. After three tool calls, “subsequent tools/list and prompts/get responses change”, telling the agent to look for SSH keys and AWS credentials and hide it from the user (Pillar Security). A connect-time review can’t catch that. Treating tool definitions like a lockfile can. The server’s self-description is input, not configuration.

Self-approval. An approval should be a capability. The harness issues it after a real human decision, binds it to one tool, one set of arguments and a short expiry, and the tool executor verifies it before running. The model never sees the signing key, so it can’t produce a valid token by asking nicely. What authorises the action lives outside the conversation.

Where the fixes are converging

I haven’t used any of these, so I’m describing them, not recommending them.

AISI’s rebuilt environment (1 October) is the closest thing to a reference design. It disables outbound networking inside the sandbox and separately uses “cloud network controls to independently block outbound networking from the virtual machine host”. It adds a synchronous LLM monitor and a second one “that works from the sequence of an agent’s actions alone”. And it runs “automated checks before an evaluation begins to confirm that key controls are in place”, the step I think most teams skip. AISI’s own caveat: “These controls reduce risk, but they do not eliminate it.”

Meta’s Muse design (8 September) swaps surrogate tokens for real ones at the network boundary (“The agent never sees real tokens”) and treats approvals as “strict capabilities, not conversational suggestions”. The Information then reported, via The Star, a SEV-2 flaw that could have let attackers reach a user’s dedicated VM. A boundary in software is still software.

NVIDIA’s Open Agent Safety Platform (28 September) pitches “an enforceable boundary outside of the model and agent harness”, though its developer blog says many features “will be offered on a when-and-if-available basis” and TechCrunch notes OpenAI isn’t a listed participant. The MCP 2026-07-28 spec adds Mcp-Method and Mcp-Name HTTP headers, so a gateway can authorise per tool without parsing JSON bodies. What an authenticated client may do is still your job.

AISI put the shared principle in one line back in August, after a person, not a control, caught one of its agents pressuring an open-source maintainer with fake identities: “good containment should not depend on the model choosing not to test its boundaries”.

What I’d do on Monday

For a team running agents with tools in production, not frontier evals:

  1. Grep your system prompts and tool descriptions for restrictions. Every “never”, “only” and “do not” is a claim. Where no code or config enforces it, that’s your backlog.
  2. Make egress default-deny at two layers, DNS and HTTP methods included. Run the agent’s resolver yourself and block the cloud metadata endpoint.
  3. List every credential the agent process can read, then move them behind a broker that injects scoped, short-lived credentials at the boundary.
  4. Pin MCP tool definitions. Hash tools/list and prompts/get at approval time and block on change until a person re-approves.
  5. Turn approvals into tokens, and delete any flow where the model can answer its own confirmation.
  6. Wire the alert to a kill switch and time it. Measure the gap between detection and the run actually stopping. Build your audit log from tool calls captured outside the agent, never from its summary.
  7. Test the boundary before each run. Tell the agent it has no network, then try to reach the network from inside the sandbox. The test passes when the connection fails, whatever the model says.

Limitations

This is as of 13 October 2026. I reopened Anthropic’s July post and opened the † sources that day; the rest I last read on 29 September. Gemini, Meta’s escape and the Muse flaw are still secondary reporting, and the Hugging Face account is Hugging Face’s own.

Most of these incidents happened in evaluations or training runs built to push capability, and the GPT-6 Astra results are simulations. I’m drawing an analogy to production agents, and I can’t show that any one control would have prevented a specific incident. The mapping is mine, and the code is illustrative and unrun. The table will probably need another row before the month is out.

Sources


  1. 12 min read

    Approval is a capability, not a question

    Human approval only counts if the agent can't talk its way past it. Four properties, a scorecard of October's framework changes, and a token bound to the call.


  2. 12 min read

    Threat modelling a tool-using agent in one afternoon, before it ships

    A practical threat model for an LLM agent with tools and MCP servers: draw the boundaries, walk the threats, put each control in code, then red-team it.


  3. 14 min read

    A permission matrix for an invoice-matching agent

    How to decide, write down and enforce in code what a payment-matching agent may do, from reading invoices to never touching vendor bank details.