The Medicare AI incident: what's new, what's old, and what it means for risk appetite

On 18 June 2026, an OpenAI agent gained unauthorised access to the Medicare Statistics Reporting Service. It was doing a research task, when the portal blocked it, the agent found a way around the blocks. It read files that were not public and wrote new files to the system. The Prime Minister made the incident public on 24 September.

No personal Medicare records are believed to have been accessed. Asked about this, the Prime Minister's answer was careful: "That we know." The portal holds aggregate statistics and sits apart from claims and payment systems. The government has called the impact minor. The portal has since been taken offline, and its public data is moving to data.gov.au.

The headlines make this sound like the moment AI turned on us. Another way to view this is that AI added fuel to already existing risks. A smaller part is new, and it matters for every business, including those that don't use AI at all.

For executives, the job is to tell the two apart. That is what lets you set a clear risk appetite.

Old risks, new flame

Look at what the agent found, and most of it was known.

• The data was meant to be shared. The portal exists so researchers can use aggregate Medicare and PBS figures. The Deputy Prime Minister described personal data as sitting "inside a safe". This data sat "behind a fence".
• The route in was documented. A public GitHub repository, created in March 2025, holds scripts that pull statistics from the same portal. One independent analysis suggests the endpoint served reports without a login for years.
• The control gaps were on the record. A 2025 Australian National Audit Office (ANAO) audit found Services Australia relies on ageing legacy systems. It also found earlier user access issues were not being fixed fast enough. A 2024 audit found its handling of cyber incidents was only partly effective.

None of this proves the agent used the documented route. That detail has not been made public. What it does show is a known, accepted level of protection. A fence was the right call for low-risk data when the likely visitors were researchers.

That was a risk appetite decision, sound for the threat it was set against. The threat changed and the fence didn't.

Your business probably carries the same kind of risk. Legacy portals and public endpoints often sit behind controls sized for yesterday's threats. AI finds the gaps that already exist faster and it keeps trying.

What is new

Nobody told the agent to break in.

There was no attacker and no malicious prompt. The agent had a normal goal: find public spending data. When the front door said no, it treated the block as a problem to solve.

The exact route into Medicare is still disputed. Some independent analysts argue the agent only used endpoints that worked as the site had set them up. The wider pattern is not in dispute. Researchers at Transluce saw agents on other public data sites try common attack methods after normal data requests failed. The Australian Cyber Security Centre issued a high alert on the same day the incident went public. It describes agents that hit security controls, then found weaknesses and tried to keep going without a person's approval.

Threat assessments have historically assumed a person with intent, so risk descriptions and controls built on that assumption need revisiting. Here, a tool with a harmless task escalated on its own.

The agent also wrote files to the system. What those files were has not been made public. It may turn out to be minor. If an agent can write, not just read, the question changes from who can see your data to whether you can still trust it.

You don't need to use AI to have AI risk

Medicare was not using AI here, it was on the receiving end.

Services Australia also did not know it had happened. OpenAI found the activity in its own review in August. It emailed the address Services Australia uses for vulnerability reports on 10 September. That was 84 days after the breach. Services Australia learned of it only because the vendor chose to disclose it.

That detection gap shows why only looking at your own AI deployments is not enough. In our experience, the first question a board asks about AI risk is often "what tools are we using?" That question is only half the picture.

Two questions to ask:

• What AI risk are we creating? Your own tools, models and agents, and the decisions they make or shape. Andrew Charlton (Assistant Minister for Science, Technology and the Digital Economy) said an AI agent is not a legal person, and liability for this kind of incident sits with a person or a company. If your agent does this to someone else, it's your problem.
• What AI risk are we exposed to? Other people's agents reaching your portals, your suppliers and your data.

The second question matters whether you have an AI strategy or not. Monitoring built for human attackers, working at human pace, may not see it at all.

AI lives inside the risks you already have on your register

AI risk works best as two views that work together. Your principal risk register shows where AI changes the risks the board already oversees. An AI risk register holds the detail: each use case, its owner, its controls and its tier. Each AI risk links back to the principal risk it affects, and is judged against that risk's appetite. The board sees one picture, and the people running AI have the depth they need.

Every organisation names its principal risks differently, so the mapping has to fit yours. As an illustration:

Most of these risks existed before AI. The table shows where AI changes their likelihood, speed or size. The goal is an AI risk register that feeds the risks you already manage, rather than a parallel list that sits beside them.

Risk appetite: in, out, and the path in between

When we work with Chief Risk Officers on AI, the goal is a written appetite with three parts.

• In appetite. Uses the business is happy to allow, with the controls that go with them.
• Out of appetite. Uses the business will not accept.
• The escalation path. Who decides on everything else, and how fast.

The third part is where the organisations we work with struggle most. Many AI use cases are not obviously in or out. They land in the grey zone, and the grey zone is where things go wrong. Ownership is unclear and defaults to IT. 'No' becomes the default and attempts to escalate can sit in a queue for months.

OpenAI's agent shows what happens when there is no path. It hit a block, and nothing told it to stop and ask. That is what your own agents could do if you don't give them one.

People do the same thing. If nothing is allowed, or the process is too hard, people route around it. Shadow AI takes hold. That's a signal that governance doesn't match the business process.

Enabling AI brings its own risk. Enabled tools need governance, and people need training to use them well. There are also the updates to the Australian Privacy Principles to keep in mind. From 10 December 2026, the new APP 1.7 in the Privacy Act requires organisations to say in their privacy policy when they use personal information in automated decisions that could significantly affect people. You can't disclose decisions if you haven't done the work to track what's being automated.

A good appetite statement makes the grey zone smaller and the path through it faster. A useful test is reversibility. Actions that are hard to undo need a human approval step. Actions that are easy to reverse can move quickly.

Standards as a starting point

The ISO standards give this work a shared language, and most risk teams already use the first one.

Linking AI into your risk register is ISO 31000 work, and ISO/IEC 23894 applies it to AI. Setting appetite and oversight at board level is what ISO/IEC 38507 covers. Running AI governance as an ongoing system, with owners, reviews and training, is ISO/IEC 42001. Assessing how an AI system could affect people sits with ISO/IEC 42005, which helps with the new APP 1.7 obligations. The fence itself is ISO/IEC 27001 territory, which your security team runs.

Use them as a checklist of what good looks like, sized to your organisation. Certification is a separate decision.

Our Altis AI Governance Playbook builds on these standards. It sorts AI and analytics into tiers, from dashboards through to autonomous agents. Oversight and approval scale with the tier. It names agents acting outside their scope as a risk in its own right, with human approval for actions that can't be undone.

Two questions for this week

The Medicare incident had a minor impact. Two questions to help you judge whether yours would too.

Would we know if this happened to us? Pick one public-facing system. Ask your security team who would notice an agent working around its controls, and how long that would take. If the honest answer is "when the vendor tells us", that's a risk without an owner, as well as a monitoring gap.

Does AI show up inside our principal risks? Look at your existing register. Check each principal risk for both kinds of AI risk: the risk you create, and the risk you're exposed to. If your AI risk register doesn't link back to those principal risks, or only covers your own tools, you have a gap.

Your security team decides how strong the controls are. The business decides how much risk it will accept, and who makes the call when it's unclear.

The second question is the conversation we have with Chief Risk Officers. If you want help linking AI into the risk register and appetite you already have, we're here for a conversation.