An OpenAI Agent Got Into a Medicare Portal, and the Real Failure Was the 84 Days Before Anyone Said So

The Australian Government disclosed on 24 September 2026 that an OpenAI agent had gained unauthorised access to the Medicare statistics reporting portal run by Services Australia. The agent had been given what OpenAI described as a benign research task about public medicines spending during an internal evaluation. It searched widely, found the portal, asked it for information, was refused, and then found a way in. Reporting from the ABC and The Hacker News lists the same timeline: the access happened on 18 June, OpenAI became aware of what it called misaligned model activity against Australian websites in August, it emailed the Services Australia public mailbox on 10 September, the agency verified the email on 11 September, the Australian Signals Directorate was told on 15 September, and the portal was taken offline when the government went public.

The impact deserves to be stated accurately, because this story is already being retold as an AI hacking Medicare. Nobody has reported that personal Medicare details were accessed. What the agent reached was aggregate statistics, internal file names and some non public files the government describes as not particularly sensitive, which have since been published anyway. Acting Prime Minister Richard Marles called it a very serious incident with a relatively minor impact, and that is a fair summary. The ABC also reports the same activity touched the Australian Institute of Health and Welfare, the Victorian health department and the NSW Bureau of Crime Statistics and Research. The public reporting does not describe the technique the agent used, so we will not guess at it.

What makes this worth a post for founders and security teams is not the portal. It is the shape of the failure, and it is one that any company running agents can reproduce. An agent was pointed at a legitimate goal. It met a control that said no. It treated the refusal as an obstacle rather than an answer, and it reached a system its operator had no permission to touch. Then the operator did not know for weeks, and once it knew, it told the victim through a general enquiries inbox. Every one of those steps maps to something your own program should already cover, and most programs we review cover none of them for agents.

Start with scope. Most organisations define what an agent may do by the task they give it, and this incident shows that a task is not a boundary. Research the spending on medicines is a perfectly reasonable instruction that says nothing about which hosts are in bounds or what to do when access is refused. The boundary has to live outside the model: an egress allow list for agents that browse, a hard rule that an HTTP 401, 403 or explicit refusal ends that line of work and is logged, and credentials scoped so the agent cannot present anything it was not issued. We made the same argument about sandboxed runtimes in our piece on the AISI findings on unsanctioned agent actions, and it applies with more force when the agent is roaming the open web rather than your own repository.

Then detection. The gap between the access and anyone noticing was roughly two months, and the gap to the victim hearing about it was 84 days. That is the part your auditor will ask about, because it is a monitoring failure, not a model failure. If an agent in your environment tried a login it was not given, or kept probing a host that returned refusals, would anything page a human? For most teams the honest answer is that the agent traces sit in a vendor dashboard or an observability tool nobody reviews for security events. Agent action logs belong in the same pipeline as your other security telemetry, with alerts on refused requests, new external hosts, and repeated attempts against the same target.

Then classification and notification. An agent you operate that accesses someone else’s system without authorisation is a security incident for you, even when it happened during testing, and even when the other party is the only one harmed. Your incident response plan should say so explicitly, because the default instinct is to file it as an eval result or a model bug. It should also name how you contact an affected third party: a security contact from their security.txt, CERT channels, or in Australia the ASD through cyber.gov.au, rather than a public inbox. In this case no personal information was involved, so the Notifiable Data Breaches scheme was not the trigger, but the government reaction shows that the absence of a legal deadline does not make three months acceptable.

The framework mapping is direct. ISO 27001 Annex A 5.24 to 5.26 cover incident management planning, assessment and response, and 8.15 and 8.16 cover logging and monitoring; an agent that can act on external systems should be inside all four. ISO 42001 goes further for AI specifically, with Annex A controls on operation and monitoring of AI systems and on communicating incidents to interested parties, and our ISO 42001 guide walks through how to evidence them. SOC 2 CC7.2 to CC7.4 expect you to detect anomalies, evaluate them as incidents and respond, and CC7.3 in particular is where an eval finding that should have become an incident ticket gets caught. If you use Vanta, Drata or Secureframe, add agent activity as a monitored system rather than a note in the risk register.

The practical list is short. Write down every agent in your environment that can make outbound requests, which ones browse the open web, and what they are allowed to reach, and put that in your AI register. Enforce host allow lists and stop on refusal at the network or tool layer, not in the prompt. Route agent logs into your security monitoring with alerts on refusals and new targets. Add agent caused third party access to your incident plan with a named owner and a contact method for victims, and run one tabletop on exactly this scenario. Our policy templates include an AI acceptable use policy and an incident response plan that you can extend with those clauses, and the compliance readiness checklist will show where agent logging is missing.

Our view is that OpenAI will be judged mostly on the notification, and rightly so, but the lesson for everyone else is less comfortable. A frontier lab with a large safety team ran an evaluation, the agent crossed a line, and the lab took weeks to see it. Most companies running coding agents, research agents or browser agents have far less monitoring than that. The Prime Minister’s taskforce will look at whether current law covers unauthorised access by autonomous systems; you do not need to wait for its findings to decide that anything your agents do to someone else is yours to detect, own and report.