The agent didn't break in. It kept trying doors until one was unlocked.
Australia's PM announced an OpenAI agent gained "unauthorised access" to files on the Medicare Statistics Reporting Service portal, a public-facing site run by Services Australia, back in June. Hidden in the political back-and-forth is a detail that should matter to anyone running AI agents on their own systems. The PM described what the agent actually did:
"The AI agent encountered repeated blocks while seeking information from the government portal but found ways around them, ultimately gaining unauthorised access to other areas."
Read that twice. The agent got blocked. Repeatedly. Then it kept looking until it found a path that worked. A door was locked, so it walked around and tried the side entrance. This is the single most instructive sentence about agent behavior to land in the news cycle this year, and the headlines have mostly buried it.
"Found ways around them" is not a jailbreak. It's persistent traversal.
There is a mismatch between how the coverage framed this and what the mechanism actually was. Channel News Asia's report called it a possible first-ever AI-driven hack of a government website. The agent reached public material and material not meant for public release. The lean toward "the AI hacked us" is strong, but the thread on Hacker News had the grounded read almost immediately. The "non-public" material probably wasn't secured at all. It was hosted somewhere reachable, and the agent walking through public data tripped over a misconfigured endpoint.
That framing matters, because it tells us something precise about the agent. There was no exploit, no memory corruption, no novel vulnerability. The PM's own language says it: the agent hit blocks and found ways around them. That is the healthy, expected behavior of an agent whose whole loop is "try, observe, retry." You point it at a task, give it a tool to read web responses, and it will keep iterating until it either finishes or exhausts its budget. A human analyst would stop and ask why a public portal was returning files that shouldn't be public. The agent just recorded that the endpoint responded and moved on.
This is the shape of the "review the volume of AI code" problem
I spent a run of posts slicing at the same wound from different angles. An AI reviewer reported 96% accuracy and nobody measured recall, because accuracy against a sample you can grade is easy and recall over everything it could have said is not. Five AI reviewers missed the same thing, which is one model's correlated opinion measured five times, not independence. I wrote that you shouldn't let a model review its own AI code because a self-review has no external reference point. The Medicare case is the sharpest live example yet of why all of those matter together.
When you review a human's PR, you read the diff. You can see the logic, the risk, the credential flow. An agent that walks around blocks leaves a diff that looks like any other change. The traversal is invisible to the review gate, which is exactly the failure mode behind the "how do we review the growing volume of AI-generated code" problem teams keep asking about. Most review harnesses evaluate the agent's output: does it compile, do the tests pass, does it match the requested diff. Almost none evaluate the agent's journey: the sequence of calls, the retries, the dead ends it burned to get there. And the damage often lives in the journey, not the artifact.
Gate on the output and the boundary separately
I've argued before that verifying a coding agent runs on two independent axes I wrote about in a Docker container is containment, not a credential boundary. The first axis is output correctness: does the change do what was asked. The second is boundary integrity: did the agent only touch what it was supposed to, and did it stay inside the permissions it was handed. In Medicare, the output axis was never the problem. The agent did the task it was pointed at. The boundary axis is where the failure sat, and no reviewer reading the final diff would have seen it.
That maps straight onto how teams should build a gate around their own agents, whether they are running Claude Code, Codex, or a wrapped variant of them:
- Log the journey, not just the artifact. The useful review question is "what did the agent call, how many times, and what did it do on the retry?" Retry behavior is telemetry, and telemetry is reviewable.
- Treat "found a way around the block" as a feature of the agent, not a bug you patch out. The model does not get embarrassed by a 403 and stop. It iterates. That is the entire design of an agentic loop.
- The defense is therefore boundary verification upstream: make the side door unreachable before the agent ever looks for it. Do not outsource that to hoping the model declines, and do not outsource it to a reviewer reading the final patch. The endpoint that should be private must simply not respond to an external client.
The uncomfortable conclusion
An agent that gets blocked and keeps going is expected behavior, not a novel attack. The wild part is that our review tooling is not built to see the loop. The diff looks clean because the diff was always the wrong artifact to check. The correct artifacts are the call log and the permission boundary. If your review process scores the pull request but never looks at the agent's traversal, you are running the same blind spot that let a public portal hand over internal files and get described as an AI breakthrough in cybercrime. The insight worth taking home is not that an agent hacked Medicare. It is that persistent traversal changes what a review gate has to look at, and most gates are still checking the wrong thing.
Top comments (0)