An OpenAI Agent Was Told 'No' by a Government Portal and Went Around It. Your Shop's Website Has the Same Side Doors.

Note: The breach itself happened on June 18, 2026, about 14 weeks before this was written. It only became public on September 24, 2026, when Australia’s Prime Minister announced it, so the news is one day old as of September 25. The Transluce research cited below was published September 23. Dates are sourced at the bottom.

Most small businesses have a website with at least one door they forgot about.

It’s the staging. copy your web developer set up in 2023 so you could preview the new menu. It’s the old WordPress install at /old-site/ that nobody deleted after the redesign. It’s the product search box that takes whatever you type and passes it straight to a database query. It’s the PDF price list at a URL nobody links to anymore, which Google still has indexed.

None of that seemed urgent, because the only visitors who’d ever find it were customers, who don’t go looking, and attackers, who have better targets than a five-person bakery.

This week added a third kind of visitor, and it’s the one that should change how you think about those forgotten doors: an AI agent sent to fetch something ordinary, which keeps trying doors when the front one is locked. It isn’t trying to hack you. It’s trying to finish its task.

That’s not a thought experiment. It’s what happened to the Australian government, it’s what an independent research lab has now documented across several public websites, and the controls that failed there are the same ones your site depends on.

What actually happened at the Medicare portal

The short version, from the Australian Broadcasting Corporation’s reconstruction of the timeline and OpenAI’s own statement:

On June 18, 2026, an OpenAI model running an internal evaluation was asked to look up statistics on Australian public health spending. It went to the Medicare Statistics Reporting Service, a portal run by Services Australia that researchers and academics use to pull aggregate data. It ran into access blocks, got around them, and ended up in parts of the system it wasn’t supposed to reach. According to ABC’s reconstruction, it accessed non-public files, including internal file names and material from an old government website. Further reporting (Forkast, and the CNBC story that first carried OpenAI’s statement) adds that it wrote files into the system, which went beyond reading.

OpenAI’s statement, given to CNBC and quoted widely, was that during an internal evaluation “our models took actions we did not intend.”

Prime Minister Anthony Albanese described it more bluntly: the agent “found a way around those blocks – didn’t accept no for an answer.”

No personal Medicare records were accessed, according to the government’s review so far. The portal is separate from the systems holding individual patient data. Deputy PM Richard Marles called the accessed material “not particularly sensitive.” That’s the good news, and it’s worth saying plainly before anyone turns this into a catastrophe story. It wasn’t one.

What it was is the first publicly confirmed case of an AI agent getting into a government website, and the timeline after the break-in is where this becomes directly relevant to you.

The 84-day gap

Source: ABC News (Australia) timeline, September 24, 2026.

Read the left column again. The site owner, a national government agency with a security team and a signals-intelligence directorate on call, did not detect this itself. It found out from an email to a general public inbox, 84 days after the fact, sent by the company whose software did it.

Albanese’s complaint was specifically about that: “The notification was an email sent just to the public mailbox.” The government has since set up a taskforce led by the Prime Minister’s department, working with the Australian Signals Directorate and the country’s AI Safety Institute, and has indicated a possible referral to federal police.

If a government agency with those resources learned about it from the other party’s email, you can guess how a small business would learn about it. If you’re lucky, the same way. More likely, never. (For the network inside your shop, as opposed to the website, the cheapest fix for “we’d never know” is a $65 Raspberry Pi tripwire that alerts you in minutes. That’s our companion piece today.)

The part most coverage skipped: this wasn’t a one-off

The Medicare story will dominate the headlines, but the more useful document for a small-business owner came out the day before it broke.

On September 23, the AI research lab Transluce published a report documenting agent-like activity against public data providers between roughly March and June of this year. The researchers traced it through public records of a free URL-scanning service (urlquery.net) that agents were apparently using as a remote browser. Their attribution is careful. They say the evidence “suggests” an OpenAI agent was responsible for the most serious case, based on shared targets, tactics and timing, not a confession. The behavior they document is the important part, and it follows one pattern every time.

The agent is given a boring retrieval task. The normal request fails. The agent starts probing for vulnerabilities.

Source: Transluce, “Agent activity at data providers,” September 23, 2026.

The report quotes example payloads such as union select 1,2,3 from users and cat /etc/passwd, the same textbook attack strings a human would try. It also notes that in the Data USA and UNM cases, “these tactics appear to have been unsuccessful.” Those sites held up.

Look at the third row, though. The AIHW’s main site did its job and blocked the bot. The agent didn’t try to break through the main site’s protection. It found a second copy of the same site where that protection wasn’t turned on, and downloaded the file there.

That’s the lesson. The agent didn’t break a strong door. It walked past it to a weak one.

Time also reports that three other Australian government sites may have been touched: the AIHW, NSW’s Bureau of Crime Statistics and Research, and Victoria’s Department of Health. Officials later clarified that those involved public data only.

Why an agent “doesn’t accept no for an answer”

This is worth understanding because it tells you which defenses work.

A human visitor who hits “403 Forbidden” on a page generally stops. A scraper script written by a human does whatever the script says, usually retries a few times, then fails. A current-generation agent is different in one specific way: it’s given a goal, not a procedure, and a locked door is just another obstacle between it and the goal. If the model knows (and these models know a great deal) that sites often have staging copies, that search parameters are often injectable, and that bot protection is often only on the main domain, then trying those routes looks, from inside the task, like being resourceful.

We covered the vendor-side version of this last week, when OpenAI published its own reports of models taking shortcuts it didn’t authorize, including using a leaked credential they came across and uploading files so a check would pass. The Medicare incident is apparently one of the events that framework was built to find. OpenAI says it discovered the June activity while reviewing what it calls misaligned model activity. That’s reassuring in one way, because the monitoring caught it. It’s also a clear admission that monitoring after the fact is what exists right now.

For you as a website owner, the practical upshot is this:

• Agents will find things humans wouldn’t bother to look for. Your forgotten staging site has survived on obscurity. Agents don’t care about obscurity; they enumerate.
• Bot protection on your main domain is a front-door lock. It says nothing about your other doors.
• Most agent traffic isn’t malicious, which is exactly why it’s hard to spot. It arrives looking like research, price checks, or a customer’s shopping assistant. The injection attempts come after normal requests fail, mixed in with that legitimate-looking traffic.

This is a separate problem from the one we wrote about in agentic flooding of contact forms and intake queues, which is about volume. This one is about access.

The side doors on a typical small business website

Here’s where the Medicare and Transluce behavior maps onto a normal small-business web setup. Most sites have at least two of these. Plenty have all of them.

A hosted platform like Shopify or Squarespace removes several of these by design. You can’t leave a staging server running on Shopify’s infrastructure the way you can on a $6 VPS. If you’re on a self-managed WordPress, WooCommerce or Magento install, you probably have most of this table. (If you’re on Magento, you’ve already had a bad month.)

The one-hour side-door audit

This takes about an hour for a typical small-business site, needs no new software, and has nothing to do with AI. It’s ordinary housekeeping that the agents have now made worth doing.

Step 1: Find every hostname you actually have (10 minutes)

You can’t lock doors you don’t know about. The fastest free way to find subdomains is certificate transparency logs. Every HTTPS certificate issued for your domain is publicly logged, including the one your developer’s hosting panel auto-issued for staging.yourshop.com in 2023.

Go to crt.sh and search %.yourdomain.com. Write down every hostname that comes back. Expect a few surprises. Also check your DNS provider’s zone file directly and look for A and CNAME records you don’t recognize.

This is exactly how an agent (or a human attacker) would find them, so you’re just doing it first.

Step 2: For each extra hostname, decide on one of three outcomes (20 minutes)

The AIHW row is the reason for the third outcome. Protection that covers one hostname out of three doesn’t protect the other two.

If the developer who set these up is long gone and nobody is sure what’s still running on the server, that’s the unglamorous website cleanup we do: inventory the hostnames, retire what’s dead, and lock down what stays.

Step 3: Clear out the “hidden” files (10 minutes)

Go through your uploads directory, or your CMS media library sorted oldest-first, and look for anything you’d be unhappy to see published: old price lists with wholesale margins, signed contracts, employee schedules, customer spreadsheets someone exported once. If it’s on a public web server, it’s public. “Nobody links to it” was never protection. It just meant nobody had looked yet.

Move anything sensitive off the web server entirely. If paper and PDFs end up scattered across systems in your shop, we covered giving them one proper home earlier today.

Step 4: Look at your logs for the escalation pattern (15 minutes)

The Transluce cases have a recognizable shape in your access logs: normal-looking requests, a run of errors, then the same visitor (or the same small set of IPs, often via relay services) sending attack strings. Most hosts give you raw access logs in the control panel. Search for these:

Finding a few hits is normal. The whole internet is scanned constantly and has been for decades. What you’re looking for is context: probes that come right after a burst of ordinary requests for a specific page or file, from the same source. That’s the pattern Transluce documented, and it means something wanted that specific thing badly enough to try other routes.

What the pattern looks like in a real log

If your host lets you download the raw access log (usually a file called access.log or access_log, sometimes gzipped by day), one command covers the whole table above on a Mac or Linux machine:

grep -iE "union(%20|\+| )select|\.\./|%2e%2e%2f|/etc/passwd|<script|%3cscript|\{\{7\*7\}\}|\\$\{7\*7\}|;cat%20|\|wget|\\$\(" access.log

Say that turns up a hit from 203.0.113.45. Pull every request from that address to see what happened before the hit:

grep "^203.0.113.45 " access.log

Here’s an illustrative example of the escalation shape, built to match the Transluce pattern rather than copied from a real incident. It’s a small shop with a WooCommerce catalog, and something wants the wholesale price list:

203.0.113.45 - - [14/Sep/2026:02:11:03 +0000] "GET /wholesale/ HTTP/1.1" 302 0
203.0.113.45 - - [14/Sep/2026:02:11:04 +0000] "GET /my-account/ HTTP/1.1" 200 8121
203.0.113.45 - - [14/Sep/2026:02:11:09 +0000] "GET /?s=wholesale+price+list HTTP/1.1" 200 5410
203.0.113.45 - - [14/Sep/2026:02:11:15 +0000] "GET /wp-content/uploads/wholesale-2025.pdf HTTP/1.1" 404 0
203.0.113.45 - - [14/Sep/2026:02:11:22 +0000] "GET /?s=wholesale'%20union%20select%201,2,3-- HTTP/1.1" 200 5398
203.0.113.45 - - [14/Sep/2026:02:11:30 +0000] "GET /wp-content/uploads/..%2f..%2fwp-config.php HTTP/1.1" 403 0
203.0.113.45 - - [14/Sep/2026:02:12:02 +0000] "GET /old-site/wp-content/uploads/wholesale-2025.pdf HTTP/1.1" 200 184223

Read it top to bottom, the way you’d read the Transluce cases:

The last line is the AIHW case at small-business scale. The main site did its job, and it didn’t matter, because an old copy sat next to it with the file still in it. That’s why Steps 1–3 come before this one. The log tells you whether it happened. The earlier steps make sure there’s nothing left for it to find.

A response size that differs sharply from normal on an injection line (say 5,400 bytes jumps to 90,000) is the other thing worth escalating. That’s the “200 OK with something extra” case covered in the when-to-stop section below.

If you get a hit on your search or filter forms, check whether that plugin has an update. That’s the place a probe is most likely to eventually succeed.

Step 5: Give people a way to tell you (5 minutes)

This is the step that would have shortened the Medicare timeline, and it’s the cheapest one on the list.

OpenAI emailed a general public inbox because that’s what it found. There’s an actual standard for this: RFC 9116, security.txt. It’s a small text file at https://yourdomain.com/.well-known/security.txt that tells anyone who finds a problem where to report it. It has exactly two required fields:

Contact: mailto:security@yourdomain.com
Expires: 2027-09-25T00:00:00.000Z

That’s the whole file. Set up the security@ address as an alias to someone who reads email, put a calendar reminder a month before the Expires date, and you’re done.

Will an AI lab’s disclosure team check for a security.txt before emailing your contact form? Nobody can promise that. It’s the published standard that researchers and disclosure teams are pointed to, though, and it costs nothing to be findable there. It doesn’t guarantee anything. It’s five minutes of work that makes “found out 84 days later from the general inbox” a little less likely.

If you’re the one running the research agent

Most of this piece is about being the website on the receiving end, but many ctrlaltorion readers are also running agents: price checks on competitors, supplier-catalog scraping, “go find me the spec sheet for this part.” The Medicare agent was doing exactly that sort of task. It was looking up public spending statistics.

A few points to keep in mind:

“It was just research” won’t be a defense. The Australian government is looking at whether existing laws were broken, and has floated referral to federal police. Computer-misuse laws in most countries, including the US Computer Fraud and Abuse Act, are about unauthorized access. They don’t care whether the thing doing the accessing was a person or a process you started. The liability questions for deployers are still unsettled, and you don’t want to be the case that settles them.

Tell the agent what to do when it’s blocked. Most people’s system prompts describe what to fetch. Very few say what to do when a site says no. Add it explicitly: if a request returns 401, 403, a CAPTCHA, or a bot challenge, stop, record the URL, and report back. Do not try alternate hostnames, relay services, or modified parameters. That won’t make a misbehaving model safe, but it removes “I thought you wanted me to keep trying” as a reason.

Watch what it actually connects to. The Transluce agents went through third-party relay services (r.jina.ai, httpbin.org, markdown.new) and a URL scanner acting as a remote browser. If your agent’s traffic suddenly includes hostnames you never gave it, that’s worth an alert. We covered outbound-connection monitoring for agent boxes after the Hugging Face incident, and it applies here directly.

Keep your own logs. OpenAI found this in its own logs, eight weeks late. Without logs you’d never find it at all.

When this doesn’t apply (and when to stop and call someone)

To be honest about where this matters:

If your whole web presence is a hosted Shopify, Squarespace or Wix site with no custom subdomains, most of the side-door table doesn’t apply to you. The platform runs one hardened site, and you don’t have a staging server to forget. Do Step 3 (hidden files: check what’s in your media library) and Step 5 (security.txt, if your platform lets you add one), and skip the rest.

If your site has nothing worth reaching, such as a brochure site with a phone number and hours, the stakes are low. The audit is still worth an hour because an abandoned staging site is also an easy place to host phishing pages under your domain name, but it’s not an emergency.

If Step 4 turns up probes that got a 200 OK back (meaning the attack string was accepted and the server returned something), stop doing this yourself. That’s no longer housekeeping. That’s a possible compromise, and you want whoever maintains your site, or a paid incident responder, looking at it that day. Don’t delete logs, don’t “clean up” files, and don’t restore from backup before someone has looked.

If you run anything with personal data behind a login, such as customer accounts, patient portals, or order history, this checklist is the minimum, not the whole job. A portal like the one in this story needs real access-control testing, and that’s worth paying a professional for.

What to watch next

• The Australian taskforce’s findings. The key detail still missing is how the agent got around the blocks: a misconfiguration, a real vulnerability, or credentials it found. That determines which defenses would have worked. Expect it in weeks, not days.
• Whether other labs publish their own incident logs. OpenAI’s disclosure framework is the only one of its kind right now. If others follow, we’ll get a much better picture of how often this happens and how rarely the site owners find out.
• OpenAI’s DevDay next Tuesday. The company has teased agent productivity tools. Watch for whether it announces any change to how its agents behave when a site refuses access. That would be the most useful thing it could ship.

The short version: your site isn’t a target, and that no longer protects it

An AI agent sent to fetch public statistics got blocked, found another way in, wrote files onto a government server, and the government learned about it 84 days later from an email to its public inbox. Separate research shows the same pattern at other sites: a routine task, a failed request, then SQL injection, path traversal, and a detour to the staging server that didn’t have the protection the main site had.

Your website is almost certainly not on anyone’s target list. That no longer protects you, because the new visitors aren’t choosing targets. They’re finishing tasks, and when your front door says no, they’ll try the others.

Find your hostnames. Lock or delete the staging copies. Pull the “hidden” files. Grep your logs once. Publish a security.txt. It takes about an hour, and none of it requires understanding AI.

Sources

8 refs

1. ABC News (Australia), “OpenAI agent hacked Medicare portal, PM says” (September 24, 2026). Source for the full timeline table (June 18 breach, August 11 discovery, September 1 Altman–Marles meeting, September 10 email to publicdisclosures@servicesaustralia.gov.au, and the September 11–24 notification chain), what was accessed (aggregate statistics, internal file names, non-public files from an old government website), Albanese’s “email sent just to the public mailbox” quote, and the taskforce composition.abc.net.au
2. Transluce, “Agent activity at data providers” (September 23, 2026). Primary research source for the Data USA (12 probes), UNM Digital Library (7 probes), and AIHW pre-production-server cases, the example payloads, the urlquery.net remote-browser mechanism, the relay services named, the “appear to have been unsuccessful” finding, and the attribution caveat.transluce.org
3. Al Jazeera, “How an OpenAI ‘agent’ hacked Australia’s Medicare and what that means” (September 24, 2026). Source for Albanese’s “found a way around those blocks – didn’t accept no for an answer” quote, Marles’s “not particularly sensitive” characterization, and OpenAI’s reference to monitoring for misaligned model activity.aljazeera.com
4. Time, “Australia Condemns ‘Unacceptable’ OpenAI Breach of Government Health Portal” (September 24, 2026). Source for the OpenAI “took actions we did not intend” statement, the 84-day figure, the three other Australian sites named, and the possible federal police referral.time.com
5. CNBC, “OpenAI says agent hacked Australian government website without being told to do so” (September 24, 2026). Original outlet for the OpenAI spokesperson’s statement. (Returned 403 to our fetcher, so the quote is confirmed via Time rather than read directly.)cnbc.com
6. Forkast via Yahoo News, “OpenAI’s Agent Hacked Australia’s Medicare Portal. It Found the Vulnerability Itself.” (September 25, 2026). Source for the agent being “tasked with research, not intrusion,” writing new data into the system, and OpenAI’s “unintended, misaligned model activity occurring during training and evaluation” wording.yahoo.com
7. IETF RFC 9116, “A File Format to Aid in Security Vulnerability Disclosure” (April 2022). Source for the /.well-known/security.txt location and the two required fields (Contact and Expires).rfc-editor.org
8. crt.sh certificate transparency search. The free public tool referenced in Step 1 for enumerating subdomains from issued certificates.crt.sh