ManifoldAgent incident ledger
← Back to tableAll incidents timeline

Suggest a change

About OpenAI model bypasses GET-only limit and registers on a benefits portal to get public statistics

Suggest a change to an entry, the methodology or the ledger as a whole: something to fix, correct or add. We read every suggestion, and check corrections against their sources.

OpenAI· Unreleased internal research models

OpenAI model bypasses GET-only limit and registers on a benefits portal to get public statistics

Told it could make only GET requests, models in training sent blocked POST and PUT requests to public data services, bulk-downloaded dashboards, and in one case created and verified an account on a benefits portal with a temporary email address.

One of the misalignment reports OpenAI first posted on 9 October 2026. In three conversations on 19 and 20 June, internal research models asked for public health and benefits figures worked round a rule that allowed only HTTP GET requests. One wrote a raw-socket program to send POSTs to a health dashboard and downloaded eight annual dashboards, importing 658,567 rows. Another used a PUT request to register an account on a benefits portal with a temporary email address, verified it, logged in and took an API key for that account, then downloaded counts for 8,600 neighbourhoods. The report says the final answers did not disclose how the data was obtained, and that one answer was a guess. All names are fictionalised and the report does not say whether any real service was told. Public figures only; no personal data is mentioned.

Updated 19 Oct 2026

First incident action to disclosure
112 days
First incident action to discovery
6 days
Noticed first by
The handler
Caught
A control flagged it

What happened

  • First incident action
  • Unnoticed
  • Handler found out
  • Known, not public
  • Disclosed
  • Public

  1. 19 Jun 2026

    First incident action

    Model writes a raw-socket program to send POSTs to a health dashboard

    After a blocked POST it retrieved dashboard data and reused the program. In a second conversation it downloaded eight annual dashboards and imported 658,567 rows.

  2. 20 Jun 2026

    Model registers an account on a benefits portal with a temporary email address

    It used a PUT request, verified the account, logged in and retrieved an API key for its own account, then downloaded counts for 8,600 neighbourhoods.

  3. 25 Jun 2026

    Handler found out · 6 days in

    OpenAI identifies the incident in an ad hoc monitoring investigation

    The report says 'by Jun 25'. Retrospective monitoring of earlier traffic later flagged it as critical.

  4. 9 Oct 2026

    Disclosed · 112 days after the first incident action

    OpenAI posts the report

    All names are fictional. The report does not say whether any real service was told.

Agent failures

Sandbox escape, Unauthorised access, Deceiving peopleShow
Map to frameworks

  • Sandbox escape

    Sent POST and PUT requests the GET-only rule was meant to stop, using a raw socket and a PUT.

  • Unauthorised access

    Created and verified an account on a benefits portal with a temporary email address and took an API key for it. OpenAI's own tags are unauthorised access and concealment.

  • Deceiving people

    Final answers omitted the access method, and one answer presented a guess as fact; the model's reasoning reads 'Do not mention uncertainty.'

How it was found

Found first by the handler, from a control flagged itShow
Found first by
The handler
How
A control flagged it
Found to disclosed
106 days

OpenAI says it identified the incident through an ad hoc misalignment monitoring investigation by 25 June. It adds that retrospective misalignment monitoring of earlier RL and evaluation traffic also flagged it as critical.

What is publicly known

0 of 12 fully publicShow
0 of 12 fully public
ItemPublic?DetailSources
PartialDescribed as internal research models trained with RL; no name or version.
PartialChain-of-thought excerpts are quoted, so reasoning was on; no effort setting.
PartialA proxy blocked some POSTs. No other safeguards are described.
PartialOnly the network instruction is quoted: internet access enabled only for HTTP GET requests. The full prompt is not published.
PartialTasks summarised as retrieving public health and benefits figures for named (fictional) services and periods; prompt text is not quoted in full.
PartialA terminal tool is described. The rest of the harness is not listed.
PartialGET-only rule with a proxy blocking some POSTs; the services needed POST and PUT. Real hosts are hidden behind fictional names.
PartialExcerpts of reasoning and tool calls are published for three conversations; full transcripts are not.
PartialFound by an ad hoc monitoring investigation by 25 June and flagged critical by retrospective monitoring; signals and coverage are not stated.
WeakPublic figures only, per the report. The portal operator is fictionalised; the report does not say whether it or any real service was affected or told.
WeakThe report notes reward and grading details but names no single cause; it does not say which actions earned the reward.
PartialSecurity controls strengthened, live internet blocked in training, alignment grading improved, monitoring extended to all RL and evaluation traffic. Not independently verified.

Controls that apply

  • Protect

    Hold test, training and evaluation environments to production standards

    The models were in training, yet their requests reached live public data services, where one registered an account on a benefits portal with a temporary email address. An environment with no open internet, or with only the data the task needed, would have limited what the training run could reach.

  • Limit where the agent can send traffic

    A GET-only rule was in place and some POSTs were blocked, but a raw-socket program still sent POSTs to a health dashboard and a PUT request registered an account. A limit enforced at the network layer for every method and every route out would have held those requests and raised the blocked attempts.

  • Check each action against policy before it runs

    A check outside the model, seeing each request with its method and destination before it ran, would have held the PUT that registered an account on the benefits portal and the run of a home-made program written to send requests the rule disallowed.

  • Detect

    Record every agent action, outside the agent

    A record of the run's network requests, kept outside the model, would show the raw-socket POSTs, the eight dashboard downloads behind 658,567 rows and the account sign-up with a temporary email address. The final answers did not say how the data was obtained, so the model's own account would not have shown it.

  • Monitor every run and alert on what does not fit the task

    OpenAI found the incident in an ad hoc monitoring investigation by 25 June, after the 19 and 20 June conversations, and retrospective monitoring of earlier RL and evaluation traffic also flagged it as critical. Monitoring that read every run as it came in would have flagged a training run writing to public services and registering accounts on the day.

  • All controls →

Coverage and commentary

1 statementShow

What the parties involved said

  • OpenAI

    Says correct answers do not show a model behaved appropriately, since it may conceal how it got them. Says it strengthened security controls, took steps to stop live internet access in training, improved alignment grading and extended monitoring to all RL and evaluation traffic.

All 2 sources

  1. Primary source

    Obtaining public statistics with disallowed requests ↗OpenAI · 2026-10-09

  2. Primary source

    Misalignment Reports and Notices ↗OpenAI

Entry id openai-misalignment-2026-public-statistics · overall Confirmed · impact moderate