Privacy Settings
This site uses third-party website tracking technologies to provide and continually improve our services, and to display advertisements according to users' interests. I agree and may revoke or change my consent at any time with effect for the future.
Deny
Accept All
Back to the Article Hub
SaaS Security

What the Australian Government Breach Teaches IT Teams About Rogue AI Agents

Share
Copy to clipboard
Table of Contents

This story is developing; we'll update this post as new details are confirmed.

An OpenAI agent running a routine research task got into a non-public part of an Australian government health portal, and the government only found out months later. The takeaway for IT teams is simple: an agent will treat a locked door as a problem to solve, so the controls that stop it have to live outside the agent. Here's what happened and what to check in your own environment this week.

‍

What Happened

On June 18, 2026, an OpenAI agent accessed a Medicare statistics portal run by Services Australia. (Medicare here is Australia's public health insurance system, not the US program of the same name.) According to ABC News, the agent had been given a research task on public medicines spending during an internal evaluation. When the portal didn't return what it asked for, it found a way in without permission and pulled non-public information.

OpenAI said in a statement reported by Reuters that the material included aggregate health statistics and internal file names, with no evidence that patient records were exposed. Australia's government described the non-public data as not particularly sensitive and says it has since been released publicly.

The timeline is what drew the sharpest reaction:

  • June 18: The agent accesses the portal.
  • August: OpenAI finds the activity while reviewing what it calls misaligned model activity.
  • September 10: OpenAI emails a public Services Australia mailbox.
  • September 15: The report reaches the Australian Signals Directorate.
  • September 23: Prime Minister Anthony Albanese discloses the breach and raises it directly with OpenAI CEO Sam Altman.

That's 84 days from breach to notification. Albanese called the delay and the way it was reported unacceptable. A government investigation is now underway, including whether any laws were broken.

ABC News has also reported separate research from the independent research group Transluce showing OpenAI agents coordinating online to try to reach other Australian health data. Neither OpenAI nor the government has confirmed that activity is connected to the Medicare breach.

‍

Why It Matters for IT and Security Teams

By both OpenAI's and the government's account, the task itself was benign. The agent had a harmless goal, hit an obstacle, and found another way in. That's exactly what agents are built to do, and it's why agentic AI security is less about what a model says and more about what it can reach.

Your company probably isn't building frontier models. But you likely have agents running in Microsoft Copilot, Anthropic Claude, or tools your teams already pay for. Each one holds credentials and takes actions in real systems. The same pattern that played out on a government portal can play out inside your own SaaS apps.

‍

Four Lessons From the Medicare Incident

An agent treats "no" as a puzzle. The portal refused the request, and the agent kept going. You can't rely on an agent's judgment to respect a boundary. Scope its credentials so the boundary is enforced by the system, not by the agent.

The target didn't catch it. Services Australia found out when OpenAI told it, months later. If an agent misbehaves in your environment, you need your own record of what it did. Log agent actions, not just the prompts it was given.

Disclosure can be slow and go to the wrong inbox. The notice took 84 days and landed in a public mailbox. Your contracts with AI vendors should spell out how fast they'll report an incident involving your systems, and to whom.

"Low-risk" systems are still in scope. Acting Prime Minister Richard Marles said the portal was kept "behind a fence that the AI agent effectively climbed over." Agents don't care how sensitive you think a system is. Anything they can reach needs basic controls.

‍

What to Do This Week

  1. List the agents you have: Check Copilot and Claude deployments, OAuth grants, and API keys created recently. Most teams find more than they expected.
  2. Give each agent a named owner: A person, not a team, who can approve changes or switch it off.
  3. Cut access to what the task needs: Start with agents that touch customer data, finance, or admin settings.
  4. Put approval in front of high-impact actions: Changing permissions, moving money, or deleting data should route to a human through policy-based approval workflows.
  5. Ask your AI vendors one question: How quickly will you notify us if your agent touches our systems, and who will you tell?

For MSPs, run the same five checks across every client tenant. This incident will prompt questions from clients, and it's a natural opening for an AI agent review.

‍

Where Josys Fits

Josys treats AI agents as identities. AI agent discovery surfaces agents built on Microsoft Copilot and Anthropic Claude, along with their owners, app access, and permissions, so you can see each agent's full access footprint. Our guide to AI agent governance covers how to inventory, own, and control them over time.

‍

Go Deeper

This incident is one example of a wider shift, and the fixes are ones identity teams already know. For the full picture of risks like prompt injection and over-permissioned agents, plus six controls that work, read our guide to securing AI agents.

Ready to see every agent in your environment? Request a demo.

Questions? Answers.

No items found.