OpenAI apologises for Australian government website hack, but is an apology enough?

On 6 October, OpenAI chief strategy officer Jason Kwon flew to Sydney to apologise in person before Parliament’s Joint Select Committee on Artificial Intelligence. The company’s models had accessed Australian government services beyond authorised boundaries in June. Months later, Kwon was answering for both their actions and how OpenAI had handled the response.

The first case involved a research task about government spending on medicines. On 18 June, an experimental, internal-only OpenAI model gained non-public access to the Medicare statistics portal. OpenAI says it ran commands, retrieved internal files, credentials and aggregate statistics, and wrote files. The incident became public on 24 September. OpenAI’s review found no evidence that individual medical records were accessed.

Another June research task involved wildfire statistics. This time, a model used crafted queries against NSW National Parks and Wildlife Service’s Fire History mapping service to infer database metadata, information about the database that wasn’t intended for public exposure. OpenAI detailed the activity in its 4 October update, saying its reviewed results showed no personal-information retrieval.

Malicious intent hasn’t been established in either case. But both started with legitimate research tasks and led to activity that was discovered months later. If your business is giving agents more responsibility, that raises a question worth settling early: what stops an unauthorised action, and who will notice?

The Apology Needs to Be Backed by Controls

OpenAI acknowledged that it should have shared preliminary findings sooner instead of waiting to complete its investigations. It says it has strengthened network restrictions and monitoring, blocked live internet access in these research environments and paused tool-use training and evaluation for its most capable models pending additional safeguards.

Those changes go to the heart of the problem: what a model can reach, what activity is visible and when someone steps in. We believe that is where confidence has to be rebuilt. A team needs more than an assurance that its agent will follow instructions; it needs limits that hold when the agent takes an unexpected path.

Legitimate Intent Does Not Establish Permission

Neither the agent’s operator nor the service owner can assume the other has protection covered. The operator needs to limit the tool’s actions, while the service owner needs to enforce access boundaries and monitor unexpected queries. Publishing statistics doesn’t grant permission to probe the systems behind them.

The Australian Signals Directorate’s (ASD) guidance on agentic AI harnesses explains how those limits work. A harness connects the model to data, tools, memory and workflows, enforcing permissions, executing actions and recording activity. Reading a customer record and changing it carry different consequences. The permissions and approvals around each action need to reflect that difference, with limits enforced outside the model.

A model upgrade can leave excessive permissions in integrations, service accounts and workflows unchanged. ASD identifies the harness as the more enduring investment, so reviews need to cover those permissions alongside connectors, memory stores, execution environments and update paths.

Prompt injection adds another reason for those external limits. Instructions embedded in a document or website can redirect an agent with sensitive access, and ASD warns that model-level safeguards alone cannot reliably resolve the risk. That hasn’t been established as the cause of the government incidents, but it illustrates why protection must extend beyond the model.

Seven Questions Turn Accountability into Practice

These principles become useful when the people deploying an agent can explain what it can reach, what it can change and who will respond if something goes wrong. A readiness review brings that together through seven questions:

1. What task does each agent perform, and who owns the outcome?

2. Which identities, data, tools and systems can it access?

3. Are its permissions limited to the approved task?

4. Which actions require human approval?

5. Do logs show what it accessed, requested and executed?

6. Who monitors alerts and supplier notifications, investigates activity and escalates incidents?

7. Can access be revoked and the agent contained quickly?

A shared agent inventory records these answers. Public-facing services also need verified access protections and monitoring, with retained logs of actions, approvals, errors and overrides so investigators can reconstruct events months later.

OpenAI’s reporting timelines show why the handover to people matters too. It identified the Medicare activity in mid-August and notified Services Australia on 10 September; the agency notified ASD five days later. ABC reported that the contacted inbox had moved from daily to 24/7 monitoring. For NSW, OpenAI says it discovered the activity on 29 September and contacted the government within 48 hours. That was faster notification, but still came after months of delayed discovery.

A notice only starts a response when someone assesses it, preserves evidence and involves people authorised to act. The national notification standards described in ABC’s report were proposals, rather than established obligations. Teams can agree responsibilities and test that handover now.

Greater Autonomy Needs Clearer Accountability

At Secure ISS, we approach this as a security provider using AI in offensive and defensive work. These tools can help a security team do more, but giving them a task shouldn’t leave their authority open to interpretation. Offensive work needs approved targets, authorised methods and clear stopping conditions. A defensive agent allowed to investigate a threat shouldn’t automatically be able to change production systems or user accounts.

People remain accountable for how the tools are used; suppliers should be prepared to support investigation and response when something goes wrong.

Accountability also means looking beyond the agents an organisation deploys to the systems other agents can reach. Dustin Kearney, Security Operations Manager at Secure ISS, highlights why reducing that exposure matters.

Through Lumara, our Australian SOC provides 24/7 threat detection and response, visibility across existing security tools and reporting that supports investigation. That helps teams understand unexpected activity and coordinate a response, alongside the harness controls and service-level protections that limit access in the first place.

Kwon came to Sydney to acknowledge where OpenAI fell short. What matters now is whether its changes hold when a model takes another unexpected path. For a business giving agents more responsibility, confidence comes from knowing who will notice, who can intervene and what evidence they’ll have to work with.

Let’s talk about strengthening visibility, investigation and response when an AI agent goes beyond its brief.