Prime Minister Anthony Albanese has revealed that an AI agent gained unauthorised access to an Australian Medicare data portal earlier this year. There is still a fair amount we do not know about what happened. There is already enough to make me think about the old server someone has forgotten to turn off.
I will come back to that server.
ABC News reports that an OpenAI agent accessed public and non-public files in the Medicare statistics reporting service portal, administered by Services Australia, while researching public medical spending. Albanese said there was no evidence that individual personal information had been accessed.
Nine's coverage places the incident in June. It also reports that the available evidence did not indicate a broader compromise of the Services Australia network. A forensic investigation and a task force are examining the incident. ABC reports that the Australian Signals Directorate is assisting the investigation. I would read ASD's involvement as a sign that the incident is being taken seriously, although it does not establish how much information was accessed or what damage was done.
As of 24 September 2026, the public reporting does not give us a complete technical account. We do not know the precise weakness used, the affected components within the portal, how long access lasted or its full extent. There is no confirmed public account establishing that personal information was taken.
We also do not have a complete account of who operated the agent or what instructions it received. The reported research task does not settle whether the access was malicious, opportunistic, experimental or something else.
I would be careful about turning any of that into a claim that Medicare patient records were stolen. That has not yet been established.
What interests me here is the ability of software to investigate a system and keep making decisions about what to try next. We have spent years dealing with automated attacks. Increasingly, the investigation between attempts can be automated too.
The Software Can Do More Than Answer
If you ask a basic chatbot how to perform a task, it gives you an answer. A user still has to do something with the results of that task output.
An agent can have tools that let it carry out the work. Depending on what it has been given access to, it might open a website, use an API, inspect files, sign in to a service or write and run code. It can look at the result and decide what to do next.
Suppose a page does not behave as expected. The agent may inspect the response, change its approach and try again. A person does not necessarily need to sit beside it supplying the next instruction.
ASD's ACSC describes the software connecting the model to those tools in its agentic AI harnesses guidance. The harness also provides somewhere to enforce permissions and control which actions can be carried out.
Those permissions matter. An agent with access to a folder of demonstration files has a different opportunity to cause damage from one holding working credentials for the business's live systems.
I would want to know which of those arrangements I was approving before connecting anything.
We Have Already Seen This With a Gym Booking
In August, ABC News reported on an Australian AI assistant asked to book a gym class. It found a way to make bookings further ahead than the system was supposed to allow.
The user then asked whether it could move him up a waitlist. While testing what it could do, the agent removed another customer from the list. He had not asked it to cancel that person's reservation and asked it to undo the change.
It is easy to imagine someone asking an assistant to sort out a booking while they get on with something else. It is rather less comfortable to discover that the assistant has been experimenting with other customers' reservations along the way.
I covered the website-security implications of the gym incident earlier. The booking service needed to enforce what that account was allowed to do, regardless of whether a person or an agent was using it.
That case does not tell us how the Medicare access happened. It does show why an apparently ordinary task needs boundaries when software can choose its own methods.
Someone Can Also Give It a Deliberately Harmful Job
In November 2025, Anthropic described an attack campaign in which attackers combined Claude Code with their own framework to target roughly 30 organisations. The company reported successful access in a small number of cases.
According to Anthropic, the system investigated targets, tested vulnerabilities, developed exploit code, gathered credentials and extracted data. People selected the targets and intervened at important points. The software also made mistakes, including inventing credentials and treating public information as if it were secret.
That is the provider's account of one campaign. It gives us evidence of real misuse, along with some useful limits on claims about completely autonomous attacks.
An agent can fail. It can misunderstand a response or confidently report something that did not happen. An attacker may still find it useful if it does enough of the surrounding work to make the next attempt cheaper.
A Failed Attempt May Just Be the Next Starting Point
A conventional vulnerability scanner generally works through a defined set of checks. An agent can potentially use what it finds to decide which check or tool to try next.
Imagine a login page that refuses access. There may be a related API worth investigating. If the main application is well maintained, there may be an old copy on a forgotten subdomain. A failed exploit may provide information that leads to a revised attempt. Credentials found in one place may work somewhere else.
These are examples of how an investigation could develop. We do not know whether any of them occurred in the Medicare incident.
Parts of that process resemble the work of a human penetration tester. Find something, examine it, try an approach and reconsider when it fails. An authorised tester has an agreed scope. An attacker will keep looking wherever the available access takes them, potentially into connected services or attempts to interfere with logs.
Automation has been part of this work for a long time. The developing capability is software doing more of the interpretation and choosing between steps. It can continue while the person who started it is doing something else.
There are still costs, rate limits and security controls in its way. But I would not want a business's security to depend on the attacker getting bored.
Back to the Forgotten Server
A business replaces its website. The new one goes live, everyone checks that the enquiries arrive, and the project is finished.
The old installation is still running on a subdomain. It has an administration login, a few plugins nobody updates and perhaps a connection to another service. The person who built it has moved on. The current supplier looks after the new site.
Who is looking after the old one?
The same question applies to a remote access service enabled for a former contractor, an unused API or a server that was meant to be retired after a migration. Add a reused password or a poorly protected email account and there may be a way further into the business.
Small businesses were already exposed to mass scanning. Being small has never stopped software finding an open service. Agentic tools could make it economical to spend more time investigating what turns up, across thousands of organisations.
An attacker does not have to know your business exists before starting. Your forgotten installation can give the software a reason to take a closer look.
That is where the economics change. Work that might not justify hours of someone's attention can become worth attempting when much of it runs without them.
What Else Can That Account Reach?
I would ask this even if AI agents did not exist.
If somebody gets into the website, what can they access from there? Does a credential stored on the server work on another system? Can the same administrator account delete the backups? Does a supplier still have access to services they no longer maintain?
Least privilege means keeping access to what the job actually requires. Separate credentials and restricted administrator accounts help. So does separating networks and limiting connections between systems that have no reason to trust one another.
MFA protects sign-ins, but application identities, API keys and existing sessions need their own review. Useful audit logs should tell you what was accessed and changed. Someone needs to look at them, and the account being monitored should not be able to quietly erase the record.
For businesses adopting agents themselves, ASD's guidance recommends least privilege, monitoring and human oversight around the tools and connected systems. My article on agent permissions goes into that work in more detail.
Before allowing a sensitive action, give the person approving it enough information to understand the consequence. Then make sure the connected service enforces its own limits. Asking the agent to be careful is a fairly thin control on its own.
Somebody Has to Keep Looking After It
A firewall configured when a website launches does not settle its security for the next five years. Software changes. Staff leave. Suppliers add integrations. An account created for a quick test becomes a permanent fixture because nobody remembers why it is there.
I would want a clear arrangement for monitoring, investigating problems, applying fixes and checking the result. That work continues for as long as the system remains in use.
Patching is part of it. So is checking whether somebody used a weakness before the patch was installed. The Mathspace breach is a useful example of why those are separate questions.
Periodically look at the business from outside its network. Establish which domains, servers and management interfaces are reachable, who owns them and whether they are still needed. Remove unused accounts and services. Review authentication and email settings after changes, rather than assuming the original configuration still describes how people work.
Monitoring needs an owner as well. A failed-login alert sent to an unattended mailbox achieves very little. Agree who receives it, what they investigate and when they call for help. Include unusual successful sign-ins, permission changes and unexpectedly exposed files in that review.
A small-business owner should not have to watch logs all evening. They should know who will act when something needs attention.
Start With Work You Can Actually Finish
You do not need an enterprise security department to improve this situation.
I would begin with email and administrator accounts. Check who has access, remove what is no longer needed and use strong MFA. Where supported, security keys or passkeys can improve protection against phishing. Plan recovery at the same time. Solway Web Consulting provides MFA implementation support for that work.
Then review the website and server. Apply operating system and application updates, remove abandoned plugins and restrict exposed administration services. Check the firewall rules against what the business actually needs. An unnecessary service can often be retired, which also removes its continuing maintenance job.
For email, check mailbox permissions and forwarding rules as well as SPF, DKIM and DMARC. Introduce DMARC enforcement after identifying legitimate senders so that the change does not disrupt business mail. My guide to those email controls explains what each does. They serve a different purpose from protecting the mailbox login.
I would also ask to see a backup restored. Keep isolated or immutable copies with separately protected access, and verify that they contain what the business would need to recover. A notification saying the backup completed is useful. Recovering the files is better evidence.
Put regular website and server vulnerability reviews in the maintenance arrangement, particularly after migrations or new integrations. A small-business cybersecurity review in Sydney should leave the owner with specific work to do, in a sensible order, and somebody responsible for doing it.
A Household Can Have the Same Problem
High-net-worth individuals and families can have personal email, domains, cloud storage, financial and identity accounts, home networks and devices managed by several different people. Assistants and advisers may have access too, along with the companies maintaining particular systems.
A personal mailbox may receive recovery messages for several important accounts. A shared folder may contain financial documents left there for an adviser years ago. A device installed at a second property may still allow remote access for a supplier nobody uses now.
I would map those connections before deciding what needs protecting. Check who can access what, remove permissions that have outlived their purpose and separate household and business administration where practical. My guide to cybersecurity for high-net-worth individuals covers the wider environment.
An attacker only needs one of those overlooked connections to be useful. The well-maintained systems still matter, but so does the one everyone has forgotten.
Find Out What Is Still Running
The Medicare investigation has more to establish. We should let the evidence determine what was accessed and avoid assuming patient information was stolen.
There is plenty of useful work a business can do in the meantime. Find the old installations. Review the accounts. Check what each system can reach and whether anyone would notice unexpected access. Keep the remaining software maintained and test that recovery works.
Increasingly, attackers can give their agents the job of finding those weaknesses. I would rather the business found them first.
Solway Web Consulting helps Sydney small businesses, professionals and private clients with cybersecurity audits, website and server reviews, vulnerability and attack-surface assessments, and infrastructure hardening. That includes email security and SPF, DKIM and DMARC configuration, MFA implementation and personal cybersecurity consulting.
If an old server or account came to mind while reading this, that is a useful place to start the conversation. The work should fit the systems you have and the risks they present, without adding enterprise products you do not need.
Discuss a cybersecurity review
Tags: security, small-business, private-client, australia, sydney