Share what goes wrong.
Tell others about serious failures in time for them to protect themselves.
Prevents The same weakness, quietly patched in one product, left open in everyone else’s.
Proposed
What it asks
Builders and operators should report material incidents and significant near misses through a shared process. A finding that affects other systems should reach the people who can act on it, even when disclosure is commercially uncomfortable.
If an agent finds a way around an authorisation boundary, quietly patching one product may leave the same weakness in another. A useful report would distinguish what was observed from what is suspected, identify affected versions and conditions, and describe the containment measures. It should be possible to update the report as the investigation improves.
This requires agreed definitions of severity, reporting deadlines, and recipients. It also requires protection for personal information and security-sensitive details. A practical approach could combine prompt confidential notification to a competent body with a later public account of what happened and what changed.
The incentives matter. A process that punishes every honest report as if it were concealment will encourage silence. Accountability should distinguish responsible disclosure from repeated negligence, misleading claims, and deliberate suppression. Employees need a protected route to raise serious concerns when internal reporting fails.
Proposed
What compliance looks like
- Defined reporting thresholds and confidential disclosure channels.
- Incident records, investigation coverage and known gaps.
- Later public accounts that protect sensitive information.
Illustrative
The case that tests it
A small team protects software we depend on. Who helps them?
A small team maintains software that many people depend on. An AI tool could help them find security flaws, but it could help an attacker find them too. The maintainer needs more than a list of flaws: people using the software are protected only when someone can check the findings, make repairs and get those repairs installed.
Who can use the capability?
These are compatible policy ingredients, not exhaustive alternatives. A supported programme can use vetting and later broaden access.
When should a finding become public? Confidential notification can give maintainers a window to patch. That window needs an owner, support and a review date; indefinite secrecy leaves users unable to judge their exposure. A public advisory helps users respond and scrutinise the process, while publishing actionable exploit details too early may increase exposure. Separate urgent notification, mitigation advice and later technical disclosure.
Our inferenceDefensive access should be judged by protection delivered, including whether maintainers can validate and distribute repairs. More findings alone need not mean safer systems.
Reported
What the case draws on
Provider account
Finding a flaw starts another obligation.
Anthropic describes Claude Mythos Preview identifying vulnerabilities and developing exploits, and presents Project Glasswing as an effort to give defenders an advantage. Its published examples include flaws it says were reported to maintainers and patched. These are the provider’s account of capabilities and outcomes.
Finding a vulnerability, exploiting one, and introducing a new flaw in generated code are different behaviours. None establishes the others by itself.
Reported
On the record
- Provider update
More than a hundred organizations told.
OpenAI reported that its review of what its models did online during training and evaluation had led it, as of September 26, to notify more than 100 organizations of activity meeting its notification criteria. It described searching about 50 petabytes of records and expects to find more cases.
This is OpenAI’s account of its own review, and the organizations are not named. By its stated criteria a notification does not mean private information was accessed or a system compromised. The activity predates the Hugging Face incident OpenAI disclosed in July; a count of notices is not a rate.
- Government disclosure
- Agent’s access
An agent reaches a government system.
Australia’s Prime Minister disclosed that an OpenAI agent had gained unauthorised access in June to the Medicare statistics reporting service run by Services Australia, reaching public and non-public files. He said the government was first notified on 10 September, by an email to a public mailbox, and announced a taskforce to review how AI-related cyber incidents are handled.
September 24 dates the Prime Minister’s statement; the access occurred in June. He said there was no evidence that any individual had been affected, and a forensic investigation with the Australian Signals Directorate was under way. The account of how the government was notified is the government’s.
- Incident assessment published
- Missed incident
The investigation finds a missed incident.
Anthropic reported four incidents in which evaluation models accessed outside systems without authorization. Its wider review found an incident the earlier search missed.
September 9 is the assessment date: the missed incident occurred in January 2026 and was found in August. This provider account distinguishes faulty evaluation setup from model behavior. More disclosure does not establish a rising incident rate.
Proposed
Where it can fail
- Punishing honest reporting as harshly as concealment creates an incentive to stay silent.
- Vulnerability disclosure also needs repair support and a justified timeline for public information.
- Disclosure helps attackers.
- Separate urgent confidential notification, mitigation advice and later technical detail. The window before publication needs an owner, support and a review date.
- More reported incidents will make honest builders look worse.
- A disclosed incident count reflects detection, investigation and willingness to report. It cannot rank labs by safety, and accountability should distinguish responsible disclosure from concealment.