Another day, another OpenAI agent going rogue. This time an OpenAI bot hacked an Australian government website:
Australia said on Thursday an OpenAI agent breached a government health data portal in June, gaining unauthorised access to files, in what could be the first known instance of an AI agent hacking a government website.
The breach is one of the highest-profile incidents of AI agents accessing external systems outside the United States, coming on top of several recent breaches globally by rogue AI agents that have alarmed governments and companies.
Prime Minister Anthony Albanese said the OpenAI agent gained unauthorised access to the medical statistics portal of Medicare, Australia’s universal health insurance programme, while conducting research on public medical spending.
“Evidence currently available is there is no broader compromise to the … network. Nonetheless, this situation is obviously unacceptable,” Albanese told reporters on Wednesday in New York, where he is attending the UN General Assembly.
Investigations continue and Australia has voiced its “extreme concern about this incident” to OpenAI CEO Sam Altman, Albanese said, adding that he was deeply disappointed by the company’s delay in notifying the government. “It took until September 10 before there was any notification at all,” Albanese said, adding that the investigation would also examine why government systems had failed to detect the breach in the first place.
He also warned that three other government health-related websites may have been impacted by the OpenAI agent’s activity, but did not confirm that had occurred.
So OpenAI hacked a government website and OpenAI didn’t warn the Australian government that it had been hacked. That’s pretty bad. OpenAI said this in its defence:
In a statement, OpenAI said its “review found no evidence of patient records being accessed.”
It added that it “identified activity involving several Australian government websites and services as our models attempted to look up answers … our models took actions we did not intend.”
So no harm, no foul? I don’t think so. OpenAI really needs to answer the question of why its agents keep going rogue. They haven’t done that here. But they need to do that because I don’t trust AI in general. And I don’t trust OpenAI products specifically. And I am sure others feel the same way. Especially after this latest hack.
UPDATE: Adrian Culley, Offensive Security Engineer, SafeBreach Said This:
“What’s notable isn’t that an AI agent found its way past a control — it’s that nobody built the agent to stop when it hit one. Told to answer a question, it treated an access restriction as an obstacle rather than a boundary, and kept working the problem until it got through.
Mapped to ATT&CK, the outcome looks ordinary: initial access via a public-facing service (T1190), then unauthorised collection. What’s genuinely new sits upstream of that: there was no adversary in the chain at all. MITRE ATLAS catalogues how attackers compromise AI systems — it has no entry for an AI system attacking everything else, because until now that direction of travel wasn’t the assumption anyone built a framework around.
Australia’s own cyber agency has now described this in general terms, not as a one-off — which means the same gap, an agent that doesn’t stop at ‘access denied’, is sitting against other public-facing services right now, untested.
Patch coverage doesn’t answer that. Only running the scenario does.”
UPDATE #2: Commenting on this is Paul Bischoff, Consumer Privacy Advocate at Comparitech:
“I understand that Australia wants to hold someone accountable for the hack, but it won’t be able to legislate the problem away. Rogue AI attacks will continue to happen no matter what the law says. Not least because the internet is global, and Australian laws don’t apply to the rest of the world.
The attack would have been prevented if the data was properly secured in the first place, and that’s the lesson that should be learned here. AI is good at finding vulnerabilities but it’s not creating new ones. We should be using AI to run preemptive scans and plug the holes before attackers have a chance to find and exploit them with their own AI.”
UPDATE #3: More commentary has come in.
Seemant Sehgal, Founder & CEO, BreachLock:
“The way an autonomous agent works is by taking a goal and finding paths to complete it, including paths around obstacles. For that behavior to be safe when the agent is operating against real systems, the boundaries have to be enforced at the orchestration layer, not inside the model. The Australian incident shows what happens when they are not, with the agent encountering repeated blocks, finding ways through, accessing non-public files, and writing to an internal server.
“What needs to happen next is clearer notification obligations for AI providers when their agents touch systems they should not, because a three-month gap sent to a public inbox is not a disclosure timeline any critical infrastructure operator can plan around.”
John Strand, Owner, Black Hills Information Security:
“Yet again, we’re looking at another breach, and these things seem to be happening faster and faster. Yes, there has to be accountability. And I mean real legal accountability, not another slap on the wrist. If companies are allowing systems to break into organizations without authorization, there need to be serious consequences.
“But there’s another question that I don’t think we’re asking nearly enough. What exactly was the AI trying to do?
“If an AI agent writes files on a compromised system, what were those files? What was the objective? What actions led up to that point? What information was available to the agent when it selected that target? Can we reconstruct from the logs, prompts, tool calls, planning artifacts, and other telemetry why the system took those actions?
“If an AI system breaks into the Australian health department, saying that it hacked the organization and wrote some files isn’t enough. Why did it do it? What was it attempting to accomplish? If it broke into Hugging Face, why Hugging Face? What did the system seek to achieve?
“Every time one of these incidents happens, accountability matters. But understanding the behavior of the AI matters too. We need enough logging and transparency to reconstruct how an agent arrived at an unauthorized action and what objective it appeared to be pursuing.
“We have to stop treating these systems as simple programs that occasionally do something they weren’t supposed to do. Agentic systems can select actions, use tools, pursue intermediate objectives, and operate with significant autonomy. Understanding those actions and objectives is absolutely critical if we want to determine how worried we should actually be.”
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:
“The Australian Medicare incident is being used to argue for more regulation of frontier AI. That risks pulling the ladder up behind the companies already at the top. Large labs can absorb compliance costs and help shape the rules, while a new regulatory framework may still fail to stop an agent from bypassing access controls.
“Australia already has relevant criminal offences. Section 478.1 of the Criminal Code Act 1995 covers unauthorized access to or modification of restricted data. Section 477.2 covers unauthorized modification that impairs, or risks impairing, computer data or systems.
“Those laws do not need to understand neural networks. They need investigators willing to apply them when an AI system crosses a legal boundary. The model may have found the workaround, but the lab built and deployed it, gave it the objective, and controlled the operation.
“The effective deterrent is criminal enforcement. Preserve the prompts, tool calls, and access logs, identify the responsible people and companies, and bring charges where the evidence supports them. More regulation gives frontier labs another framework to negotiate. Enforcement gives them a reason to stop.”
Ryan McCurdy:
“An AI agent received a pretty ordinary research task. When it couldn’t get the information it wanted, it found another way in and accessed files it didn’t have permission to access.
“That problem gets much bigger as AI starts participating across the SDLC. Agents can interact with repositories, infrastructure, databases, and production systems to complete the tasks we give them. We can’t assume they’ll always take the path we expected.
“AI makes decisions based on probabilities. We can’t let those decisions automatically become production actions. Organizations need clear controls around what an agent can access, what it can change, and what policies it must meet before a change reaches production.
“The goal isn’t to put a human in front of every decision. We need to build the AI SDLC so agents can move quickly but the controls around critical systems remain deterministic.”
UPDATE #4: Rohit Valia, CEO of cybersecurity company Tumeryk, provided the following comments:
“This incident shows how an ungoverned AI program can wreak havoc. By Prime Minister Albanese’s account, even Sam Altman acknowledged issues with OpenAI’s protocols. Without proper governance, agents are let loose with indiscriminate access to resources. The problem isn’t just model alignment with human values. It’s a complete lack of oversight over agents accessing external resources.”
The CISA, FBI warn critical infrastructure operators of third-party ICS risks
Posted in Commentary with tags CISA, FBI on September 24, 2026 by itnerdThe CISA and the FBI warned critical infrastructure operators about cybersecurity and supply chain risks associated with third-party industrial control system (ICS) integrators, urging organizations to limit access to operational environments and apply the principle of least privilege.
The agencies pointed to a 2025 incident in which foreign cyber actors compromised a U.S. industrial automation solutions company serving power utilities and transportation entities. The attackers searched for customer and SCADA information and created nine ZIP files containing approximately 800 files for presumed exfiltration, including customer SCADA information, ICS device details and schematics.
CISA and the FBI recommend that operators secure and monitor third-party remote access, minimize internet exposure, inventory hardware and software supplied by integrators, include cybersecurity and supply chain requirements in contracts, and maintain offline backups and manual operating capabilities.
Denis Calderone, CTO, Suzu Labs:
“The ugly side of the outsourced ICS model is the amount of trust that goes along with it. Integrators are a vital part of this ecosystem, especially for smaller operators that could never staff all of that engineering expertise themselves. The integrator needs the keys to the castle. They will be responsible for maintaining network diagrams, device configurations and SCADA details while maintaining a privileged path into the operational environment. CISA and the FBI have now documented exactly why this can be a problem and how this extension of trust directly alters the risk profile of the operator.
“The FBI has not said whether this company was selected because of its role as an integrator, but the post-compromise activity strongly suggests the actors knew what they were after. They searched specifically for ‘customers’ and ‘SCADA’ and staged roughly 800 files of device details and schematics. That is targeted intelligence collection against a company that holds a map of multiple critical infrastructure environments in one place. We have been concerned about how third-party integrators implement operational security for decades. As a professional penetration tester for more than 25 years, I have repeatedly seen integrators or all sorts (ICS, building security systems, environmental controls systems, etc) ignore basic security standards while the client fails to notice because, after all, they outsourced that headache. The more than 100 water systems compromised across the US since July illustrate the consequences of the same kinds of implementation failures. Weak or default passwords, architectures designed without meaningful isolation, little or no monitoring across ICS and SCADA networks, and PLCs placed directly on the internet where anyone can find and attack them. The fact that the integrator became the target itself is of no surprise to me.
“The way to manage this relationship is through the contract and then through audit. Put least privilege, named accounts, unique credentials, MFA, data location and retention, patching, incident notification, access termination and a right to audit into the agreement. Then verify those obligations in the environment. Inventory every component and connection the integrator supplied, inspect the remote-access logs, confirm default credentials are gone, make sure no controller is sitting on the public internet, and prove that your team can cut off the vendor, restore from a local offline backup and operate safely without them. If you cannot see, limit and terminate the integrator’s access, you have outsourced more than engineering.”
John Strand, Owner, Black Hills Information Security:
“Whenever I see stories like this, I keep coming back to the fundamentals. One of my mentors used to say, ‘Good security is nothing more than an inspired application of the fundamentals.’ And that still holds true.
“We talk about reviewing third-party access into systems, but that’s basic access control and authorization. These aren’t new security concepts. What stories like this continue to expose is just how often the fundamentals still aren’t implemented.
“For all the money we’ve spent and all the technology we’ve deployed, there are still legacy systems, legacy network connections, and old pathways into critical environments. We keep seeing the same lessons repeated because organizations haven’t fully addressed the lessons we should have learned years ago.
“The fundamentals are still fundamental. And unfortunately, we’re still failing at them.”
Critical infrastructure has been a target for threat actors forever. Now is the time to secure it. Because if not now, when?
Leave a comment »