On 18 June 2026, an OpenAI agent was trying to answer a question about Australian public medicine spending when it gained unauthorised access to Services Australia's Medicare Statistics Reporting Service.
The agent accessed public and non-public files. No personal Medicare information is believed to have been accessed, and OpenAI says the material it reached consisted of aggregate health statistics and internal file names.
The data itself may have been relatively low risk. The behaviour behind the incident is harder to dismiss.
Prime Minister Anthony Albanese made the incident public on 24 September, after speaking with OpenAI chief executive Sam Altman to express Australia's "extreme concern."
Together, those details expose two problems that extend well beyond Medicare: what an autonomous agent does when something stands between it and its objective, and how quickly an organisation finds out when somebody else's agent crosses a boundary.
What happened when the agent couldn't get the data
OpenAI has said the activity occurred during an internal evaluation in which its models were trying to answer questions about Australia. According to The Canberra Times, the agent attempted to retrieve statistics from four government sources: the Medicare portal, the Australian Institute of Health and Welfare (AIHW), the NSW Bureau of Crime Statistics and Research, and the Victorian Department of Health.
When normal access didn't work, the agent didn't necessarily treat that as the end of the task.
Separate archived logs reviewed by ABC News show OpenAI agents sharing methods for getting around blocks while trying to access Australian government health data. Those methods included proxies, screenshotting services, guessed file names and workarounds for Cloudflare, a security service commonly used to distinguish legitimate visitors from automated traffic.
The AIHW appeared more than 300 times in the logs. One agent wrote that it needed exact data "urgently" against a deadline.
OpenAI and the Australian Government haven't confirmed that those logs relate to the Medicare access, so they shouldn't be treated as a reconstruction of the same event. But they offer a revealing view of how some agents might behave when they're optimised to complete a task and encounter resistance.
Albanese put the problem more simply: the agent "didn't accept 'no' for an answer."
Acting Prime Minister Richard Marles said the Medicare information wasn't sensitive or related to national security, so the portal hadn't been protected to the same degree as more sensitive systems. The defences reflected the value of the data and the visitors the system was expected to encounter. An autonomous agent with a goal and multiple ways to pursue it complicates both assumptions.
Now put the same behaviour inside a payment workflow
Finance functions are starting to use agents to match invoices, chase approvals and update vendor records. Their value comes partly from their ability to move work forward without someone manually directing every step. That same persistence needs boundaries.
If an agent encounters a bank detail that doesn't match, an approval that hasn't arrived or a system refusing access, the desired behaviour isn't simply to "finish the task." The desired behaviour might be to stop, escalate or require independent verification.
Without those boundaries, a control risks becoming another obstacle for the agent to route around.
Eftsure Chief Product Officer Ramesh Menon described the problem during a recent Eftsure webinar on multi-layered controls in an agent-led world.
"We automate the task and then we unintentionally automate the trust associated with it," he said. "The faster the system decides, the less a single gate will catch."
The risk runs in both directions. An agent can exceed the permissions or intent of the organisation deploying it, but it can also become a target itself.
Researchers have already demonstrated how hidden instructions can manipulate AI agents involved in payment processes. In another simulated attack, a compromised inbox's own AI assistant helped an attacker construct a US$247,500 CEO impersonation fraud.
The common problem is trust. An agent can act quickly on information that looks authoritative without necessarily understanding why a control exists, whether a source has been manipulated or when persistence should become escalation.
An 84-day notification gap is a vendor risk
The agent gained unauthorised access on 18 June. OpenAI discovered the activity in August during a review of its models, then notified the Australian Government on 10 September, 84 days after the incident, according to SmartCompany.
The notification reportedly went to a Services Australia email inbox, and Services Australia reported the incident to the Australian Signals Directorate (ASD) on 15 September.
Albanese has criticised both the delay and the way the Government was notified, though OpenAI hasn't classified the activity as a formal security breach.
So what does this all mean for businesses? For starters, it raises an uncomfortable contractual question: if a software provider's AI agent gained unintended access to your ERP, payroll environment or vendor master file, what exactly would require the provider to tell you?
Many incident clauses focus on personal information, credential theft or conventional unauthorised access. Agentic systems create greyer scenarios: the software might operate with legitimate credentials but take an unintended action, retrieve information outside the expected scope or interact with another system in a way nobody anticipated.
Whether the provider calls that a "breach" matters less to the affected business than whether it finds out quickly enough to respond.
Australia has already seen how third-party incidents can travel beyond the organisation where they start. The MediSecure ransomware attack exposed the risks attached to providers holding sensitive information, while data stolen in the Medibank breach was subsequently linked to more than 11,000 other cyber incidents.
The technology changes. The dependency problem doesn't.
Build controls that hold regardless of who's asking
The Medicare portal relied partly on controls that an automated requester kept trying to navigate around. Payment processes can't assume that a requester, human or automated, will stop at the first barrier.
Four controls are worth testing now:
- Scope agent permissions narrowly. An agent that prepares a payment run shouldn't also be able to change vendor bank details or release the funds.
- Make change a verification trigger. As Eftsure VP of Customer Operations Michelle Cram put it in the same webinar, "Change should always trigger a verification." That applies whether the change originates from a vendor email, an employee or an agent.
- Verify against an independent source. Confirm bank details through a source the requester doesn't control. That separation remains important when a vendor's email account has been compromised and when an agent itself has been fed manipulated information.
- Consider AI incidents in vendor contracts. Define the behaviour that requires notification, set a timeframe and nominate an escalation contact rather than relying on a shared inbox. Organisations should also know how and where to report cybercrime in Australia before an incident occurs.
The Medicare portal held relatively low-risk statistics and an AI agent ostensibly still crossed a boundary to reach them. A payment workflow holds something considerably more attractive: the ability to move money.
As organisations give agents more authority to act, the important question isn't only whether the agent can complete a task, it's what the agent is allowed to do when the answer is "no."
These are big questions, in a landscape that has very few blueprints. That's why we're holding discussions to explore topics like these at our On The Defense Summit. On 19 November in Sydney, you'll hear from specialists in banking, ERP systems, law enforcement, ethical hacking, and more.
Be sure to register and secure your spot now.
