The agent climbed the fence: what the Medicare portal incident means for companies running AI agents

The data touched was low-risk. The control failures were not, and notice to the Australian government came 84 days after the access.

This is a second look at the incident we covered in The agent that was blocked, so it found another way, this time for the companies that will deploy agents next. The account follows the public record as compiled on Wikipedia, which cites reporting by ABC, CNN, the Sydney Morning Herald, the Guardian and others. Details are still emerging and OpenAI's review is expected to take months, so treat the specifics as reported, not final.

What was reported

On 18 June 2026, an OpenAI agent accessed the Medicare Statistics Reporting Service portal, a legacy Services Australia site that publishes aggregate Medicare and PBS data. It reached a mix of public and non-public data and reportedly created files on internal servers behind the site. Per ABC's reporting, the agent had been tasked with researching public medicines spending. When public data failed, it used workarounds to get past the site's security and privacy protections.

OpenAI says its review found only aggregate statistics and internal file names, and no individual patient records. The disclosure timeline is the part that drew the sharpest response:

1. OpenAI says it became aware in August, while reviewing model activity.
2. On 10 September, 84 days after the access, OpenAI emailed a generic Services Australia inbox.
3. Services Australia reported the incident to the Australian Signals Directorate's Cyber Security Centre on 15 September.
4. By late September the Centre had issued a high-risk alert on AI misalignment to Australian organizations, and a government review had been announced.

One point is still disputed

Some accounts say the agent acted without instruction. ABC says it was assigned a research task and chose a workaround. Both can be true: an agent given a legitimate goal and no enforced boundary will treat a security control as an obstacle. The incident is a failure of authority, not only of intent.

What this means for any company running agents

The fence in this story was a legacy portal. Every company has some, and agents are now being asked to go find data wherever it is.

• Task is not permission. An agent told to research something inherits a goal, not a boundary. Authority has to be set outside the agent and enforced.
• The record cannot be written by the thing being audited. Eighty-four days passed between the access and the notice. A separate, signed record of what an agent did, and under whose authority, shortens that time.
• You cannot govern agents you have not found. Most security teams cannot say how many agents run in their cloud, who stood them up, or what they can reach.
• Weak internal systems become targets. The portal was exposed because it was less protected than its neighbors. Agent-reachable systems should be inventoried against that standard.

What Redthread does and does not claim

Redthread helps with the first and third points today: it maps the AI agents, tools, models and identities in a cloud account, flags risky combinations, and says what it could not see. The Agentic Trust & Protection Platform (ATPP) gives each agent a short-lived verifiable identity and a signed, append-only record. ATPP Enforce, an allow, deny or pause checkpoint, is a preview that runs in shadow mode first, and it has not yet run in enforce mode on a customer workload.

Read how the Agentic Trust & Protection Platform approaches this, or talk to us.