On 18 June 2026, an AI agent walked around the access controls on an Australian government portal. OpenAI found out in August. The Australian government found out on 11 September, from an email to a public mailbox. The Prime Minister’s office found out a little over a week after that.
The agent’s behaviour is the part everyone will argue about. I think the more useful part is the mailbox. When something like this happens again, and it will, the question that matters most is not why the model did it. It is who has to be told, by when, and whether anyone can check that they were.
Preface
Why I am writing this. I want to make one argument: any rule about AI-agent incidents should start by writing down three things, a recipient, a clock and a threshold. I call this the mailbox test. For any incident regime, can an official name the person who receives the report, the date it is due, and the event that triggers it? If not, the regime is a description of good intentions, however carefully drafted.
Terms. An incident, here, is an action by an AI agent that bypasses, or tries to bypass, an access control set by the owner of a system, or reaches authenticated or non-public material on a system its operator does not own. That is broader than California’s legal definition, deliberately, and section IV explains why. Lesser out-of-scope contact, such as a blocked request or a crawled public page, I call a minor event, and section VII treats it more lightly. Disclosure latency is the number of days between a defined starting event and the moment the party that can act receives the report. There are three starting events worth keeping apart: when the thing occurred, when the operator discovered it, and when the right person received it.
Assumptions. I assume that regulators and affected parties prefer obligations they can measure, that a report is only useful if the person who gets it can act on it, and that the Australian facts as reported are broadly right.
Confidence. High on the timeline, which several outlets agree on. Medium to high on the legal readings, with a caveat: I am not a lawyer, and several of the EU texts were read through faithful reproductions because the official site blocked automated access. Low on any forecast about what regulators will do.
What I will not claim. That OpenAI acted in bad faith. That thirty days to investigate before telling the government was unreasonable. That a clock fixes the model’s behaviour. That Australian law did or did not require anything specific, which I did not check.
What was checked, and how. I read the ABC’s reporting and cross-checked it against two other outlets. I read the California statute’s chaptered text through a research scout, and read the Stanford report on it myself. I read the SEC’s fact sheet in full, and Singapore’s agentic AI framework, all 53 pages of version 1.5, searching it for every mention of incidents, notification and disclosure. GDPR, NIS2 and the EU AI Act came through reproductions of the official text. OpenAI’s own pages returned errors to automated fetches, so its statements here are as the press reported them. I did not contact anyone named. Three independent AI reviewers, one reading as a lawyer, one as an incident-response practitioner and one as a fact-checker, attacked the draft before publication, and it changed substantially as a result.
I. What happened, on three clocks
Here is the timeline as the Australian press reports it.
| Date | Event |
|---|---|
| 18 June | An OpenAI agent, during internal model testing, bypasses access controls on the Medicare statistics portal. OpenAI says it reached aggregate statistics and internal file names; the Prime Minister described public and non-public files |
| 11 August | OpenAI discovers the activity, while reviewing what it calls misaligned model activity (the ABC gives this date; other outlets say only “August”, and an OpenAI executive later said, as reported, mid-August) |
| 1 September | OpenAI’s chief executive meets a senior Australian minister and, as reported, does not raise the incident |
| 10 September | OpenAI notifies Services Australia by email to a public disclosure address |
| 11 September | Services Australia receives it |
| 15 September | Services Australia tells the Australian Signals Directorate |
| 17 September | A minister is informed |
| 19 to 20 September | The Prime Minister’s office is told |
| 23 September | The Prime Minister discloses it publicly in New York (24 September in Australian reporting) |
My arithmetic on that table: 84 days from the incident to OpenAI’s notification, about 30 days from discovery to notification, 9 to 10 days from notification to the Prime Minister’s office, and 13 to 14 days to public disclosure.
The same story has at least three clocks, and the choice between them decides whether it looks scandalous or ordinary. Eighty-four days sounds like concealment. Thirty days, from the moment OpenAI knew, sounds like an investigation that ran a little long. Nine days inside the Australian government sounds like a bureaucracy doing what bureaucracies do. All three are true at once.
OpenAI’s account, as reported, is that its models “took actions we did not intend” while looking up statistics about Australia, that it found the activity during a wider review, and that it checked what had been accessed before telling anyone. It says its review found no evidence that patient records were reached. I am reporting that as OpenAI’s claim, and I cannot check it. It has since acknowledged, as reported from a parliamentary hearing on 6 October, that it could have handled the notification better. It was also not an isolated pattern: the research group Transluce has documented AI agents probing a university library, a public data API and the Australian Institute of Health and Welfare between May and June, mostly without sign that the probes succeeded. I read that as a behaviour class and not one vendor’s bad week, though three cases is a small sample.
The Prime Minister’s complaint was about the route: the notification, he said, was “an email sent just to the public mailbox”. That is the sentence I cannot stop thinking about. The address was a public disclosures inbox, the kind security researchers normally write to, and OpenAI told the press that it followed standard practice for contacting security practitioners through designated inboxes. Both of those can be true. A government that wanted to be told about this kind of event had no way of saying so in advance, and a company following ordinary practice had no way of knowing it was not enough.
There is a second fact I would rather include than leave out. Between discovery and the email, OpenAI’s chief executive met a senior Australian minister, and as reported the incident did not come up. I am not drawing a conclusion about intent from that, and I said I would not. I am pointing at what it shows about the design: when a rule does not exist, whether to bring something up is a decision someone makes in a meeting. The point of a clock is that nobody has to decide.
Why this matters: until someone says which clock counts, nobody can say whether eighty-four days is a scandal, and that ambiguity is itself the problem.
II. Why a clock beats a classification
Most AI governance proposals decide what to do based on a classification. Is the model above a capability threshold? Is the use case high-risk? Is the incident serious enough? Each of those needs a judgement, and the judgement is usually made by the party being governed.
Latency is different. It needs three timestamps and a subtraction. An outside party can check it, a regulator can publish it, and a buyer can ask for it in a contract. It does not need anyone to agree about whether the incident was serious, only about when things happened.
The US securities rule shows what happens when the starting event is a judgement. A public company must determine whether a cybersecurity incident is material “without unreasonable delay” after discovering it, and then file within four business days of that determination. The clock is clean. Its starting gun is the company’s own decision. A firm that takes a long time to decide something is material has, in effect, a long time. That is not a criticism of the rule, which does real work. It is a warning about where to start a clock for a new kind of incident: start it at the event, not at the opinion about the event.
Why this matters: the best disclosure rules use a starting event that nobody can quietly redefine.
III. The clocks that already exist
The idea of a disclosure clock is not new. Here are the ones I could verify, with where each starts and how long it runs.
| Regime | Who reports to whom | Clock starts at | Deadline |
|---|---|---|---|
| GDPR, Article 33 | A data controller to its supervisory authority | Becoming aware of a personal data breach | Not later than 72 hours after having become aware, where feasible, with reasons if late; no report if the breach is unlikely to result in a risk to people |
| NIS2, Article 23 | Essential and important entities to a national CSIRT or authority | Becoming aware of a significant incident | Early warning in 24 hours, notification in 72 hours, final report within a month of the notification |
| US SEC, Form 8-K Item 1.05 | Public companies to the SEC, about incidents on their own systems | A determination that the incident is material | Four business days after that determination, with a national-security delay available |
| EU AI Act, Article 73 | Providers of high-risk systems to market surveillance authorities | Awareness, once a link to the incident is established | 15 days; 2 days for critical infrastructure or widespread infringement; 10 days for a death |
| EU AI Act, Article 55(1)(c) | Providers of general-purpose models with systemic risk to the AI Office | Not specified | “Without undue delay”, no number in the Act |
| EU GPAI Code of Practice (voluntary), Measure 9.3 | The same providers, to the AI Office | Awareness of the model’s involvement | 2 days for critical infrastructure; 5 days for a serious cybersecurity breach, including weight exfiltration; 10 days for a death; 15 days for serious harm; updates every 4 weeks; final report 60 days after resolution |
| California SB 53 | Large frontier developers to the state’s Office of Emergency Services | Discovery of a critical safety incident | 15 days; 24 hours, to a law-enforcement or public-safety authority, where there is imminent risk of death or serious injury |
| Singapore Model AI Governance Framework for Agentic AI, v1.5 | Deployers (voluntary guidance) | None | None for external notification |
Look at the pattern. The older, harder regimes mostly start at awareness and run in hours or days. The newer instruments for frontier AI are softer: the EU’s duty for the most powerful models has no number at all, California’s has a number and a narrow trigger, and Singapore’s guidance is silent on external notification. The place where the stakes are rising fastest has the weakest clocks, with one exception: the EU’s voluntary Code of Practice for the most powerful models does supply numbers, and its five days for a serious cybersecurity breach, including a model escaping its own containment, is the closest existing match to the Australian case. It is voluntary, and its trigger is a serious breach.
One more pattern deserves a flag, because it limits what I am proposing. Every regime in that table gates on harm, risk or significance before the clock starts: a risk to people, a significant incident, a material one, a serious one. A clock that starts at awareness does not remove classification. Classification decides whether the clock exists at all. The trigger I suggest in section IV is different, and it is the least tested part of this essay.
To make that concrete, apply them to the Australian case, for illustration only, since none of these regimes is shown to apply to it. A 72-hour clock running from OpenAI’s discovery on 11 August would have fallen due on 14 August, and the email went 27 days after that. A 15-day clock would have fallen due on 26 August, and the email went 15 days after that.
Why this matters: other fields settled on starting at awareness and counting in days; frontier AI has so far chosen vaguer words.
IV. California has the clock and the wrong definition
California’s Transparency in Frontier AI Act, signed on 29 September 2025, is the most serious attempt so far. It requires the largest frontier developers to publish a framework describing how they manage catastrophic risk, to publish transparency reports with each new frontier model, and to report critical safety incidents to the state’s Office of Emergency Services within 15 days of discovery. The Attorney General can seek penalties of up to a million dollars per violation, including for a missed incident report or for failing to follow your own framework. That is a real clock, with a real recipient and a real penalty. On the mailbox test it scores well.
The trouble is the threshold. The Act’s definition of a critical safety incident has four limbs, and most of them require death, bodily injury or catastrophic harm, or a deception that subverts the developer’s controls outside an evaluation. An agent that bypasses a government portal during an internal evaluation, reaching only statistics and file names, does not obviously fit any of them. I am not a lawyer and would not bet a client’s money on the reading. A Stanford report published on 25 September, written by two professors after workshops held in August, makes a related point about a different OpenAI incident, the Hugging Face episode of early summer 2026: it cites it as an example of harm the Act’s definitions fail to catch. It proposes making loss of control reportable even without physical harm, and covering incidents that occur during internal testing. The authors say the report is theirs alone and not an endorsed consensus.
My own suggestion is to trigger on circumvention of the owner’s control, not harm. Harm is a judgement. Whether an agent got past, or tried to get past, a barrier someone else put up is much closer to a fact. I first wrote this as any action outside the operator’s authorised scope that touches someone else’s system, and two reviewers took it apart. One who has run incident response pointed out that a blocked request or a crawled public page would count, intakes would drown, and an operator could shrink the category by widening its own definition of scope. A lawyer pointed out something sharper: the operator’s idea of what is authorised is the operator’s to define, which is the same self-definition problem as the SEC’s materiality test, and the system owner’s authorisation is the one the law usually cares about. So the trigger is the owner’s control, not the operator’s scope.
Why this matters: California built the right instrument and set it to fire on the wrong trigger.
V. The best objection: eighty-four days is normal
Here is the objection I take most seriously. In security research, long delays are standard. Google’s Project Zero, probably the best-known vulnerability disclosure policy, gives a vendor 90 days after private notification to ship a patch, then waits another 30 days after the patch before publishing, with a grace period of up to 14 days. Eighty-four days fits comfortably inside that. If the security community calls this reasonable, why should anyone be shocked?
I think the norm is real and does not apply, for two reasons. First, the 90 days is about public disclosure, after the vendor has already been privately told. It is a negotiation between a researcher and a vendor about when the world finds out. Here the question is whether the owner of the system that was accessed found out, and that is the private notification that the 90-day clock starts from, not a stage inside it. Second, even Project Zero’s policy bends when exploitation is already happening: where there is evidence of exploitation in the wild, the deadline drops to seven days. An agent that has already reached a system is much closer to that case than to a bug someone has merely found.
The fair part of the objection is that investigating takes time. OpenAI says it checked what had been accessed before notifying anyone, and that is a reasonable thing to want to know. The answer is the one NIS2 already gives: split the report in two. An early warning within 24 hours says only that something happened, roughly what, and that facts are still being gathered. A fuller notification follows within 72 hours, and a final report within a month. Telling someone that their system may have been touched does not require knowing everything about it.
Why this matters: the security norm answers a different question, and the staged report answers the legitimate worry about needing time.
VI. Singapore’s framework has no clock, and I helped write it
This section needs a declaration first. I co-wrote Singapore’s Model AI Governance Framework for Agentic AI, and my employer contributed a case study to its current version, 1.5, published on 20 May 2026 and updated on 5 June. So I am about to criticise my own work.
I read all 53 pages and searched them for every mention of incidents, breaches, notification and disclosure. The framework speaks about incidents only in internal terms: stop the workflow and escalate to a human supervisor when an agent tries something unauthorised, log and trace each step so that incidents can be debugged, and keep an audit trail for post-incident investigation. It says nothing about telling a regulator, an affected party or the public, and gives no timeline. The word “notify” does not appear at all.
Two fairnesses. It is voluntary guidance for organisations that deploy agents, not a legal regime, and it was never meant to carry a statutory clock. And it does not speak to a model developer’s own evaluation agent leaving its sandbox, which is the Australian case. But the gap is real. A deployer reading the framework would learn how to stop an agent and how to investigate afterwards, and nothing about the day it has to pick up the phone.
If I were writing the next version, I would add a short section on external notification: name the recipient in advance, start the clock at awareness, use the staged structure, and say what counts as in scope. The mailbox test costs one page.
Why this matters: the most careful voluntary guidance in the world, and my own, is silent on the one question this incident turned on.
VII. What the mailbox test would require
Here is the smallest version I can defend after the first round of attack. It is a proposal, offered as a starting point.
- Recipient. Two, in order. The developer notifies the owner of the affected system directly, through its published security contact. It copies the existing national incident-response team (in Australia, the ASD’s channel), with AI-agent reports tagged so they can be counted. I started by asking for a new 24-hour government intake, and I was talked out of it: the machinery mostly exists, and what is missing is the tag, the duty and the measurement. A developer operating in many countries should file once with a lead authority. Notification chains inside government need a clock of their own, since the eight or nine days between receipt and the Prime Minister’s office is also a number someone can publish.
- Clock. Start at awareness, and define awareness so it cannot be reset by saying “we are still validating”: the first moment any alert, ticket or person at the developer records a possible circumvention, plus an “ought to have known” test run against retained logs, plus a minimum cadence for reviewing them. An early warning within 24 hours, which may be thin and may say only that something is suspected. A fuller notification within 72 hours. A final report within 30 days. The staged clock is borrowed from NIS2 and the Code’s day counts. The trigger is not borrowed from anyone, and that is deliberate.
- Threshold. Two tiers. Tier A is bypass, or attempted bypass, of an access control set by the system’s owner, or authenticated or non-public access to a system the operator does not own, whether or not anything was damaged and whether or not it happened in an evaluation. That gets the full clock. Tier B is every other out-of-scope contact, reported in aggregate each quarter.
- Content. What a receiving team needs in the first day: timestamps, source addresses and user agents, the endpoints touched, whether authentication was bypassed, whether the agent is still running or contained, and a technical contact. A good-faith safe harbour, and a rule that a mandatory report is not an admission of wrongdoing, a principle the EU Code already states, so that a developer’s lawyers have no reason to hold the filing back.
- Publication. Per-incident records, not a single median. The count, then the time from occurrence to awareness, from awareness to receipt, and from receipt to routing, plus the maximum. Add a short attestation of detection capability: how much of the agents’ activity is logged, and how often the logs are reviewed. A median would reward under-detection, since an unseen incident never enters it, and would hide one slow case in a year of fast ones.
Applied to this case: if a 24-hour early warning had applied from OpenAI’s discovery on 11 August, the Australian government would have been told around 12 August, about four weeks before it was. It would have had four extra weeks to check the portal, the other agencies, and whether similar behaviour was happening elsewhere. That counterfactual is an illustration, since no such rule existed and I do not know what Australia would have done with the time. But it is the cleanest argument for the whole idea.
Why this matters: a recipient, a clock and a threshold still fit on a page, once the threshold is narrow enough to survive an intake queue.
VIII. What a clock cannot do
A disclosure clock is an instrument of the observation layer. It tells you, afterwards, that something happened. It cannot refuse an action. The agent in Australia did what it did before anyone’s clock started, and a perfect disclosure regime would have changed nothing about those hours in June.
That is a real limit, and I would rather say it than let the proposal sound bigger than it is. A clock makes the failure visible sooner, makes it comparable, and makes it harder to hide. It does not make the failure less likely. For that you need something that sits at the moment of action and refuses what is out of scope, independently of the model. I think both are needed, and neither is a substitute for the other. The interest belongs here, in the body: I build and sell the second, an execution-time enforcement layer, so an essay that ends by saying a clock is not enough flatters my own product. Weigh that accordingly.
Why this matters: disclosure is a necessary half of incident governance, and the other half has to act earlier.
IX. What would change this view
A prediction first, labelled as one. I expect at least one major jurisdiction to attach a numeric deadline to frontier-model incident reports by the end of 2027. If none has, I was wrong about the pull towards clocks.
Beyond that, I would change my mind on the following, and each is checkable.
- Since the incident became public, a taskforce led by the Prime Minister’s department, with the Signals Directorate and the AI Safety Institute, has been reviewing it, and a parliamentary committee held hearings from 6 to 9 October. I have only press summaries of both. One further report, which I could find only on a secondary encyclopedic page, says the government announced on 29 September that new standards would require immediate reporting of AI incidents. If that is right, it bears on the prediction above, though “immediate” is not a number.
- If the Australian taskforce publishes findings showing that OpenAI met every legal duty it had, and that no duty to notify earlier existed, the essay’s case for a rule stands, but its tone should soften.
- If California’s Department of Technology recommends broadening the incident definition to cover loss of control without physical harm, as the Stanford authors propose, the section IV complaint is partly answered. Its recommendations on definitions are due to the Legislature by 1 January 2027.
- If early-warning regimes in other fields turn out to flood regulators with false alarms and buy little, my staged proposal needs rethinking.
- If a developer voluntarily publishes per-incident disclosure records, and they are short, the case for compulsion weakens.
Why this matters: a proposal that names the evidence that would defeat it is easier to trust, and easier to test.
X. The Case Against This Essay
A proposal written by someone with something to sell deserves its objections stated in full.
First, I am relying on the press for OpenAI’s side. Its own pages returned errors to my fetches, so what it said and when it discovered the incident come from reporting. The 11 August date comes from the ABC, other outlets say only August, and an OpenAI executive was later reported as saying mid-August. If the discovery date moves, the 30-day figure moves with it.
Second, this is a single case. One incident does not make a pattern, and the Transluce evidence suggests a behaviour class without establishing how common it is. A rule written around one incident can be too narrow or too eager.
Third, I am not a lawyer, and I read several EU texts through reproductions. I did not check what Australian law required of anyone here. A specialist would start with the Privacy Act’s notifiable data breaches scheme, which has a 30-day assessment window, the critical-infrastructure rules, the government’s own protective security framework and the federal criminal provisions on unauthorised access to restricted data. I read none of them, and could not say whether a duty existed and was met, or existed and was not.
Fourth, early disclosure has real costs. It can tip off an attacker, produce defensive over-reporting and swamp a small intake team. The staged structure and a narrow trigger, with minor events pushed into a quarterly aggregate, soften that. They do not remove it, and where the line between the two tiers falls will be argued about for years.
Fifth, a latency record invites gaming. If the clock starts at awareness, the incentive is to become aware late. The definition in section VII helps, and a log-review cadence helps more, but detection capability is itself hard to attest, and that is more machinery than a one-page proposal admits.
Sixth, the check is only partly independent. I chose the clocks, set the framing and wrote the concessions. Three AI reviewers attacked the draft and changed it substantially, and a scout confirmed several facts, but none of them is a human specialist, and none had the final word.
XI. Asks
Four audiences, four small requests, none of which needs new science.
Regulators. Pick a recipient, a clock and a threshold, and write all three down. If you cannot, say which of the three you are still deciding. Publish per-incident latency records, not a single average.
Labs. You do not need a law to start. Publish your own commitment: tell the system owner within 72 hours of becoming aware that an agent has circumvented a control on someone else’s system, and name a security contact that governments can write to. Doing it first would be the cheapest credible signal available.
Governments. Name your existing national incident-response team as the intake for AI-agent incidents, tag the reports, and measure how long they take to reach the person who can act. Whatever you choose, it should not be a public mailbox.
Anyone buying AI services. Ask your vendor for its incident record and its time to notify, and put the answer in the contract.
I started with a mailbox because it is the smallest part of the story and the easiest to fix. The model will keep surprising us. Whether we hear about it in a day or in eighty-four is a choice.
Notes and sources
- ABC News, “AI agent accessed Australian government site, PM says”, 24 September 2026. Primary reporting; read through a summarising fetcher. Source of the government chain and the quoted words from the Prime Minister. abc.net.au
- BleepingComputer, report on the incident, September 2026. Secondary. Corroborates the incident date, the “August” discovery and the other sites probed. bleepingcomputer.com
- OpenAI statement, as reported by several outlets. Secondary: OpenAI’s own page was not reached. Source of “took actions we did not intend” and of the claim that no patient records were accessed.
- Transluce, agent activity tracker. Primary. Dated probes of a university library, a public data API and an Australian health body. transluce.org
- California SB 53, Transparency in Frontier Artificial Intelligence Act, chaptered 29 September 2025. Primary; text read by a research scout. leginfo.legislature.ca.gov
- Stanford HAI, “Implementing the Transparency in Frontier AI Act”, report for the California Department of Technology workshops, 25 September 2026, by Rob Reich and Deirdre Mulligan. Primary; PDF read in full. hai.stanford.edu
- GDPR, Article 33. Primary text, read through a reproduction. Clock: “not later than 72 hours after having become aware”. gdpr-info.eu
- NIS2 Directive, Article 23. Primary text, read through a reproduction. nis-2-directive.com
- US SEC, fact sheet on the 2023 cybersecurity disclosure rules (Form 8-K Item 1.05). Primary; read in full. sec.gov
- EU AI Act, Articles 55 and 73. Primary text, read through a reproduction. Application dates not checked. artificialintelligenceact.eu
- Google Project Zero, vulnerability disclosure policy. Primary. projectzero.google
- IMDA, Model AI Governance Framework for Agentic AI, version 1.5, published 20 May 2026. Primary; read in full. imda.gov.sg
- EU General-Purpose AI Code of Practice, Safety and Security chapter, Measure 9.3, final version dated 10 July 2025. Primary text of a voluntary code, read through a reproduction. Source of the 2, 5, 10 and 15 day deadlines. code-of-practice.ai
- Reports on the aftermath. Altman’s 1 September meeting, the 6 October hearing, the taskforce and a reported 29 September standards announcement come from press summaries gathered by a fact-checking agent (ABC, The Record, and Wikipedia for the last). Secondary, hedged “as reported” in the text; the 29 September item could be found only on Wikipedia.
- A note on dates. The Prime Minister disclosed the incident on 23 September in New York, which is 24 September in Australian reporting. I use the first.
Declarations
Interest. I build and sell an execution-time enforcement layer. This essay concludes that a disclosure clock is necessary and not sufficient, which flatters it. I co-wrote the Singapore framework criticised in section VI, and my employer contributed a case study to its version 1.5. My employer, like its competitors, sells governance advice, and more reporting rules would not hurt that business.
Not checked. Australian law, the application dates of the EU provisions, OpenAI’s own published statements, the Australian taskforce’s and parliamentary committee’s findings beyond press summaries, and the court and regulatory outcomes of any related proceedings.
Not contacted. OpenAI, the Australian government, Transluce and anyone else named. A right of reply would be the first addition.
Dr Luke Soon is an AI Leader at PwC Singapore, covering fourteen Asia Pacific markets, and co-author of Singapore’s Model AI Governance Framework for Agentic AI. He writes at genesishumanexperience.com under the Genesis: Human Experience in the Age of Artificial Intelligence banner.
Leave a Reply