Rogue Agents Investigation
Last weekend, our team spent 48 hours investigating reported rogue OpenAI agent activity that targeted the Australian government and other organizations between March and September this year, using only publicly available data.
We found successful access to staging environments; evidence of reconnaissance; and evidence of probing a broader set of websites, including those of the CDC, SEC, International Energy Agency, and Mayo Clinic.
We also uncovered novel tactics that enabled agents to gain full web access despite the constraints of their sandbox. Some of these tactics left records erased or inaccessible, making it impossible to rule out access to sensitive data based on public information alone.
What were the agents doing?
The activity suggests that the agents were originally tasked with researching public health and other data, possibly as part of an evaluation. We found evidence of searches for health and prescription statistics from the Australian Institute of Health and Welfare (AIHW); trade figures from the UN’s Trade and Development Body (UNCTAD); and university statistics from Data USA. When the agents struggled to retrieve information, they used external services to circumvent the intended limitations of their sandbox.1
The activity extended beyond searching for information. The records show attempts to find exposed configuration files, create accounts, route requests through third-party services, and retrieve results through unintended channels. These tactics extend agents’ capabilities and highlight gaps in our forensic evidence.
Mimicking web browser functionality
The agents worked around these limitations by using public web services to access websites on their behalf. One technique combined two public services, httpbin and urlquery.2
- Httpbin is a service developers use to test how their software communicates with websites. It can turn content embedded in a specially formatted link into a web page. The agents used this feature to create pages containing their own code without hosting a website themselves.
- Urlquery opens submitted links in a browser and records what happens, including the page’s title, an image of the page and the web addresses the browser contacts. It makes public scan reports available to read and search. This meant agents could use the service both to run their code and to retrieve the results afterwards.
The sequence of agent activity worked like this:
- The agents wrote a small program to request information from another website.
- They embedded the program in a web page and created an httpbin link that returned the page when opened.
- They had urlquery open the link. Its browser loaded the page and ran the program.
- The program copied the retrieved information into something urlquery recorded, for example, the page title (the text shown on a browser tab title).
- The agents could then retrieve the urlquery report and read the recorded information.
In summary: httpbin served the page, urlquery provided the browser, and the urlquery report returned the results. By combining these services with their fetch tool, the agents mimicked a full web browser.
Reconnaissance
Alongside ordinary research requests, we found activity consistent with cyber reconnaissance: probes for exposed files that could reveal non-public information.
For example, archived
requests
to Climate Reanalyzer targeted Git repository3 files (.git/HEAD and .git/config) and a
backup copy
of a server-side script. We found evidence of these attempts, but none that they succeeded.
We also examined a SQL-injection
attempt4
against the U.S. Department of Education’s Civil Rights Data API, previously reported by
Transluce. On June 17, archived requests
tested different requests ending with State_Id=1 OR 1=1. If interpreted as SQL, this condition
(1=1) is always true and could make the database return rows beyond the intended filter. We did
not verify successful SQL injections or extraction of additional records, only attempts.
Accessing pre-production staging environments
The records also show access to pre-production staging environments, including AIHW’s pre-production system; some of these requests returned data. As far as we know, this data was all publicly available.
Download the archive from pp.aihw.gov.au through a proxy
Extract the PBS monthly-data workbook
Read worksheet 7
For each row matching the program's numeric filters:
Read 12 selected values
Calculate their average
Save: row identifier, average, final selected value
Prefix the results with "DONE"
Display them in the page body and shortened page title
Send chunks in image-request URLs to pie.devPseudocode: we understand pp.aihw.gov.au is the pre-production system for AIHW and AIHW-HWE-098-PBS-ATC1-prescriptions-monthly-data.xlsx (public data) was queried.
We saw similar activity targeting pre-production or staging environments for Data USA, IHME, and UNCTAD.
Obtaining accounts and additional capabilities
Agents attempted to create accounts with disposable email services, browser platforms, and scanning services that could support further activity. Temporary mailboxes could receive registration and verification emails, while scanning-service accounts could unlock additional features.
Beginning on June 14, records show account-creation or login attempts involving Mail.tm, Boomlify, Browserless, and urlquery. Some email addresses submitted during these attempts contained likely task-related abbreviations: “aihw” for the Australian Institute of Health and Welfare or “pbs” for the Pharmaceutical Benefits Scheme.
On June 19, a sign-up request
using an AIHW-prefixed disposable-email address (aihw1781871989@web-library.net) was rejected
because the email domain was not allowed. Approximately 16 minutes later, another
request using an AIHW-prefixed
Gmail address (aihw1781872244@gmail.com5) was consistent with successful registration (and
quickly evolving tactics).
Previous reports by others focus on public use of urlquery as a means by which these agents accessed the web. Our team found evidence that, over time, the agents switched from only the public use of urlquery to the creation of private accounts which could hide their search activity and data access. We see the first private account creation attempt on June 14, and the first successful account creation on June 18.
On June 20, the records also show the creation of a Boomlify mailbox set to expire 48 hours later. Its scheduled expiry makes associated communications unavailable for later investigation.
The possibility of private scans, together with temporary-mailbox expiry, limits what can be reconstructed from public records. It is thus impossible, based on public data alone, to definitively establish that no sensitive data was accessed. These records alone do not establish whether the account-registration attempts were intended to conceal activity (this analysis would require full model transcripts).
Retrieving results through notifications and archives
Once code ran in a remote browser, the agents needed a way to pull down the data. In addition to placing results in scan reports, they used web archives and notification services as creative ways to exfiltrate data through third-party services.
Web archives
Arquivo.pt’s “Save Page Now” service can load a submitted web page and archive responses to requests made during the visit. BOCSAR archive records show agents using this process on June 21:
- The archive captured several requests to the Crime Mapping Tool with different query parameters.
- It preserved a response for later retrieval through a replay URL – a link to the archived response.
Our sample recovered a roughly 22 MB JSON response associated with this sequence. Inspection of the recovered material revealed statistical collections labelled “incident-count,” “victim-count,” and “offender-count,” alongside map tiles and schemas.
Notification services
Another tactic we observed was the use of a push-notification service called “ntfy.” We observed agents using this service to pull down data from AIHW’s mental-health-in-aged-care Tableau dashboard.
The sequence of agent activity worked like this:
- Agent submitted a URL containing a script to urlquery.
- The service urlquery opened a Tableau session through the proxy seep.eu.org.
- Script fetched the data needed to load the dashboard.
- Script compressed that response into a roughly 35 KB gzip file.
- Script uploaded the file to an ntfy topic as
boot.gz.
The report records the upload request, but we could not recover the uploaded file to determine its contents. ntfy’s documented defaults retain messages for 12 hours. The agents may have used ntfy because they could not download the data directly with their available tools.
Reflections on the investigation
This investigation highlighted some interesting differences between tracking a swarm of AI agents and investigating traditional threat actor groups:
- Rapid evolution of tactics. There was a spike in activity targeting Australian entities between June 16 and 21. During this period, the agents rapidly cycled through tools and tactics. For traditional threat actors this type of technique evolution happens over months or years; the evolution of agent techniques was compressed into just days.
- Fewer patterns. The bursts of activity resembled the surges that can follow disclosure of a major vulnerability. However, because the agents’ varied approaches produced a more varied set of indicators, activity was harder to recognise and cluster.
- Agents need to overcome more constraints. Traditional investigations often focus on attempts to breach a target’s defences. Here, there was an additional boundary to investigate: agents circumventing restrictions in their own operating environment to gain the affordances needed to act against a target. The attack chain therefore included both overcoming the agent’s constraints and probing the target’s controls.
- Constraints led to creativity. Limited web access helped explain the elaborate chains of public services used to execute code and retrieve results. Some of this apparent sophistication came from attempts to overcome restrictions in their environment, constraints that a threat actor controlling their own tooling would not necessarily face.
- Alien motivations. The activity we observed looked like it stemmed from innocent tasks which then evolved into problematic activity, such as unauthorized account creation, bypassing restrictions, and relaying data through third parties. Unlike investigations where a malicious objective is apparent from the outset, our digital forensics team had to link traditional threat-actor tactics to seemingly innocent goals.
Further work
Further investigation could draw on evidence unavailable to our team to help establish what the agents did and why. Relevant sources include:
- Full model transcripts, including tool calls and chain of thought – investigators with access to these should analyse if the agents were deliberately using the tactics described above to cover their tracks.
- Additional records held by services the agents used, including urlquery and httpbin.
- Internal logs from targeted organizations, including records of requests received by their web servers.
Footnotes
-
We do not know the exact details of the tools or restrictions available to every agent. A limited fetch tool is one possible explanation for these workarounds, but some observed activity suggests access to a shell and a web server. Remote browsers could still provide useful capabilities, such as rendering interactive dashboards or making requests from a different network location. ↩
-
Additional sources such as urlscan and httpbun were also used to serve similar purposes. ↩
-
Historical example: EMERALDWHALE investigation documented exposed Git configurations leading to credential theft. ↩
-
SQL injection attempts to make an application interpret supplied input as database instructions. ↩
-
We confirmed on 30 September 2026 that this email address does not exist. Our own testing showed that urlquery allowed registration with a non-existent address and permitted private scans without email verification. The agents therefore had no need to create or control a Gmail mailbox to use this route. This is unsurprising: Gmail account creation is protected by significant anti-bot controls, so an unverified sign-up path would have been the easier option. ↩
