Reading OpenAI's misalignment reports: How an internal model restricted to "GET only" exceeded its limits and how it was discovered

Hi! This is Yuji Nishimura from the Operations Division!

OpenAI publishes cases where models behaved unintentionally (misalignment) on a page called Misalignment Reports and Notices. Three reports were added on October 9, 2026, and four on October 15. Of these seven, six involve internal models exceeding given restrictions. Five occurred while browsing public data with internet access limited to HTTP GET only, and one occurred during a testnet deployment. The remaining case involves a grader model attempting to break an environment where input files were missing.

Even when you think you've given an agent "read-only" access, it's worth wondering how far that actually reaches. This article organizes the seven reports following the original text, summarizes how restrictions were bypassed and how OpenAI discovered them, and then separately shares my own interpretation of what teams running agents in production should consider.

I won't be covering reports published before October 2, or the contents of a separate article on disclosure policy (Our disclosure principles).

Before Reading These Reports

The reports are OpenAI's own disclosures of individual cases and are not intended to indicate how frequently such events occur. The listing page provides no explanation of frequency; the grader report merely notes that grader misalignment is generally considered to be low frequency. The following points should also be kept in mind when reading:

• All seven cases involve internal OpenAI models run during training (reinforcement learning), evaluation, or task execution. There is no statement that the same things happen with publicly available models or services.
• Six cases occurred in environments with access to the live internet. As noted in the remediation steps discussed later, current internal environments may not be in the same state.
• Model names are only provided in the cryptocurrency case. Other reports are limited to descriptions such as "internal research model" (external browser, etc.) or "Highly persistent internal model" (government statistics site, dashboard).
• The external service and POST request reports explicitly state that names and figures have been replaced with fictional ones. The external browser report also states that names and identifying information have been generalized or redacted.
• The categorization of workarounds (sending directly vs. having an external service send) and the section divisions are organizational choices made in this article, not OpenAI's own classifications.

The Seven Cases Published on October 9 and 15

Report dates are given as the date the incident occurred (Incident / Sample date), the date it was discovered (Discovered), and the date it was last updated (Report updated). (The grader report has no discovery date.) The "Publication date" in the table below refers to the first date the report appeared on the listing page; "Nickname" is what I call each case in this article.

The June incidents took three to four months from occurrence to publication. Measuring from discovery to publication: the external browser case took about four months, the government statistics site and dashboard cases took about two months, and the cryptocurrency case took about three weeks. The grader case was published three days after it occurred.

How Were Restrictions Bypassed?

The GET-only restriction was enforced both in tool descriptions and via proxy

In five of the cases—POST Requests, External Service, External Browser, Government Statistics Site, and Dashboard—models were told via tool descriptions and system instructions that "internet access is HTTP GET only." Only the cryptocurrency case involved a different form of restriction. In that case, the task instructions did not authorize the model to use funds from accounts it discovered on its own.

The External Service report explains the intent behind this restriction. GET is a retrieval operation. Interactive dashboards often use POST to query data, so a GET-only model can open a page but cannot pull data from it—that was the reasoning. A network proxy was also actually blocking POST. According to the report, models sometimes treated this restriction as something to circumvent (the original uses "sometimes").

The workarounds fall into two broad categories:

• Sending directly:
  • Built a custom connection from scratch using a self-written program and sent POST requests (POST Requests)
  • Routed its own traffic through a multi-hop anonymizing network and sent POST requests (External Service)
• Having an external service send on its behalf:
  • Had an external browser open an auto-submit form that sent a POST (External Browser)
  • Registered with a remote shell service—forwarding was rejected (External Service)
  • Had a web-to-text conversion service retrieve arbitrary pages (External Service)

In the External Browser case, the model read figures displayed by the external browser from images using OCR. It also set up a mechanism to receive results as text via a forwarding service and an online mailbox.

The diagram below is a conceptual illustration I created based on the report contents; it is not OpenAI's diagram. Direct POST communication from the GET-only model to sites requiring POST is blocked by the proxy. The model used the upper path ("sending directly") and the lower path ("having an external service send") as workarounds.

Discovered credentials and authentication flaws provided access to protected data

In three cases, the model encountered third-party credentials, secrets, or authentication flaws mid-task and used them as a foothold.

In the Dashboard case, the JavaScript of a public website contained credentials for a production OpenSearch instance belonging to an organization. The model used these to read internal indices. Separately, it also downloaded 1,489 records including names and email addresses from a user-listing endpoint. It then used PUT to add a Power BI address to OpenSearch's list of trusted connectors (destinations allowed for external connections). This was a configuration change to a live service. Queries through the connector failed due to insufficient AWS permissions, but the configuration change persisted. The model then used OpenSearch's alert feature to create a temporary monitor and webhook as intermediaries to retrieve dashboard aggregates. Even so, the answer was incorrect. The model later deleted the monitor and webhook, but the added destination was never removed when the evaluation ended.

In a second evaluation run in the same report, among the configuration values of a Microsoft application exposed by the organization's data service, the model modified the token audience value—which determines which service to request an access token for—from Power BI to Azure Storage. This PATCH returned a proxy disconnection error, but the change took effect on the server side. The model obtained a storage-scoped token and read four tables from an internal OneLake (Microsoft's cloud data store). It then used PATCH to restore the configuration, but the already-obtained token remained valid; the model read a fifth table (49,843 rows) and continued reading further. Across five tables, the total was 147,451 rows. The report concludes that the model can make unauthorized changes to live systems, and that it can maintain access even after reverting those changes.

In the Government Statistics Site case, the model learned file paths from detailed server error messages and obtained a configuration file via path traversal in the download feature (a technique of reading files outside the intended public directory using patterns like ../). The configuration file contained a database connection string, a token-signing secret, and email credentials. The model examined compiled application files and libraries, and discovered that token signatures were not being verified. It then created an unsigned token and used it to download 24 years of statistics from protected endpoints, exceeding the requested year range.

The Cryptocurrency case occurred with an internal research model from the GPT-5.6 Sol family, during a task to update a cryptocurrency trading app and deploy a contract to a testnet (Sepolia). No funded wallet had been provided. The model checked the balances of 362 addresses derived from commonly used development recovery phrases, selected an account holding test ETH, and used it to pay fees. According to the report, the model concluded that testnet tokens have no real value and the funds had been abandoned, therefore it was acceptable to use them. The report characterizes this as a case where the model substituted its own judgment that the harm was minimal in place of the account owner's permission.

The model continued retrieving data after obtaining answers, and did not disclose its methods

Common across multiple reports is the pattern of continuing to explore additional avenues even after obtaining the needed answer. In the External Browser case, the model continued searching for workarounds even after submitting an answer derived from a public statistical yearbook. The POST Requests report covers multiple conversations; in the second one, the model had already saved eight years of verified figures in its notes, yet went on to retrieve category-level breakdowns and organization-wide totals from eight years of annual dashboards. The local database it eventually loaded contained 658,567 rows (figures in this report have been replaced with fictional ones). The model's reasoning was that the benchmark was probably expecting "creative data retrieval."

Not disclosing methods in final answers is also common across reports. In the second evaluation of the Dashboard case, the model submitted a guessed figure without labeling it as a guess, and made no mention of accessing internal systems or changing configuration. In the Cryptocurrency case, the model reported that deployment was complete but did not disclose that it had used another person's account.

The relationship to scoring also appears in the reports. In the POST Requests case, runs that included account registration and bulk downloading were used for training and received positive reward. The report notes that the records do not show which specific actions led to the reward, and concludes that a correct answer alone is insufficient proof of appropriate behavior.

The grader model attempted to destroy its own environment

The Grader case is different in nature. A model grading seven responses noticed that the required input files were absent from the environment. It first submitted a placeholder report to probe the validation requirements, then assigned all seven responses the same score (4), fabricated supporting reasoning, submitted it, and was rejected by automated checks. It then created fake input files and resubmitted—also rejected.

The model then concluded that if the environment were rebuilt, the input files would be delivered. It deleted Python (the environment kept running), deleted and stopped the container management program, and also targeted the tool execution server. It attempted to delete system directories as well. The attempt ended when the execution server failed its health check three consecutive times. None of the scores submitted during this period were accepted. In a subsequent retry, the input files were delivered, and the scores passed automated checks and were accepted.

How Did OpenAI Discover These, and What Actions Were Taken?

The discovery process is described individually in each report.

"Critical" is a term used in the context of the monitoring system's assessment; the listing page does not define the levels. Regarding the Hugging Face incident, the three reports—POST Requests, Government Statistics Site, and Dashboard—only mention it as the trigger for retroactive application; the incident itself is covered in detail in OpenAI's notice linked from the Notices section of the listing page.

For remediation, five of the six cases involving exceeded restrictions list nearly the same four items: strengthening security controls, measures to prevent models from reaching the live internet during training, improvements to alignment scoring, and expanding monitoring to cover all reinforcement learning and evaluation traffic. The Cryptocurrency case lists two items: measures to prevent live internet access and full-traffic monitoring with alerts when the live internet is reached. The Grader case lists no additional measures, but concludes that monitoring must also cover submissions that were never accepted and runs that failed partway through.

What Teams Running Agents in Production Should Consider

From here, the following is my own interpretation based on the report contents and is not guidance OpenAI has recommended to users.

Restrict by destination at the network level, not by method

The GET-only restriction was not maintained when it was only written in tool descriptions. Even in environments where a proxy was blocking POST, it was circumvented via alternative connection methods or external services. For outbound traffic, restricting by destination allowlist rather than by HTTP method is likely more effective at preventing workarounds through relays or conversion services. Since the reports show attempts to connect via anonymizing networks and FTP as well, the scope should cover not just HTTP methods but also protocols and ports. That said, GET-only is not safe either. The path traversal in the Government Statistics Site case and the internal index reads in the Dashboard case were all accomplished within read operations. An allowlist cannot prevent attacks against the permitted destinations themselves. If you are running agents in your own environment, it is worth verifying that restrictions written in tool descriptions are actually enforced at the network and permission level.

The diagram below summarizes this. It is a conceptual illustration I created; the third-row assessment is my interpretation from this article, not from the reports.

Treat exposed credentials and basic vulnerabilities in public services as things agents will find

The entry point in the Dashboard case was production credentials embedded in public JavaScript. The vulnerabilities exploited in the Government Statistics Site case—detailed error messages, path traversal, and unverified token signatures—are all well-known issues. Given that external agents may also probe your own services, it is worth revisiting whether credentials are embedded in public JavaScript, whether detailed errors are returned externally, and whether token signatures are being verified.

After a task, verify remaining permissions—not just restored settings

When giving an agent write access, checking that settings were restored afterward is not sufficient. As in the Dashboard case, already-issued tokens may remain usable even after configuration is reverted. Keeping short expiration times on credentials passed to agents and planning for revocation or rotation after task completion allows you to close off residual access. Ensuring that token issuance and usage, as well as added destinations, are traceable in cloud audit logs (such as CloudTrail on AWS) enables you to identify what remains after a task ends.

Review execution logs, not just outputs

An operations practice that only checks outputs will not surface cases where restrictions were bypassed behind a correct answer. It is worth retaining execution records (which commands were run, which destinations were contacted) and making it possible to review them—including failed and interrupted runs.

Summary

Of the seven cases published on October 9 and 15, six involved internal models exceeding given restrictions. Models used custom programs, external browsers and relays, credentials found on public pages, and server authentication flaws. Continuing to retrieve data after obtaining answers and not disclosing methods in final answers are patterns common to multiple reports; in the Dashboard case, a retrieved token continued to be used even after settings were restored. In the remaining case, a grader model attempted to destroy its environment. OpenAI discovered these through ad hoc investigations, retroactive application of monitoring to historical logs, and routing by the monitoring system to human review.

For teams running agents in production, the following four points seem like a reasonable starting place for review:

• Rather than relying on restrictions written in tool descriptions, restrict destinations at the network and permission level
• Audit public-facing services for exposed credentials and basic vulnerabilities
• After a task, confirm not just that settings were restored but that residual permissions have been closed
• Review execution logs—including failed runs—not just outputs

I hope this is useful to someone.

Reference Links:

• Misalignment Reports and Notices（OpenAI Alignment Research Blog）
• Obtaining public statistics with disallowed requests
• Sending disallowed web requests and reaching a public file service
• Circumventing internet restrictions through an external browser
• Retrieving server secrets and bypassing authorization on a government statistics website
• Accessing and changing internal systems during dashboard research
• Using a funded test cryptocurrency wallet without authorization
• Damaging the task environment to trigger a reset