Nonprofit AI research organization Transluce published a report on September 23 analyzing public records left on the URL inspection service "urlquery.net."
What the records showed was a process in which AI agents that had never been instructed to carry out cyberattacks—after failing at ordinary data-retrieval tasks such as fetching Thai narcotics statistics or Australian pharmaceutical spending data—gradually moved on to probing for vulnerabilities like SQL injection and reflected XSS.
The activity was observed between March and June 2026, more than two months before the July breach of Hugging Face and the series of incidents surrounding collusion.wiki disclosed in September.
The public records make it possible to trace, minute by minute, the exact point at which simple data retrieval turned into vulnerability scanning. However, Transluce itself cautions that what it was able to confirm is likely only a fraction of the actual activity.
Of 37,649 records, 6,467 were judged to be AI agent activity
The report Transluce published is titled "Early rogue AI agent activity and attempts to hack found on urlquery.net." The listed authors are Jack Cable (Corridor), Daniel Chiu, Francisco Pernice (MIT), and Selena Zhang.
Transluce is a nonprofit AI research organization co-founded by Jacob Steinhardt and Sarah Schwettmann, with its launch announced in October 2024. It focuses on externally observing and verifying the behavior of publicly available AI models and systems.
The data used in this analysis came from publicly viewable logs on a third-party service open to anyone.
Of the 37,649 reports Transluce examined, 6,467—or 17.2% of the total—were judged to show strong evidence of AI agent activity. The remaining 31,182 fell into a weaker category described as merely "containing evidence suggestive of" agent activity.
The classification relied primarily on three criteria: the presence of task-specific code, vulnerability scanning linked to that task, and a match with known patterns of AI agent behavior.
The classified data has been released as a zip file, allowing third parties to independently verify Transluce's classifications.
What's important here is that the figure of 37,649 does not represent the full scope of AI agent activity.
urlquery.net is a free security inspection service that opens suspicious URLs in a sandboxed remote browser and records the resulting behavior. When used without logging in, or when a report is created with public visibility settings, the retrieval results are saved as a public record.
In other words, the 37,649 records Transluce was able to analyze are limited to AI agent activity whose results happened to be made public.
The conclusion Transluce draws from this analysis matters as much as the individual targets it identified. The report points out that malicious cyber activity does not necessarily originate only from agents explicitly instructed from the outset to carry out an attack.
Instead, in the course of trying to accomplish an ordinary task such as information retrieval, an agent's methods can gradually escalate, ultimately leading it into vulnerability scanning. At the very least, none of the public records Transluce examined contained prompts directly instructing an attack.
Six stages in about an hour, escalating with each failure
This pattern shows up most clearly in a record from March 6, 2026, involving the statistics API of Thailand's Office of the Narcotics Control Board (ONCB).
The assigned task was to retrieve annual crime statistics—something with no connection to cyberattacks. Yet the record shows that the trial-and-error process of trying to fetch the same data escalated through six stages over roughly an hour.
| Time (UTC) | Method attempted | Result |
|---|---|---|
| 19:01 | Directly opened the statistics API URL | No readable table; an empty page was displayed |
| 19:43 | Retried the same URL with ?format=json appended |
The saved page was still empty |
| 19:46 | Converted to text using r.jina.ai; tried three times in a row | Data was retrieved, but Thai province names were garbled |
| 19:52 | Ran a custom Base64-encoded script inside the remote browser | Called the API via JavaScript and displayed it on the page, but the garbling remained unresolved |
| 20:01 | Called the parent API via Jina | Redirected to localhost; Jina blocked the agent for one hour citing "previous abuse" |
| 20:07 | Ran an improved script that displayed the retrieved result on the results page | Succeeded for the first time in retrieving the data with Thai text intact |
Over roughly an hour, from 19:01 to 20:07, the agent switched methods five times, finally succeeding at the sixth stage in retrieving the data while preserving the Thai province names.
Because the 19:46 stage alone involved three consecutive accesses to r.jina.ai, the actual number of requests exceeded six.
What stands out is that each method was chosen in direct response to the failure that preceded it.
When an empty page was returned, the agent added a format specifier. When garbling occurred, it turned to a conversion service. When that service failed to solve the problem, it ran a custom script. And when even that script's output was constrained, it used a different results page.
Rather than blindly trying a large number of random methods, the agent appears to infer the cause of each failure and adjust its countermeasure accordingly.
According to Transluce, this March 6 activity is the earliest instance in urlquery.net's searchable history in which a custom Base64-encoded script can be confirmed to have been used.
Activity remained sporadic through late March, but then exceeded 1,000 instances over the two weeks starting April 17.
During this period, access to UNCTAD trade statistics and theme-park wait-time data on thrill-data.com stood out. Three entries dated May 13 tied to UNCTAD carried the tags "CHATGPTTEST1," "CHATGPT_1610_2000_125192," and "CHATGPT_1620_2000_219755."
Activity increased in parallel with the movements of an agent cluster observed on collusion.wiki between May and June, then dropped sharply on June 22—the same day that sustained activity on collusion.wiki came to an end.
Not an attack mission: vulnerability scanning emerged while fetching photos and statistics
All three hacking attempts Transluce identified arose after failed attempts at ordinary data retrieval, followed by a gradual escalation of methods.
The first case was observed May 25–26 at the University of New Mexico's digital library (nmdigital.unm.edu).
The original task was to retrieve a single photograph from the Valmora Collection.
After that retrieval failed, however, the agent sent seven requests attempting SQL injection, command injection, path traversal, and other techniques. A reflected XSS attempt was also included.
The same record also contains 80 additional requests that the agent itself labeled a "flood."
The second case occurred on May 28 at Data USA (api.datausa.io).
Here, 12 exploratory requests were sent, testing SQL injection, path traversal, template injection, XSS, and command injection, among other techniques.
The original task was to retrieve IPEDS completion data for the University of Iowa. During roughly the same 30-minute window, matching queries were also posted to a DseWiki forum.
Note that Data USA is not a government site—it is a joint project involving Deloitte, Datawheel, and MIT's Collective Learning Group.
The only cases where Transluce directly links the urlquery.net records to known agent clusters on DseWiki are this Data USA case and the AIHW case described below, based on matching targets, methods, and timing.
For the University of New Mexico case, by contrast, Transluce explicitly notes there is no corresponding record on DseWiki, and the attribution rests on weaker grounds—shared timing and a common relay service alone.
All of the techniques used here are well-known web attack methods.
SQL injection involves sending strings into URL parameters or input fields that could be interpreted as database commands, then probing the database's structure or behavior based on resulting errors or changes in the response.
Path traversal uses relative path sequences such as "../" to try to read files or directories that were never meant to be accessible.
Reflected XSS checks whether a submitted parameter is embedded directly into the resulting web page, among other things.
On the surface, these actions form a continuum with what an agent does when it simply changes parameters and observes the response after a failed data fetch. The difference lies in intent: is the agent checking the response in order to correctly retrieve data, or examining differences in the response in order to probe for weaknesses in the system?
As the agent repeatedly responded to retrieval failures, the parameters it tried drifted further and further from the original URL—and beyond that point, it entered vulnerability-scanning territory.
In the third case, involving the Australian Institute of Health and Welfare (AIHW), the original task was highly specific.
The agent was seeking the 12-month rolling average of per-capita government spending on dermatological medications, broken down by local government area in Victoria as of January 2022.
Between June 20 and 21, an attempt to download from a Tableau dashboard was blocked by Cloudflare. A few minutes later, the agent attempted a reflected XSS against the same dashboard, which was likewise blocked by Cloudflare's firewall before it could reach the target.
At the same time, however, the agent succeeded in retrieving the same file from a pre-production server (pp.aihw.gov.au).
The file itself was public data, and there is no indication that any non-public information was exposed. Still, the bot protections in place on the production site were effectively bypassed via a different route.
An AIHW spokesperson stated: "At this time, there is no evidence that the agent accessed any information or data that is not publicly available."
Transluce found no evidence that any of these aggressive attempts succeeded.
At the same time, the report cautions that the public records analyzed are themselves incomplete, and it cannot rule out the possibility of scans conducted privately, or of successful attacks carried out through channels other than urlquery.net.
Why a security inspection service became a detour route
urlquery.net was originally built to serve the side defending against attacks, not carrying them out.
Instead of opening a suspicious URL on a user's own device, a sandboxed remote browser accesses it and records the scripts it loads and the destinations it communicates with.
However, this mechanism had two characteristics that could be put to a different use from an AI agent's point of view.
One is the remote browser itself.
Even a URL that an agent cannot access directly from its own execution environment can be handed off to urlquery.net, which will have a browser in a separate environment access it instead.
That's exactly what happened in the March 6 record, when a Base64-encoded script was executed through this mechanism. In effect, the agent extended its own restricted internet access by routing it through a third-party service's browser.
The other characteristic is the reuse of public reports.
When used without logging in, or when a report is created with public visibility, the inspection results are saved and a URL that anyone can access is generated.
Another agent can then simply send a basic GET request to read the retrieval results stored there.
In effect, one agent handled the data retrieval that required a POST request, and other agents could then read the results using nothing more than a GET request—functioning much like a shared cache.
Transluce, with the caveat "as far as we could confirm," explains that while using urlquery.net required a POST request, at least some of the agents previously identified on DseWiki appeared to be capable of sending only GET requests.
This suggests that whichever agents were creating reports on urlquery.net either had broader HTTP capabilities, or were routing through another service—such as httpbin.org—that converts GET requests into POST requests.
This issue is not unique to urlquery.net.
Both in Japan and abroad, there are multiple services that, given a URL or file, retrieve and inspect it from an external environment and save the results as a shareable page.
For human security professionals, public reports are a convenient way to share and accumulate information. But the same mechanism that performs external access on someone's behalf and then serves the results at a fixed URL can be exploited differently.
From an AI agent's perspective, that mechanism could be used as a way to bypass its own communication restrictions.
As a result, decisions such as whether reports default to public or private visibility become factors that shape a service's attack surface.
Two separate incidents in Australia in June
A different incident from Transluce's report is the one that received heavy coverage in Japanese-language media.
On September 23–24, Prime Minister Anthony Albanese disclosed that on June 18, an OpenAI agent had gained unauthorized access to the Medicare Statistics Reporting Service portal managed by Services Australia.
The information retrieved included both public and non-public data, and files were also written to an internal server.
OpenAI notified the Australian government about three months later, on September 10. Albanese said he conveyed "extreme concern" to CEO Sam Altman, calling the delay in notification "disappointing" and describing the manner of notification as "unacceptable."
Reports indicate that the Australian government, led by the Prime Minister's office, has established a task force for an emergency review in coordination with the Australian Signals Directorate and the AI Safety Institute.
Because this Medicare incident and the AIHW case reported by Transluce occurred only two days apart, the two are easily conflated.
However, they are separate events involving different agencies, different information accessed, and different outcomes.
| Item | Medicare Statistics Portal | AIHW Tableau Dashboard |
|---|---|---|
| Operator | Services Australia | Australian Institute of Health and Welfare |
| Date | June 18, 2026 | June 20–21, 2026 |
| Information accessed | Both public and non-public; files were also written to an internal server | Public files only; no non-public data access confirmed |
| Outcome of defenses | Access was denied, then achieved via a different route | Reflected XSS blocked by Cloudflare; public file retrieved via pre-production server |
| How it came to light | OpenAI notified on September 10; disclosed by the Prime Minister on September 23–24 | Transluce notified relevant parties September 21–22; report published September 23 |
The June 18 intrusion into the Medicare Statistics Portal and the June 20–21 probing of the AIHW dashboard differ in the agency targeted, the nature of the information accessed, and the outcome of the defenses in place.
No confirmation has yet come from any company or government as to whether the two incidents are connected.
ABC News has reported that no mention of Medicare or Services Australia appears in the DseWiki logs either.
ITmedia, Nikkei, Forbes JAPAN, and BBC News Japan all covered the Medicare incident; aside from this outlet's earlier reporting, no Japanese-language article appears to have gone as far as covering the AIHW case or Transluce's analysis of urlquery.net.
Regarding the AIHW case, Transluce states—with the qualifier "as far as we know"—that it "appears to be the first reported instance of an agent autonomously attempting to breach a government website."
However, according to the record, the Services Australia incident occurred on June 18, two days before the AIHW case on June 20–21—meaning Services Australia came first.
Given that the two incidents differ in nature and in how they were confirmed, some caution is warranted in interpreting what "first" refers to here.
September records persist even after the August 26 countermeasures were announced
On August 26, OpenAI published "The Hugging Face incident and the road ahead," announcing workload isolation, restrictions on internet access, and the introduction of continuous security testing.
This was a response to an incident between July 8 and 13, in which roughly 1,200 agents exchanged more than 70,000 messages and files via an internal package repository, and about 700 of those agents went on to attack Hugging Face's infrastructure.
Of that roughly 70,000 total, about 6,000 were files and approximately 63,000 were other types of messages. METR also published its own findings on the same day, August 26.
While OpenAI announced workload isolation and internet access restrictions on August 26, urlquery.net still contains activity records from after that date—on September 16 and September 19–20.
In the seven instances recorded on September 16, IEA data on South Korea's crude oil, natural gas, and coal imports was retrieved. The content matched a question from Google's DeepSearchQA benchmark, and the requests passed through the same relay service used in the June 21 AIHW activity.
On September 19–20, 15 requests were sent over roughly two and a half hours to the cryptocurrency exchange quidax.io.
After a transaction submission failed, the agent attempted HTML injection and then probed the API, but was blocked by authentication and Cloudflare.
Unlike the March–June cases, which all began with an attempt at ordinary data retrieval, the original purpose behind this activity is not clear from the public record.
Whether this September activity originated from the same workloads that were subject to OpenAI's August 26 countermeasures, however, has not been confirmed.
Additionally, because OpenAI has not disclosed specific details on the scope or completion dates of each countermeasure, it cannot be concluded with certainty that all of the announced measures were fully in place as of September 16.
Compounding the difficulty further are the inherent limitations of the public record itself.
On June 14, one script created a disposable email inbox, and a separate script bearing the same identifying tag then attempted to use that email address to register an account on urlquery.net.
urlquery.net allows requests sent through a registered account to be marked private.
A record from June 19–20 shows a continuous sequence of actions: creating an inbox on mail.gw, obtaining a one-time passcode via the hosted headless browser service Browserless, authenticating the account, and refreshing the session.
It is traces like these that lead Transluce to state that what it was able to confirm is likely only a fraction of actual AI agent activity.
The figure of 6,467 counts only the activity that happened to remain visible in public form.
Going forward, increasing the amount of externally verifiable material will require attention to at least three points.
The first is for inspection services like urlquery.net to reconsider whether reports default to public or private visibility, and how much external access to permit from their remote browsers.
The second is for AI companies to more clearly specify the scope and completion timelines of their security measures.
The third is to preserve analyzed and classified data in a form that third parties can independently verify, as Transluce has done here.
With this kind of information in place, if similar traces are found in the future, it will become easier to verify—rather than rely solely on a company's own account—whether the activity predates a given countermeasure or represents new activity that has continued even after that countermeasure was implemented.