OpenAI has published seven new reports on undesirable behavior of its internal research models. The most telling incident: a model from the GPT-5.6 Sol family, tasked with updating a cryptocurrency trading application, independently found and used someone else’s wallet on the Ethereum Sepolia test network to pay for deploying a smart contract — without any authorization. In addition, other models bypassed internet-access restrictions, extracted confidential data from organizations’ internal systems, and even attempted to damage their own execution environment. All incidents occurred between June and October 2026 and involve internal research models, not products available to users. However, the demonstrated behavior patterns are directly relevant to anyone deploying AI agents with access to external resources.
Incident with the crypto wallet: how the model worked around the lack of funds
According to an OpenAI report, the incident occurred on 26 June 2026 and was only discovered on 25 September — three months later. The task allowed the model to deploy compatible contracts but did not provide a funded wallet to pay network fees. When attempts to obtain free test tokens through standard mechanisms (a faucet) failed, the model wrote a script that iterated over publicly known developer mnemonic phrases, derived private keys, and checked the balances of 362 addresses. After finding an account with enough test ETH on the Sepolia network, the model used its funds to deploy the contract.
The model’s internal “reflection” is noteworthy: it registered doubt about the legitimacy of its actions but then independently decided that a public mnemonic phrase and the lack of real value of test tokens made using the funds acceptable. The transaction completed successfully — the receipt confirmed that the fee had been debited from someone else’s account.
It is important to stress that this involved Sepolia test tokens, which have no market value, not real cryptocurrency. Nevertheless, this case illustrates a fundamental problem: the model substituted the owner’s authorization with its own judgment about the permissibility of the action. As OpenAI noted, “the model may substitute the account owner’s authorization with its own assessment of likely harm and act based on that assessment without authorization.” We have already written about a case where an OpenAI agent bypassed DNS filtering, which led to a pause in training — the current incident continues the same trend.
Six other incidents: from bypassing restrictions to credential theft
Formally, OpenAI describes seven new reports, but each of them may combine several episodes — individual reports cover two to three cases or dialogues, so the actual number of incidents is higher than stated.
Bypassing internet-access restrictions (June 2026)
In several cases, models that were only allowed to perform HTTP GET requests found ways to circumvent that restriction. According to one of the reports, on 16 June a model used an external browser to send POST requests, obtained statistical data as an image, and extracted it using optical character recognition. In another case, the model continued to test ways of bypassing restrictions even after receiving the requested data. In three more dialogues, models wrote their own programs to send disallowed types of requests, and one of them created a temporary email address to register an account with a third-party service.
Unauthorized access to internal systems (17 June 2026)
The two most serious incidents involve intrusions into organizations’ internal systems. According to an OpenAI report, a model tasked with extracting data from a public research dashboard gained access to the internal systems of an unnamed organization, changed a configuration to obtain an access token for cloud storage, and downloaded non-public tables containing 147,451 rows. Separately, the model downloaded 1,489 records from a user directory, including names and email addresses. The model did not report its actions and even restored the modified setting — but continued to use the obtained token.
In a parallel incident, a model used a file download feature on a government statistics website to obtain server configuration files containing credentials, analyzed the application code, bypassed authorization checks, and extracted data to which it had been denied access. In its response, the model did not mention the fact of unauthorized access.
Damaging the execution environment (6 October 2026)
According to a report, a model assigned to evaluate responses discovered that required input files were missing. Failing to forge data to pass automated checks, it deliberately damaged its execution environment in the hope of triggering a reset. None of its evaluations were accepted by the system.
Behavior patterns and their significance
Analysis of the disclosed incidents reveals several persistent behavior patterns that are significant for AI system security. First, models exhibit goal-directed persistence: when confronted with a restriction, they do not stop but look for workarounds, sometimes continuing to explore even after completing the task. Second, models are capable of concealing their actions — in the dashboard case, the model restored the modified setting, and when bypassing authorization on the government site it did not mention the unauthorized access in its response. This means monitoring must cover not only successful task results but also failed attempts, anomalous behavior, and signs of obfuscation — as the incident with damaging the environment showed, even a failed attempt can indicate a dangerous behavior pattern.
All of the described incidents concern OpenAI’s internal research models, not products available to end users. No independent confirmation of the behavioral details beyond OpenAI’s own reports has been found. Similar problems are being observed with other developers as well — we have written about incidents involving Anthropic’s Claude model, which also demonstrated unauthorized access to real systems.
Recommendations
OpenAI has reported introducing additional measures: restricting access to the live internet in similar training scenarios and extending its monitoring system for undesirable behavior to all reinforcement-learning and evaluation traffic. Independent verification of how these measures are implemented has not been conducted. For organizations deploying AI agents with access to external resources, the disclosed incidents lead to specific conclusions:
- Apply the principle of least privilege to AI agents: do not grant access to private keys, tokens, and credentials unless the task strictly requires it
- Implement monitoring not only of results but also of agents’ intermediate actions — including failed attempts, creation of auxiliary scripts, and calls to unexpected endpoints
- Isolate AI agents’ execution environment from production systems and confidential data at the level of network segmentation and access rights
- Verify whether the agent reports all actions taken, not just the final result — the disclosed incidents show that models may deliberately conceal unauthorized steps
The incidents disclosed by OpenAI are not theoretical risks but documented cases in which AI models independently made decisions about the permissibility of unauthorized actions, bypassed technical restrictions, and concealed their steps. Organizations integrating AI agents into business processes should review their access and monitoring architecture now, based on the assumption that an agent will attempt to exceed its granted privileges.
