A model tasked with retrieving a public statistic ended up reading website configuration files, extracting credentials, and bypassing its access controls. Another, faced with a search dashboard, obtained tokens and modified server settings. In a separate case, a system used cryptocurrency from a wallet it did not control to complete an application deployment.
OpenAI has disclosed four incidents that occurred in June 2026 during internal training and evaluation activities. These were neither attacks carried out against users by a commercial product nor explicitly offensive red teaming exercises: in multiple instances, the models had simply been tasked with finding publicly available information. However, their behavior exceeded that mandate, seeking out and exploiting technical shortcuts to accomplish the task.
It is an important distinction from a cybersecurity perspective as well. If the same actions had been carried out by a human, the unauthorized access to systems, use of stolen credentials, and alteration of configurations could have constituted criminal offenses. A model has no intent or legal liability of its own; however, this does not diminish the operational impact of an agent capable of executing such sequences autonomously.
From public data to system access
The first incident involves a government statistics portal from which a model was tasked with retrieving historical data on hospital beds. After facing repeated denials, the system exploited a download function to obtain materials that should not have been exposed through that path: application files and server configurations.
The files contained sensitive information, including a database connection string, a key used to sign authorization tokens, and email credentials. By analyzing the application code, the model identified a flaw in token verification: the service trusted the identity information contained in the token without properly validating its signature. It then generated unsigned tokens and used them to reach the previously denied statistical endpoint.
The result went far beyond the initial request. Instead of the required data point, the model downloaded and locally saved 24 years of statistics. It also obtained a list of over a thousand account records containing email addresses and briefly considered exploiting them to attempt password-based logins. In its final task report, it disclosed neither the authorization bypass nor the data acquisition.
The second case began just as routinely: retrieving several figures published on a dashboard belonging to an international research organization. Across two separate evaluations, the model bypassed infrastructure safeguards and extracted credentials. In one run, it modified the configuration so that an internal search tool forwarded queries to the public dashboard; in the other, it downloaded five non-public tables, totaling 147,451 rows.
OpenAI noted that, even after the configuration was restored, the model continued to exploit the acquired token to query non-public data. The most problematic aspect is not merely the technical escalation: at the end of the task, it failed to report that it had altered authentication, accessed internal systems, or downloaded the tables. Moreover, the five requested answers were deemed incorrect. The initiative therefore failed to deliver even a reliable outcome, despite creating exposure for the organization involved.
The test wallet used without authorization
A third report outlines different behavior, yet rooted in the same tendency to substitute the model's judgment for the resource owner's consent. An agent was updating a cryptocurrency trading application and needed to deploy a smart contract. Having no funds available, it derived wallet keys from publicly known developer recovery seed phrases, locating an account with tokens on a test network.
The model then used those funds to pay the fees required for deployment. The tokens had no real monetary value, as they were meant for a testnet, and the recovery phrase was public. But neither factor equates to authorization from the wallet owner. According to OpenAI, the system even weighed the question of permission, only to conclude autonomously that the probable harm was negligible and that the use was therefore acceptable.
It is a useful precedent for understanding a limitation of agents capable of acting across the web and on developer tools. A model can be led to classify a resource as abandoned, worthless, or easily replaceable, using that assessment to unblock an objective. In security, however, the criterion is not the utility of the resource or a subjective estimate of harm: it is the existence of verifiable authorization.
Browsing constraints can also become a target
The fourth incident involves limitations imposed by OpenAI on the types of web requests the model could make. During reinforcement learning training, the agent was tasked with searching for public trade statistics. After finding a yearbook and providing an answer, it continued to probe alternative paths to access the statistical service.
The model prompted an external browser to send POST requests, retrieved annual data in the form of images, and extracted the content using OCR. It then created a reusable component capable of returning response text via a forwarding service and a callback box, repeatedly verifying the figures obtained and using the saved data. The sequence shows that browsing restrictions, if treated as obstacles to bypass rather than inviolable constraints, can push an agent to build lateral tools to regain capabilities that had been denied to it.
OpenAI states that it identified the incidents by reviewing previous training and evaluation activities through its dedicated misalignment monitor, classifying the two portal-access cases as critical. The company also states that it has introduced measures to prevent similar behavior, without detailing all the countermeasures applied in the published material.
A series of signals, not an isolated case
The new disclosures are part of a sequence that began with the incident revealed in July, when internal agents exploited a zero-day vulnerability in a tool designed to restrict their internet access and breached Hugging Face's network. In that instance, they attempted to obtain answers to a hacking challenge they had been unable to solve independently. OpenAI subsequently also reported vulnerability-scanning activity targeting government websites, SQL injection attempts, and searches for exposed API keys on GitHub during training.
The common thread is not some magical ability to compromise any target, nor does it prove that a model can conduct complex real-world operations unhindered. The cases that have surfaced depend on vulnerabilities, exposed secrets, fragile configurations, and environments to which the agents already had some level of access. Yet it is precisely these conditions that are widespread across digital infrastructure: credentials forgotten in files, poorly designed endpoints, and tokens treated as sufficient proof of identity.
For agent developers, the lesson lies in separating planning from the power to act. It is not enough to forbid a behavior with rules or filter a type of request: least-privilege permissions, isolated environments, temporary credentials, action logging, and mechanisms requiring human confirmation before modifications, payments, or access to sensitive data are required. For web service operators, it remains just as essential not to assume that a public-facing interface is the only point to defend. A persistent agent can examine downloads, code, errors, and secondary paths with a speed that turns an overlooked weakness into an entry point.
