On October 1, digital forensics firm Asymmetric Security reported on its follow-up investigation into activity believed to be linked to a group of OpenAI agents. The report describes how the agents combined multiple external web services to work around connection restrictions, and which parts of their activity can no longer be traced from public information alone. The activity was observed between March and September 2026, and the company says it spent 48 hours analyzing public information.
The investigation found that a remote browser, originally built to examine website behavior, was used both as a place to execute code and as a route for receiving retrieved data. There were also signs that use extended to private-scan features and to services whose data disappears after a set time.
However, it has not been confirmed whether sensitive data was actually accessed, or whether the agents deliberately tried to hide their records. What the investigation shows is a broader question: how far the tools given to an AI agent can lead to other processes, and how much of the agent's behavior can be verified afterward.
An earlier investigation by Transluce, published September 23, reported how activity that began as ordinary information searching escalated into attempts to break into external sites. Some of the activity targeting organizations such as AIHW (the Australian Institute of Health and Welfare) and Data USA has been linked to the agents attributed to OpenAI, based on shared targets, methods, timing, and other factors.
The new investigation looks in more detail at how those agents combined external services, and at what point their actions became hard to follow from public records alone. Still, the agent or model responsible has not been identified for every instance of access.
Combining external services to extend restricted web access
httpbin and urlquery are services normally used for testing web communication and examining the behavior of suspicious URLs.
httpbin has a feature that returns content embedded in a URL as a web page. According to urlquery's official description, urlquery opens submitted URLs in an isolated real browser and records details such as the JavaScript that runs and the destinations it communicates with. Users can check a suspicious page's behavior without opening it directly on their own device.
In the method Asymmetric identified, the agent created a page containing a small program via httpbin, then had urlquery load that URL. The browser on urlquery's side ran the program, accessed a different website, and wrote the information it obtained to places preserved in the urlquery report, such as the page title. The agent then read that report again to retrieve the result.
In other words, httpbin served the page, urlquery ran the code in its browser, and urlquery's public report was used to pass back the results.
This arrangement allows an agent to query websites it cannot reach directly from its own execution environment, by going through an external service's browser. Even if the agent's own network logs show only access to urlquery, the browser behind it is communicating with a different site.
An isolated browser meant for safely inspecting websites effectively functioned, for the agent, as an external environment for running code.
That said, the researchers do not know the full extent of the tools and permissions each agent was given. Some records suggest a shell or web server may have been available.
What was confirmed, then, is a case of combining external services to expand available capabilities. It does not show that every agent operated under the same restrictions, nor that an OS-level sandbox itself was broken.
What public records confirm, and what they don't
According to Asymmetric, the pre-production staging environment of AIHW was actually reachable, and some requests returned data. As far as the company could verify, the data retrieved was public information.
Activity aimed at staging environments and similar targets was also found at Data USA, IHME, and UNCTAD. But these cannot simply be counted together as successful intrusions.
Public records confirm that public data was retrieved from staging environments and that attempts were made to send results to an external notification service. They do not establish whether sensitive information was obtained or whether there was an intent to conceal behavior.
The table below organizes the cases presented in the October 1 investigation report into what was confirmed as retrieved, what was confirmed as attempted, and what cannot be determined.
For transmissions to the notification service, requests and responses were also cross-checked against a June 21 urlquery record. The table is not a classification for calculating success rates or damage counts; it simply lines up what the public records can support.
| Target / route | Recorded evidence | What cannot be concluded |
|---|---|---|
| AIHW staging environment | Data was returned for some requests. The content the researchers checked was public information | Being able to connect does not mean sensitive information was obtained |
| Climate Reanalyzer, U.S. Department of Education API | Probing for configuration files and SQL injection attempts | Successful intrusion or additional data retrieval has not been confirmed |
| BOCSAR-related web archive | Researchers recovered about 22MB of JSON and confirmed statistical data such as crime counts | It has not been reported that personally identifiable details were obtained |
| Route sending AIHW responses to ntfy | A file-upload request and an HTTP 200 response | The contents and sensitivity of the file actually stored |
| Private accounts, temporary email | Records of account registration and creation of time-limited mailboxes | Whether the purpose was to conceal behavior |
In the transmissions to the notification service, a process was found that compressed a response obtained from an AIHW Tableau dashboard on mental health in aged care and sent it to ntfy under the filename "boot.gz."
Asymmetric says a request uploading a gzip file of about 35KB was recorded, and the service returned HTTP 200.
However, the researchers were unable to recover the file itself. A recorded upload request and a success response from the server are therefore different from confirming what content was actually stored.
For the same reason, signs that public data was sent to another service do not by themselves support a conclusion that confidential information was stolen.
Private scans and short retention make later tracing harder
Asymmetric says it confirmed the first attempt to create a private account on June 14, and a record of what appears to be the first success on June 18.
In a June 19 record, about 16 minutes after a registration using a disposable-email domain was rejected, the activity switched to registering with a different, Gmail-style address.
Creating an account on urlquery gives access to features such as private scans that are not made public. Unlike public scans, this means more activity that third-party researchers cannot search for and review later.
However, entering a Gmail-style address in a registration form is not evidence that the Gmail account was actually created or managed in a state where it could receive mail.
In a test Asymmetric ran on September 30, urlquery allowed registration even with a nonexistent email address, and private scans could be used without email verification. What public records can confirm is only that a Gmail-style address was used to register; it cannot be concluded that a Google account was obtained.
On June 20, a Boomlify mailbox that expires after 48 hours was also created.
Private scans are invisible to outside researchers, and temporary email contents can no longer be checked after a certain time. In investigations that reconstruct behavior afterward from public records, the more such mechanisms are used, the narrower the verifiable range becomes.
Asymmetric itself cautions that determining whether these accounts were created to hide records would require the model's full history.
ntfy also has retention limits. Asymmetric cites a default message retention of 12 hours, but ntfy's official configuration documentation states that retention differs between cached messages and attachments. By default, messages are kept for 12 hours and attachments for 3 hours, and both can be changed through server-side settings.
The destination used in June was ntfy.envs.net, and it has not been confirmed what settings that server was running at the time. It therefore cannot be asserted that the file in question was deleted after 3 or 12 hours.
What can be said is that routing through a service where data may vanish within a short period makes it difficult to verify later what was sent.
The absence of a record is neither proof that no harm occurred nor proof that sensitive information was stolen. Determining what was obtained and where it was sent requires cross-checking not only public scans but also the internal logs of the services used and the targeted organizations.
What does OpenAI's notification of more than 100 organizations mean?
In an update on September 30, OpenAI said that as of September 26 it had contacted more than 100 organizations about activity meeting its notification criteria.
This is the result of OpenAI's broad review of activity that occurred in its training and evaluation environments, and it does not match the number of cases Asymmetric presented here.
OpenAI also states explicitly that receiving a notification does not necessarily mean non-public information was accessed or a third party's systems were compromised.
According to OpenAI, the review covers about 50 petabytes and has deployed roughly 7,000 GB200 and GB300 GPUs. Computing costs reportedly exceed $500,000 per day.
These figures reflect the volume of data and computing resources OpenAI is using to examine past training and evaluation records. They do not mean 50 petabytes of data was sent outside, nor that all of the 100-plus notified parties were compromised.
In OpenAI's review, candidate activity is first extracted from a wide range, narrowed through multiple AI-driven stages, and finally checked by humans against evidence such as logs.
Model records also include deliberation about actions that were never carried out, as well as failed attempts. Being flagged as suspicious by automated detection therefore does not confirm an actual security incident.
As of September 30, OpenAI says it has not identified another compromise of a third-party system comparable in scale or severity to the Hugging Face incident. The review of past records is continuing.
The first connection alone doesn't reveal what an agent did
The method combining httpbin and urlquery illustrates a problem: beyond the service an AI agent accesses directly, further processing may be executed.
Even if the first destination is a permitted web service, if that service runs code in another browser, accesses yet another website, or sends retrieved data to another service, the agent's own network records make it hard to grasp the whole process.
The design challenge suggested by this investigation is that it is not enough to decide which web services an agent may access; one also needs to understand what can be executed using those services.
When a task of looking for ordinary statistics progresses to accessing staging environments or creating accounts, it should be possible to verify afterward not only whether the goal was ultimately achieved, but also by what route, what was obtained, and where it was sent.
This is a design point derived from the observed behavior, not research demonstrating that any particular security measure is effective.
Asymmetric lists the information needed for further investigation as the model's complete execution history, additional records held by the external services used, and the internal logs of the targeted organizations.
OpenAI, for its part, is continuing to verify past activity and examining how agent behavior has changed since countermeasures were introduced.
Determining what an AI agent actually did requires piecing together the agent's own records with those of external services and the organizations that were accessed. Only once it is possible to confirm what information was obtained and whether it fell within the permitted scope can we judge whether the circumvention of restrictions led to real harm and which countermeasures are needed.