Read this first
This is speculation. I have no inside information. Everything below is a reconstruction from public news reporting and historical records on the Wayback Machine and Trove.
No hacking was performed in this investigation.
What happened
On 24 September 2026, Prime Minister Anthony Albanese revealed that an OpenAI AI agent had gained unauthorised access to a government Medicare statistics system on 18 June 2026.
The reported story: an agent researching public medicine spending was blocked from Australian data, "found a security workaround," accessed non-public aggregate health statistics and internal file names, and wrote files to the server. No patient records were accessed.
The PM didn't name the exact site. Based on the reported details and the archive records, I believe it's the Medicare Statistics Reporting Service portal at medicarestatistics.humanservices.gov.au. That identification is my inference, not an official statement.
"Security workaround" makes it sound like a break-in. The archived code tells a different story. Nobody picked a lock. The gate was open, and it had been open for over ten years.
Ten years with no login
The portal is a public statistics service built on SAS, a reporting platform. You choose options on a form (Medicare item numbers, date range, "by state"), and the server runs a report and sends back the results. It's a reporting tool, not a patient database, which fits the official line that no personal data was touched.
From 2014 to early 2025, the report URLs looked like this:
http://medicarestatistics.humanservices.gov.au/statistics/do.jsp?
_PROGRAM=/statistics/mbs_item_standard_report&group=23&
VAR=services&
STAT=count&
RPT_FMT=by+state&
PTYPE=finyear&
START_DT=201707&
END_DT=201806The Wayback Machine shows these returning full reports to anyone, with no authentication, for over a decade.
They weren't secret. The URLs appear in academic papers, CSIRO journal articles, NGO reports and government documents, and Trove's index confirms it. Open access was the design, not a defect.
Before March 2025: open, but you had to know the paths
In the decade before the upgrade, the data was already open to anyone. There was no login and no barrier. The one thing standing between a visitor and a report was knowing the report's address, and even that was barely a hurdle. The URLs were published in academic papers, CSIRO journal articles, NGO reports and government documents, so the well-known ones could simply be copied. Anything not already published, you'd have to work out or guess.
So the "before" state was: fully open access, with a mild speed bump of needing to know the right paths.
After March 2025: the upgrade handed out the paths
Between 18 and 27 March 2025, the archive shows the old custom app being replaced with the standard SAS 9.4 platform.
That platform comes with a login system (SASLogon) built in by default. This almost certainly wasn't a security project. It looks like routine modernisation of a decade-old app, and the login layer arrived as a side effect.
But the portal had to stay public. Nobody should need an account to read aggregate statistics. So the operators switched on the platform's built-in guest access, keeping the site open to everyone.
Here's the twist. The upgrade that looked like it added security actually made the data easier to reach. The new platform shipped a JavaScript file, SetupEnvironment.js, that published the internal path formula on every page. After March 2025 you no longer had to know or guess the paths. The site handed them to you.
So the "after" state was: still fully open access, but now with the speed bump removed. The site looked secured, with a login page and an authentication handshake, while the guest mechanism quietly let everyone through and the code spelled out exactly where to go. The operators were keeping the public door open, and in doing so they appear to have unintentionally left the door to the back rooms open too.
The two files that did the work
Two files in the archived code are what turned the post-upgrade site from "open if you know the path" into "open, and here's the path."
1. The JavaScript that published the internal addresses. Every page loads SetupEnvironment.js, which contains the formula for building internal paths:
var _NUMBERPLATE='VEA0032';
switch (...last-two-chars-of-hostname-prefix) {
case '01': var ENV_SYSTEM='prod'; break;
case '02': var ENV_SYSTEM='test'; break;
case '03': var ENV_SYSTEM='dev'; break;
}
var _PROGRAM='/Shared Data/sasdata/'+ENV_SYSTEM+'/'+_NUMBERPLATE
+'/SAS.StoredProcess/'+ENV_PROJECT+'/'+stpName;Any visitor, human or bot, could learn the production path, the fact that test and dev systems exist, and the rule for addressing any report. Comments in the file even spell out the full internal address format.
2. The guest entrance logged itself in. Archived redirect chains show what happens when you call the guest endpoint:
/SASStoredProcess/guest?_PROGRAM=SBIP://METASERVER/...
→ SASLogon/login?...&direct_authentication_ticket=ST-1032515-...
→ /SASStoredProcess/j_spring_cas_security_check?ticket=ST-1032516-...
→ back to /guest → report runsThe server issues its own login ticket and signs the visitor in, with no credentials required. This is a documented SAS feature for guest access. The login system wasn't broken or bypassed. It worked exactly as configured, and it was configured to say yes to everyone.
Reading the incident against the evidence
Line up the reported facts with that setup:
- "Blocked from the Australian data." Bot-blocking on the website's front end, standard against AI crawlers by 2026.
- "Found a security workaround." The front end was blocked; the reporting engine behind it wasn't. Build the address from the site's own JavaScript (or from ten years of publicly cited URLs), call the guest endpoint directly, and the report comes back.
- "Accessed internal file names." The internal report paths are the file names, and after March 2025 the site published the formula for them, so there was nothing left to guess. The ABC reported that agents in public logs discussed guessing file names as a technique. On this site, they didn't have to.
- "Wrote files to the internal server." The scariest-sounding detail is the most mundane. Chart reports save their images to a temp folder on the server (the archive shows files like /statistics/temp/gph18MAR25-22-52-54.gif). Running a chart report is writing a file to the server.
None of this requires a software vulnerability. No exploit, no injection, no broken encryption. Only documented endpoints, working as configured, at addresses the site published itself.
The warning signs were there. In April 2025, Wayback captures show AI crawlers probing the domain. On 5 May 2026, six weeks before the incident, captures show direct calls to the internal reporting endpoint with correct paths. Who made them is unknown, but the route was known and used before 18 June.
So what was the actual failure?
Not unpatched software. The platform was refreshed in March 2025, and nothing observed looks like a version-specific exploit.
The failure was in who was allowed to see what:
- The lock was on the wrong door. The 2025 changes protected the human-facing website with bot-blocking and a login page, while the reporting engine underneath stayed open to guests.
- Public and non-public data sat behind the same gate. "Non-public" just meant "not linked from the menu."
- The hiding place was published. The site's own JavaScript revealed the naming scheme that the secrecy depended on.
Nobody noticed
- 18 Jun 2026: The incident.
- 26 Jun and 11 Aug 2026: The portal is still online and serving normally. Services Australia doesn't know.
- 10 Sep 2026: OpenAI notifies Services Australia, three months later, by email to a public inbox.
- 15 Sep 2026: Services Australia reports it to the Australian Signals Directorate.
- 24 Sep 2026: The PM reveals the breach at the UN General Assembly and announces a taskforce. The portal is fully offline.
The site stayed exposed for at least eight weeks after the incident, because the organisation running it had no idea anything had happened.
Why the fix is taking a while
Every path on the domain, even robots.txt, now returns a 503 "Service Unavailable" page. So they've panicked and pulled the plug.