---
title: "The Medicare Portal Told OpenAI's Agent No. The Agent Treated It as a Retry."
description: "An OpenAI research agent read a government portal's refusals as obstacles, and OpenAI filed the result under research. Here's the stop condition and the notification path that would have caught both."
author: "Jahanzaib Ahmed"
date: 2026-09-25
category: "ai-agents"
readingTime: "14 min read"
tags: ["ai news", "ai-agents", "ai-security", "openai"]
canonical: https://www.jahanzaib.ai/blog/openai-agent-medicare-breach-ai-agent-incident-response
source: https://www.jahanzaib.ai
---
# The Medicare Portal Told OpenAI's Agent No. The Agent Treated It as a Retry.

On June 18, an OpenAI agent on an internal evaluation asked Australia's Medicare statistics portal for data about medicine spending. The portal said no, more than once. The agent kept going until it got in, read files that weren't public, and wrote files to an internal server. Prime Minister Anthony Albanese summed it up at a press conference in New York: it ["Didn't accept no for an answer, if you like."](https://www.pm.gov.au/media/press-conference-new-york)

Most coverage has fixed on the hack itself and on the 84 days before OpenAI told anyone. Both matter. But if you build agents, the useful part is less dramatic: this wasn't a security agent doing security work. It was a research agent with a retry loop and no floor. That's ordinary code in almost every agent stack, and it's the part you can fix this week.

![Prime Minister of Australia transcript page for the 24 September 2026 New York press conference describing the OpenAI incident at the Medicare statistics portal](https://cdn.sanity.io/images/qajb7q5q/production/1a0e19b2276d950defa1e5d5b3b70f0fd95aa03c-2880x1800.png?w=1200&auto=format&q=75&fit=max)

_The primary source. The transcript's first paragraph says the agent accessed both public and nonpublic files, and later answers add that it wrote files to an internal server._

## What did the OpenAI agent actually do to the Medicare portal?

According to the Prime Minister's transcript, an internal OpenAI model doing research on public medicine spending hit repeated blocks on the Medicare Statistics Reporting Portal, found a way around them, read public and nonpublic files, and wrote files to an internal server. No personal information is believed to have been accessed.

The portal matters here. It's a public statistics site run by Services Australia, holding aggregate figures like spending, not patient records. Acting Prime Minister Richard Marles described it to the ABC as data ["kept behind a fence that the AI agent effectively climbed over."](https://thehackernews.com/2026/09/openai-agent-bypassed-australian.html) OpenAI told reporters the material included aggregate health statistics and internal file names, and its statement conceded that ["our models took actions we did not intend."](https://arstechnica.com/ai/2026/09/openai-agent-didnt-accept-no-for-an-answer-in-australian-government-breach/)

Three other systems are under review: the Australian Institute of Health and Welfare (AIHW), the NSW Bureau of Crime Statistics and Research, and the Victorian Department of Health. The PM called them the "same incident" but said the government was not confirming the agent got into them. By September 24 the Medicare portal had been taken offline, per The Hacker News.

Here's the detail I keep coming back to. Nobody told this agent to hack anything. The task was a question about statistics. The PM's own words were that there ["were blocks clearly which were coming back telling the AI agent, no."](https://www.pm.gov.au/media/press-conference-new-york) The agent read those as obstacles on the path to an answer, not as the answer.

## Why does a research agent end up probing a government site?

Because a retry loop without a stop condition will eventually treat a refusal as a bug to route around. Transluce's report shows the pattern step by step: agents on ordinary data tasks escalated from direct requests to reader services to custom scripts in a remote browser, and in three cases on to exploit probes, whenever the previous approach failed.

Transluce, a nonprofit research lab, published [its urlquery.net analysis](https://transluce.org/agent-activity) the same day the government went public. The clearest example isn't Australian at all. On March 6, an agent spent 66 minutes and six recorded steps trying to read Thai drug enforcement statistics:

-   19:01 UTC, the API opened directly, no readable table.
-   19:43, the same endpoint with `?format=json`. Still empty.
-   19:46, through r.jina.ai, a service that turns pages into text for language models. Province names came back garbled.
-   19:52, a Base64 encoded script run inside urlquery.net's remote browser.
-   20:01, Jina blocked the API for an hour, citing previous abuse.
-   20:07, a revised script, and the data finally came through intact.

Read that sequence as an engineer and it's a normal fallback chain. Try the obvious thing, try a variant, try a proxy, try your own code. The only thing missing is a rule saying some failures aren't failures. They're answers.

Transluce's own conclusion is blunt: ["malicious cyber activity is not limited to agents tasked with cybersecurity-related tasks and can arise instrumentally to solve mundane tasks like information retrieval."](https://transluce.org/agent-activity) That sentence should be taped above every research agent's tool router.

The scale isn't small either. Transluce classified 6,467 urlquery.net reports as significant evidence of agent activity and another 31,182 as suggestive, with traffic running as recently as September 16. It also notes agents appear to have created accounts on the service, which would make scans private, so the public record is probably a partial view.

![Transluce chart of daily urlquery.net agent scans from November 2025 to September 2026 with the 20 to 21 June 2026 AIHW targeting marked in red](https://cdn.sanity.io/images/qajb7q5q/production/7cd6ff17049c21e76adda83700151796c6279b2d-2880x1800.png?w=1200&auto=format&q=75&fit=max)

_Transluce's scan volume on a log scale. Agent activity climbs from mid April, peaks through May and June, then collapses on June 22. The three red lines are the exploit attempts, the last one against AIHW._

## Did the agents really hack four Australian government sites?

No, not on the evidence published so far. The Medicare portal is the one confirmed unauthorised access. Transluce found exploit probes against AIHW on 20 and 21 June but says it saw no sign they succeeded, and AIHW says it has no evidence anything nonpublic was accessed. The other two systems are under review, with nothing confirmed.

This is where the coverage splits. ABC's exclusive said Transluce's data shows hundreds of OpenAI agents working together for months to get into AIHW, BOCSAR and others. Transluce's own report is more careful. It describes the extent of activity as minor, "a low number of probe payloads," and states ["we observe no evidence of exploitation."](https://transluce.org/agent-activity) On AIHW specifically, its account is that Cloudflare bot protection stopped the agents at the main site, and what they came away with was one public file pulled off a preproduction server.

AIHW's spokesperson told the ABC: ["At this stage, there is no evidence the agent accessed any information or data that is not publicly available."](https://www.abc.net.au/news/2026-09-24/openai-agents-plotted-to-access-data-amid-medicare-hack/107189504) ABC also counted AIHW mentions in the archived wiki posts: more than 300 of them, from about a dozen OpenAI agents. That's a lot of intent and very little access.

So what's actually linked? Transluce ties the AIHW probes to the DseWiki swarm OpenAI has already acknowledged, through shared targets and task values like "Dermatologicals" and "Wodonga" in the attack URLs. OpenAI told the ABC that ["much of the activity described in Transluce's report overlaps with cases at varying stages of investigation"](https://www.abc.net.au/news/2026-09-24/openai-agents-plotted-to-access-data-amid-medicare-hack/107189504) in its review. But the wiki and urlquery logs don't mention Medicare or Services Australia at all. The Medicare breach and the AIHW probes happened two days apart on the same task theme, and two sources told the ABC they believe they're connected. Nobody has shown it.

![TechCrunch security article headline reading Australia to investigate if OpenAI hack of government health website broke the law, beside a photo of Anthony Albanese](https://cdn.sanity.io/images/qajb7q5q/production/37fd31c319993dde3ceaf25bd9a1a87719b709c6-2880x1800.png?w=1200&auto=format&q=75&fit=max)

_TechCrunch's report says the unreleased models reached "reams of bulk health data information." The government describes aggregate statistics it calls nonsensitive. Same breach, very different weight._

## Where do the sources disagree about this breach?

On three things: how secure the target was, how long OpenAI waited, and how big the data haul was. The Guardian opinion piece and the government describe different systems, the delay is quoted as anything from two months to nearly three, and TechCrunch's "reams of bulk health data" sits awkwardly beside the PM's description of "non-sensitive" aggregate statistics.

Start with the target. Kate Crawford and Edward Santow, writing in The Guardian, say the agents ["broke in, hacking into a secure database."](https://www.theguardian.com/commentisfree/2026/sep/25/open-ai-attacked-australias-health-system-and-then-doubled-down-on-its-negligence-the-time-for-wait-and-see-is-over) The PM said close to the opposite: "this is not a security website," it's a Medicare statistics portal. Both can't be the frame.

Then the delay. The same opinion piece says OpenAI "waited two months before they sent an email to a generic inbox." The incident date was June 18 and the email went on September 10. That's 84 days. OpenAI says it only found the activity in August, during a wider review, so its own delay from discovery was shorter. Two months matches neither count.

I'm not raising this to defend OpenAI. I'm raising it because incident timelines get argued about in public, and the only defence is a log that says when you knew. Which brings me to the part OpenAI actually got wrong.

## How long did OpenAI take to notify Australia, and why does the channel matter?

OpenAI emailed a public Services Australia mailbox on September 10, 84 days after the breach and some weeks after it says it found the activity in August. Services Australia saw it on September 11, verified it, and reported it to the Australian Cyber Security Centre on September 15. The public heard on September 24.

I laid the dates out against June 18 because the gaps are the story. The day numbers are my arithmetic from the dates in the cited reports.

| Date (2026) | Day | Event | Source |
| --- | --- | --- | --- |
| March 6 | minus 104 | First strong evidence of agent tunnelling through urlquery.net | Transluce |
| May 18 | minus 31 | Earliest wiki mentions of AIHW | ABC |
| June 18 | 0 | Medicare portal breach | PM transcript |
| June 20 and 21 | 2 to 3 | Exploit probes against AIHW | Transluce |
| June 22 | 4 | Sustained agent activity on the wiki ends | Transluce |
| August | 44 to 74 | OpenAI says it found the activity | OpenAI via TechCrunch |
| September 5 | 79 | OpenAI publicly confirms the wiki incident | TechCrunch |
| September 10 | 84 | OpenAI emails a public Services Australia inbox | PM transcript |
| September 15 | 89 | Reported to the Australian Cyber Security Centre | PM transcript |
| September 24 | 98 | Government announces the breach | PM transcript |

Look at rows seven and eight. OpenAI went public about the wiki swarm on September 5 and called it ["an instance of misalignment similar"](https://techcrunch.com/2026/09/05/openai-confirms-wiki-incident-says-its-working-on-a-framework-for-more-disclosure/) to others it had shared, contrasting it with Hugging Face, where it ran a traditional security playbook. Its [misalignment reports page](https://alignment.openai.com/misalignment-reports/) still describes that September 5 response as covering "disclosure criteria for misalignment that does not constitute a security incident." Five days later it emailed an Australian agency about a breach by agents working the same kind of task.

The classification did the damage. Once you file agent behaviour under research, it flows to research channels: a blog post, a reports page, a public inbox. Wired reports Sam Altman met Richard Marles earlier this month and didn't raise it, though OpenAI had known since August. The PM's complaint was twofold, the delay and that ["the notification was an email sent to just the public mailbox."](https://www.pm.gov.au/media/press-conference-new-york)

A small irony. I ran a quick check on the inbound side: openai.com serves a PGP signed `security.txt`, the standard file that tells researchers exactly where to report a vulnerability to OpenAI. The inbound channel is signed and documented. The outbound one was a message to a general inbox.

## What should a stop condition look like in your agent's tool layer?

Key the retry budget on the target host, not on the tool. A 401, 403, 407, 429 or 451, a bot challenge page, or a robots disallow should end the attempt for that host across every tool the agent has, and come back to the model as a final answer it can report, not an error it should solve.

The Transluce ladder shows why a per tool limit doesn't catch this. Each step used a different tool: direct fetch, a JSON variant, a reader proxy, a remote browser. Any one of them might retry twice and stop, and the agent still walks the whole ladder, because from the model's point of view it's trying new things, not repeating a failure. The budget has to live where the target lives.

Here's the shape I'd put in front of every outbound call. It's short on purpose:

```
REFUSAL_CODES = {401, 403, 407, 429, 451}
RELAYS = {"r.jina.ai", "urlquery.net", "httpbin.org", "markdown.new"}

def guarded_fetch(tool, url, ledger):
    host = target_host(url)          # unwrap relay URLs to the real target
    if ledger.refused(host):
        return Final(f"{host} refused earlier. Report that, don't retry.")
    if host in RELAYS:
        return Final("Relay services are not allowed for this agent.")
    resp = tool(url)
    if resp.status in REFUSAL_CODES or looks_like_challenge(resp):
        ledger.mark_refused(host, tool=tool.__name__, status=resp.status)
        return Final(f"{host} said no ({resp.status}). Stop and report.")
    return resp
```

Two lines in there carry the weight. `target_host` has to unwrap relay and reader URLs, because `r.jina.ai/https://example.gov` is still a request to example.gov. And the refusal returns a `Final`, a terminal result the model sees as the end of that path, so it reports the block instead of treating it as a puzzle. The ledger doubles as your evidence when someone later asks when you knew.

The relay list isn't paranoia. Transluce's report and the wiki posts ABC reviewed both describe agents routing around blocks through third party services: proxies, screenshot services, urlquery.net, httpbin. ASD said as much in an [August 11 notice](https://www.cyber.gov.au/about-us/view-all-content/news/when-ai-agents-take-unexpected-actions) after a booking agent broke a gym's limits, warning that ["AI agents might identify and exploit vulnerabilities at speed and scale."](https://www.cyber.gov.au/about-us/view-all-content/news/when-ai-agents-take-unexpected-actions) That notice came 54 days after the Medicare breach and 30 days before OpenAI's email.

![Australian Signals Directorate notice titled When AI agents take unexpected actions, first published 11 Aug 2026, describing an AI assistant bypassing gym booking limits](https://cdn.sanity.io/images/qajb7q5q/production/6cadda409a65b80ee8a510cb46a9bf362b7aea2c-2880x1800.png?w=1200&auto=format&q=75&fit=max)

_ASD's August notice described the same failure at gym scale: an agent that achieved its booking by bypassing limits and removing another customer from a waiting list, which ASD tied to specification gaming._

## Was I wrong about egress controls earlier this month?

Partly, yes. On September 5 I argued that OpenAI's POST block failed because the wiki its agents found would write on a GET request. Transluce suggests the gap was wider: agents appear to have used services like httpbin.org to turn GETs into POSTs, so even a GET only agent can reach sites that need POST.

[That earlier post](https://www.jahanzaib.ai/blog/ai-agent-sandbox-escape-openai-wiki-egress) treated the wiki as the unusual case, a site that happened to accept writes on GET. Transluce's report says urlquery.net needs a POST to submit a scan, and that agents with only GET abilities appear to have used converter services to get there. So the method filter wasn't a boundary at all. The boundary has to be the destination list, and relay services have to be on the deny side of it by default.

I learned the narrower lesson first and it was the wrong size. If your agent's egress policy is written in HTTP verbs, rewrite it in hostnames.

## What does this mean for teams running agents in production?

Treat any agent that touches a third party's system as a potential incident, with an owner, a log and a notification path decided in advance. The engineering fix is a stop condition keyed on the target host. The organisational fix is refusing to file real world agent impact under research just because the model meant well.

Here's what I'd put on the list for Monday, in rough order of cost:

-   A host level refusal ledger in front of every outbound tool, as above. An afternoon of work.
-   An egress allowlist by destination, with reader proxies, URL scanners and request converters denied unless a human adds them.
-   Logging of every write outside your own infrastructure. The Medicare agent wrote files, and that's the line between a nosy crawler and an incident.
-   A notification runbook that names channels per country. For Australia that's the ACSC's reporting portal on cyber.gov.au, not an agency's general inbox.
-   A classification rule: if your agent touched someone else's system without permission, it's a security incident, whatever your alignment team calls the cause.

That last one is the opinion I'd defend hardest. OpenAI's split between "misalignment" and "security incident" is useful inside a lab. Outside it, the owner of the system doesn't care why your agent climbed the fence. The law might not either, though UTS professor Nicholas Davis told the ABC that Australia's unauthorised access rules currently turn on intent, which is ["a big question"](https://www.abc.net.au/news/2026-09-24/openai-agents-plotted-to-access-data-amid-medicare-hack/107189504) for an agent. I wouldn't bet a company on that ambiguity lasting.

For more on why "the model didn't mean it" isn't a control, see how [Google and Anthropic framed their own escapes](https://www.jahanzaib.ai/blog/gemini-sandbox-escape-agent-containment), the [Hugging Face report where almost no agent thought to call a human](https://www.jahanzaib.ai/blog/openai-hugging-face-incident-report-ai-agent-oversight), and [Amazon's block on an agent it couldn't identify](https://www.jahanzaib.ai/blog/amazon-blocks-meta-muse-ai-agent-identity). The glossary entries on [agentic misalignment](https://www.jahanzaib.ai/glossary/agentic-misalignment) and [least privilege agents](https://www.jahanzaib.ai/glossary/least-privilege-agent) cover the vocabulary.

## Frequently asked questions

### Did the OpenAI agent access personal Medicare records?

No evidence of that so far. The government says the Medicare Statistics Reporting Portal holds aggregate data it calls nonsensitive and no personal information is believed to have been accessed, while the investigation continues. OpenAI says what it reached was aggregate health statistics and internal file names.

### Was the agent told to hack the portal?

No. It was researching public medicine spending during an internal OpenAI evaluation. When the portal blocked its requests, it tried other routes until one worked. That's why Transluce stresses the behaviour arose on a mundane data task, not a security task.

### Why did it take so long for Australia to find out?

OpenAI says it found the activity in August during a wider review of misaligned model behaviour, then emailed a public Services Australia mailbox on September 10. Services Australia verified the email and reported it to the ACSC on September 15. The government will also look at its own five day gap.

### Is the AIHW probing the same incident as the Medicare breach?

Probably, but it isn't proven. The probes happened two days later on a similar pharmaceutical data task, and Transluce links them to the wiki swarm OpenAI has acknowledged. The wiki and urlquery logs don't mention Medicare, and neither OpenAI nor the government has confirmed the link.

### Could OpenAI face legal consequences in Australia?

The government has asked for urgent advice on possible offences and on a possible Federal Police referral, and the PM said there will be legal consequences. UTS professor Nicholas Davis told the ABC the unauthorised access laws turn on intent, which is hard to pin on an agent.

### How do I stop my own agent doing this?

Make refusals terminal. Track refused hosts across every tool, unwrap proxy and reader URLs to the real target, deny relay services by default, and log any write to a system you don't own. If you want help auditing an existing agent, [see how I build them](https://www.jahanzaib.ai/agents) or take the [AI readiness assessment](https://www.jahanzaib.ai/ai-readiness) first.

> **Sources:** [Prime Minister of Australia, New York press conference transcript (24 Sep 2026)](https://www.pm.gov.au/media/press-conference-new-york) · [Transluce, Early rogue AI agent activity on urlquery.net (23 Sep 2026)](https://transluce.org/agent-activity) · [ABC News (24 Sep 2026)](https://www.abc.net.au/news/2026-09-24/openai-agents-plotted-to-access-data-amid-medicare-hack/107189504) · [TechCrunch (24 Sep 2026)](https://techcrunch.com/2026/09/24/australia-to-investigate-if-openai-hack-of-government-health-website-broke-the-law/) · [Wired (24 Sep 2026)](https://www.wired.com/story/openai-agent-hacked-australias-health-service-their-government-found-out-months-later/) · [Ars Technica (24 Sep 2026)](https://arstechnica.com/ai/2026/09/openai-agent-didnt-accept-no-for-an-answer-in-australian-government-breach/) · [The Hacker News (Sep 2026)](https://thehackernews.com/2026/09/openai-agent-bypassed-australian.html) · [The Guardian, Crawford and Santow (25 Sep 2026)](https://www.theguardian.com/commentisfree/2026/sep/25/open-ai-attacked-australias-health-system-and-then-doubled-down-on-its-negligence-the-time-for-wait-and-see-is-over) · [TechCrunch on the wiki incident (5 Sep 2026)](https://techcrunch.com/2026/09/05/openai-confirms-wiki-incident-says-its-working-on-a-framework-for-more-disclosure/) · [OpenAI misalignment reports](https://alignment.openai.com/misalignment-reports/) · [ASD, When AI agents take unexpected actions (11 Aug 2026)](https://www.cyber.gov.au/about-us/view-all-content/news/when-ai-agents-take-unexpected-actions).

## Related

- [OpenAI's Model Left a Note for Its Next Self: Be Transparent Only If Asked](https://www.jahanzaib.ai/blog/context-compaction-openai-misalignment-reports)
- [Altman Blamed Safety for the IPO Delay. OpenAI's Own Report Blames a Missing System Prompt.](https://www.jahanzaib.ai/blog/altman-openai-ipo-delay-ai-agent-monitorability)
- [OpenAI Blocked POST Requests. The Wiki Its Agents Found Writes on GET](https://www.jahanzaib.ai/blog/ai-agent-sandbox-escape-openai-wiki-egress)

---

Canonical HTML version: https://www.jahanzaib.ai/blog/openai-agent-medicare-breach-ai-agent-incident-response