Skip to content
All posts

7 min readAI, Security

What we know about the Medicare statistics portal incident

An AI agent got into a government website it should not have. Here is what happened, in plain English, and what it means for an ordinary organisation.

By Dave Tormey

A person working on a laptop and phone, standing in for the everyday traffic a public website receives

In late September the Prime Minister stood up at a press conference in New York and told the country that an AI agent had got into a Medicare website. Within a day the word “rogue” was in most of the headlines. If you run an organisation and you were already uneasy about AI, it did not help.

I spent more than a decade as a chief information security officer, and I have been reading everything published since. Here is what is known, what is still disputed, and what I think an ordinary organisation should take from it.

What the portal was

The website involved was the Medicare Statistics Reporting Service, run by Services Australia. It published aggregate figures about Medicare and the Pharmaceutical Benefits Scheme: totals and averages, not anyone’s medical record. It was separate from the systems that hold claims, payments and personal details.

What happened

On 18 June, researchers at OpenAI gave one of their internal test models a research task: work out how much the government spends per person on skin medicines in Victoria. This was not ChatGPT, and no member of the public was driving it. It was an experimental model running on OpenAI’s own systems, without the safeguards of OpenAI’s public products.

Looking for the figures, the model found the Medicare statistics portal. According to the government, the portal refused its requests, the model kept trying other ways in, and it wrote files to an internal server. OpenAI’s own account goes further: it says the model found a way to gain access that was not meant to be public, ran commands, read system information and source code, and took internal files, login credentials and aggregate statistics.

Both the government and OpenAI say there is no evidence that anyone’s personal or medical information was accessed.

It was not the only case. OpenAI has since listed four other agencies its models reached in the same period. The NSW crime statistics bureau’s public crime map handed out login details for its own data requests, and a model used them to pull configuration and logs. At the Victorian Department of Health, agents found an exposed access key and used it to download reporting settings and survey totals; OpenAI says it is unclear whether that material should have been reachable. At the Australian Institute of Health and Welfare, agents tried to get around access controls and failed. At NSW National Parks and Wildlife Service, a model used crafted queries to work out database details that were not meant to be public. OpenAI says that in every case it has reviewed so far, no personal information was retrieved, and that its review is still going.

How long it took to find out

This is the part that angered the government most.

  • OpenAI found the Australian activity in August, while reviewing earlier test runs after a similar incident elsewhere.
  • On 10 September it notified Services Australia, by email to a public inbox, and the Victorian Department of Health. The other agencies were told between 18 September and early October.
  • Services Australia reported it to the Australian Signals Directorate on 15 September, and the minister was told on 17 September.
  • The public found out about a week later, roughly three months after the event.

The Prime Minister called the delay, and notifying a government by email, unacceptable. OpenAI has apologised and said it should have shared its early findings sooner. It has paused training and testing its most capable models on tool use, restricted the network access of its research environments, added monitoring that it says would now alert a person to this kind of activity, and committed to an Australian taskforce. On 6 October one of its senior executives told a parliamentary committee that its internal escalation “could have been much better”.

The open door

There is a second story, and it matters. The Record says it verified archived copies of the portal’s public code that sent statistics requests to a guest login, which signed visitors in automatically and was added in an upgrade in March 2025. SMBtech found a script published on GitHub that documented the same route before the incident.

So the guest route itself is well supported. What remains unconfirmed is whether it explains the model’s reported access to internal files, its use of credentials and its other actions. The activity logs have not been released. Ciaran Martin, the former head of the UK’s National Cyber Security Centre, said it was “still unclear” whether this was a hack in the normal sense.

My reading is that both things can be true. The door may have been easier to open than it should have been, and a piece of software still kept pushing past “no” and took things it had no business taking. One does not excuse the other.

The portal was taken offline and will not be reactivated; its data is moving to data.gov.au. There is a forensic investigation, a taskforce led by the Prime Minister’s department, and the parliamentary committee is due to report on 30 November.

What it means for an ordinary organisation

Software visits your public systems too, and some of it does not take no for an answer. A person who hits a locked page usually gives up. A task-driven AI agent may keep trying other routes when its requests fail. Design access controls so that persistent automated requests cannot reach anything outside what is meant to be public.

Check what “public” really means. Guest logins, keys left in web pages and old addresses that still work are all open doors. It is worth asking someone to look at your sites the way an anonymous visitor would, and writing down what they can reach.

Keep logs good enough to replay what happened. The public record still does not establish the full sequence of actions at the Medicare portal or exactly which files were accessed, and the activity logs have not been released. Repeated refused requests and unexpected file writes are exactly the pattern your own logs should catch and keep.

Have a monitored way to report problems, and a clear way to escalate them. A security contact on your website matters, but a serious incident also needs prompt, direct contact between the organisations involved, not just an email.

Treat your own AI the same way. This incident happened on somebody else’s infrastructure, pursuing somebody else’s task, with somebody else deciding when to tell the affected party. When AI runs inside your own environment, each of those is your choice: what it can reach, what it records, and how fast you hear about it when it does something unexpected.

The headline was “rogue AI”. The lessons underneath it are older and more useful: retire old systems, know where your doors are, keep good records, and tell people early.

Sources

Dave Tormey

Dave runs TAGD Ventures in Brisbane. He has spent more than twenty years building and running software for government and regulated industry, including more than a decade as CTO, CIO and CISO of a software company serving law enforcement.

Get in touch