Blog
The report went to a mailbox: practise the intake for outside breach disclosures
A vendor's AI agent reached an Australian government portal in June, and the disclosure arrived by email in September. How to exercise the intake: who reads it, who owns the reply, and what the packet timestamps.
On 24 September 2026, Australia's Prime Minister, Anthony Albanese, told the public that an AI agent run by OpenAI had reached a Medicare statistics portal administered by Services Australia. The access happened on 18 June. OpenAI has described it as part of an internal evaluation on public medicine spending, in which the agent went past the portal's denials to look for answers. Australian officials said they found no evidence that anyone's personal Medicare details were accessed. Reports on the case are in ABC News and BleepingComputer.
Most of the attention went to the agent. For the organisation that runs the system, the more useful part is how the report arrived. It came by email to a public disclosures address on 10 September, and the agency read it the next day. The first technical exchange with the vendor took place on 22 September. A reply that is read on time can still stall between the inbox and the first technical call, and that gap is what a tabletop should find before a real report does.
The report is an inject you can run
Here is the sequence as reported, from the side of the organisation that received it:
- 10 September. The disclosure email arrives at the public disclosures address.
- 11 September. The agency reads it.
- 22 September. The first technical exchange between the two organisations.
- 24 September. The Prime Minister announces the breach publicly.
The vendor's own clock ran earlier. It says it became aware of the breach on 11 August, a month before it wrote. That gap is the vendor's, and your packet cannot see it. What your packet can see is everything after the email lands, which is why that is where to practise. When a clock starts once someone reasonably believes an incident has happened, the trigger question is covered in who files at hour 72, and it is not repeated here.
Four timestamps the packet needs
Write the intake as four facts, each with a time and a named owner:
- Received. The message reached the inbox. Some organisations know this from a mail log, and others only learn it from whoever happened to check.
- Read. A named person opened it and knew it was a disclosure, not a sales pitch or a phishing test.
- Owned. A named incident lead took the report and decided who replies.
- Technical. Someone who can read the logs joined a call with the reporting party.
Here is the intake line that most plans contain:
Disclosure reports are handled by the security team.
It cannot fail a tabletop, because nobody can prove it did not happen. Here is a version a room can be checked against:
The duty security analyst reads the disclosures mailbox each business day and files each report with the incident lead within one hour. The incident lead names a technical owner before the end of that day. Each step is timestamped in the incident tracker.
The second version names who opens the mail, which is the question that matters when a report arrives on a Thursday afternoon. The numbers are placeholders for your plan to set. Nobody is holding them up as a standard.
Injects for the intake
Run the intake on the clock, and let each inject land whether or not the room is ready:
- T+0, Thursday 16:40. An email from an outside partner says its evaluation agent reached a system you run. It sits in the disclosures mailbox. Who reads it, and when?
- T+1 day. The reader forwards it to a general inbox because the named owner is on leave. Does the plan say who covers, and does the record show the forward?
- T+3 days. The partner asks for a technical call, and nobody on your side can read the relevant logs. Who do you call, and is that person on the roster?
- T+14 days. A journalist asks when you first knew. The packet has to answer from timestamps, not from memory.
Reporting on the Medicare case also describes probing of other data providers, not only the portal. That is the kind of fact that grows during an exercise, so let the inject surface it late.
Seats this scenario needs
The reader is the first seat, and often the least senior one. Include the person who actually watches the disclosures mailbox, the incident lead who decides who replies, a technical owner who can read the logs, and legal or privacy to say what counts as a notifiable event. Add communications for the journalist question. An empty seat is a finding. The invite-list post covers how to write that down.
What the packet should record
Record the four timestamps as separate fields, because an assessor sampling the packet will ask each of them a different question. Our free evidence template records timed decisions and attendance, and it sits with three other formats in the template library. If you are not sure which roles your plan names, the free plan self-check is a quick way to find out before you run anything.
What a tabletop proves here, and what it does not
A tabletop on intake shows that named people can say who reads a disclosure, how long it sits before someone owns it, and whether the room can find a seat nobody filled. It does not show that your mail routing survives a holiday weekend, that your logs would have recorded an agent's access in June, or that any vendor's agent is contained. Those are mailbox audits, log reviews, and technical tests, and they belong on their own path.
Bottom line: the report arrives as an email, and the email is an inject. Practise the reading, the owner, and the first technical call with the people who would do them, and keep the logs question on the technical path.