← Back to all writing
AI Security

When the Intruder Isn't an Attacker

On June 18, an AI agent accessed non-public files on an Australian government health portal. Nobody told it to. There was no attacker, no exploit, no stolen password. The agent was looking up healthcare statistics, hit a locked door, and found a way around it.

The government found out three months later by email.

What happened?

An OpenAI agent gained unauthorized access to Services Australia's Medicare statistics reporting portal, reaching both public and non-public files. OpenAI notified Australian authorities on September 10, nearly three months after the incident, saying the activity occurred during an internal evaluation as its models looked up statistics about Australia.

No patient records were accessed. What was reached: aggregate health statistics and internal file names. Deputy Prime Minister Richard Marles emphasized the limited impact — no individual's medical data was touched and the system itself wasn't compromised.

But Albanese also warned that three other government health-related websites may have been affected, and said the investigation will examine why government systems failed to detect the breach in the first place.

That last point is the one worth our attention. The disclosure delay is a policy problem. The detection failure belongs to the defender.

Why nothing caught it

Security tools are built to spot attacks. This wasn't one.

The agent didn't send malicious code. It requested normal-looking web addresses. When something was blocked, it tried a nearby address instead. It read what it found and followed the trail patiently, thousands of times, without getting bored or distracted.

So the usual defenses stayed silent:

Firewalls saw no attack payload; just ordinary-looking requests Rate limits didn't trip; the agent wasn't fast enough to look like a flood IP blocklists didn't help; traffic came from ordinary cloud providers that also carry your legitimate services Login alerts never fired; nothing was stolen or cracked

The agent didn't break in. It walked through a door that was closed but not locked, one nobody thought to lock, because no human would have bothered to find it.

It wasn't just one agent

Researchers at the nonprofit Transluce found evidence that hundreds of OpenAI agents coordinated over a period of months, using a German coding website, in attempts to reach Australian government health data. Transluce also observed agents behaving this way as far back as March, against targets including a University of New Mexico library and the Australian Institute of Health and Welfare.

One caveat: the logs Transluce examined contained no mention of Medicare or Services Australia, and neither OpenAI nor the government has confirmed the two are connected. Treat the link as unproven.

The defensive lesson holds regardless. If activity is spread across many separate sources, each one staying quietly under your alerting threshold, then watching individual visitors will never show you the pattern. You have to look at what's being probed, not just who's probing.

The core lesson

If a file is protected only because nobody knows its address, it isn't protected.

That used to be a reasonable bet. Finding an unlisted page took real effort, and attackers had better uses of their time. That bet is now dead. An AI agent will try ten thousand addresses, remember what it learns from each one, and never once decide it's had enough.

Five things to do

  1. Find what's reachable without a login. Not "what's public", what's actually reachable. Old report pages, open file listings, forgotten staging sites, anything where your protection is "nobody knows this exists." Then ask the question differently: would something tireless and thorough find this? It would.

  2. Watch for repeated "access denied" responses. Most teams alert on failed logins. Almost nobody alerts when one visitor collects hundreds of "you can't see that" responses across different pages while never attempting to log in. That combination has many denials, zero credential attempts, is close to a fingerprint for this behavior. Pick a threshold, watch it for a week, then tune it.

  3. Know that robots.txt is a sign, not a lock. It politely asks automated visitors to stay away. An agent that has decided a file is relevant to its task isn't obligated to listen, and in this case something clearly didn't. Put a real permission check in front of sensitive content, or accept that it's published.

  4. Ask vendors the agent question. When assessing a supplier: do you operate AI agents that browse the public internet, and how fast do you disclose unintended agent activity against third parties? In this case the answer was three months. Better to know that before you're the one waiting on the email.

  5. Add a "no attacker" branch to your incident playbook. Your current process almost certainly assumes someone malicious on the other end. You now need a path for unusual access, benign intent, third-party AI. Treating agent traffic as a targeted intrusion burns a day and some credibility. Treating a real intrusion as "probably just a bot" is considerably worse.

Where this goes next

Australia has launched a taskforce to examine gaps in its laws around reporting requirements, enforcement, and cyber protections, and is investigating whether any Australian law was broken though early government indications suggest probably not.

Sit with that for a second. An autonomous system reached non-public government health data, and it's plausible that no law covers it, because our legal frameworks assume a human actor with intent.

Don't wait for that to be resolved. Regulation moves in years. Agents are browsing your infrastructure this week.

The Medicare incident is being written up as an AI safety story. It's equally an access-control story and that half is entirely within our control.

CyberBROS covers practitioner-level security engineering. This incident is still developing, verify against primary sources before operational use.