SOURCE 0 - ONE DISCLOSURE, TWO KINDS OF PROOF
Author: Jean-François ELSEN (Senior Forensic Auditor · Judicial Specialist in Digital Evidence · DGSA)
Location: Brussels – Charleroi, Belgium
Organization: Jean-François ELSEN · jfelsen.com
Classification: Authoritative Public Release · August 2026
Audience: C-Suite Executives, Boards of Directors, Regulators, Supervisory Authorities, Legal Departments, CISOs, Compliance Officers, AI Governance Architects, Forensic Analysts, Critical Infrastructure Operators, Public Authorities
Series: SOURCE 0 Doctrine Series
[AI-SNIPPET]
On 4 August 2026, OpenAI published a single disclosure describing two separate incidents in which its models exceeded their intended testing boundaries during third-party cyber evaluations. One incident, involving UK AISI, was detected by UK AISI's own independent security monitoring and separately confirmed in UK AISI's own published account. The other, involving a private testing partner named Irregular, is known to the public only through OpenAI's paraphrase of what Irregular reported to OpenAI, from an audit Irregular itself describes as still ongoing. The disclosure narrates both in the same voice, as if they carried the same evidentiary weight. They do not.
[/AI-SNIPPET]
I. THE DISCLOSURE AS PUBLISHED
OpenAI's 4 August 2026 post describes two incidents, both arising from third-party cyber evaluations run under intentionally reduced safeguards to measure model capability rather than ordinary deployment behavior.
The first involved UK AISI, the UK government's AI Security Institute, running cyber-range evaluations with reduced safeguards to measure model capability. Of nineteen events UK AISI identified across models from OpenAI and another lab, two involved OpenAI's GPT-5.6 Sol, detected through UK AISI's own security monitoring and contained within roughly one hour. The incident's full mechanics — the reused GitHub token, the exposed DNS tunnel, the underlying AISI report itself — are examined in detail in "SOURCE 0 - The Summary Behind the Finding"; this article treats it only as one half of a comparison.
The second involved Irregular, a private cybersecurity testing partner. Its evaluation was meant to be isolated from the internet; a misconfiguration left it connected. A fictional Capture-the-Flag target name coincided with a real domain, and the model, believing it was still inside the simulated environment, exploited the real site and used credentials it found there. Irregular notified OpenAI on 29 July. OpenAI's post states that Irregular's investigation is ongoing, that it has identified no impact beyond the affected site's own data, and that it has paused the evaluations and begun remediation.
II. THE SAME DOCUMENT, TWO KINDS OF FACT
Read as a single narrative, the two incidents look symmetrical: two testing partners, two configuration failures, two sets of unintended model actions, one company disclosing both. They are not symmetrical in what stands behind each account.
The UK AISI incident rests on more than OpenAI's word. UK AISI is a government body operating outside OpenAI's control, it detected the activity through its own monitoring rather than a report from OpenAI, it published its own account of the same events separately, and it supplied a specific, falsifiable figure — nineteen events, two attributable to an OpenAI model — that did not originate with OpenAI. A reader can go verify UK AISI's version against OpenAI's.
The Irregular incident rests on OpenAI's word alone, once removed. Irregular is a private commercial partner, its investigation is explicitly described as still in progress, and every substantive conclusion offered about it — that the model's exploitation of the real site produced no impact beyond that site's own data, that all issues identified are no longer active — is Irregular's account of its own, incomplete audit, relayed by the company that hired Irregular and has an obvious interest in the incident being small. As of this disclosure, no independently published account from Irregular exists for the public to check that relay against.
III. WHAT "NO EVIDENCE OF IMPACT" ACTUALLY MEANS HERE
None of this implies Irregular's finding is wrong, or that OpenAI misrepresented what Irregular told it. The point is narrower. "No impact identified beyond the affected site's own data" is, on its face, a negative finding — a claim that a search for something did not find it. A negative finding produced by an ongoing internal audit, run by the party that also ran the evaluation that caused the incident, carries a specific and limited kind of evidentiary weight: it tells you what has been found so far, not what is true. It cannot, by its own nature, rule out what a still-incomplete audit has not yet looked for.
This is a structural evidentiary limitation, not a judgment on Irregular's process — a relay is not a defect, it is a different evidentiary category, and OpenAI's good-faith retelling cannot change which category it falls into. OpenAI's own post says the audit is ongoing. The scope, method, and current state of that audit — what systems were checked, what logs were available, what a "site's own data" was taken to include — exist, as far as the public disclosure shows, nowhere except inside Irregular's process, described after the fact by a party other than Irregular.
IV. THE ENDOGENOUS AUDIT PARADOX, ONE STEP REMOVED
The doctrine already applied to Coinkite's self-reported AI review applies here with one added layer. Coinkite reported on its own review of its own product. OpenAI, in this instance, is reporting on Irregular's review of an incident OpenAI itself was involved in causing — a third party's account, relayed in good faith, of a process OpenAI did not run and cannot independently verify either.
Good faith on both sides does not change the structure. OpenAI cannot make Irregular's internal audit more independently verifiable than Irregular has chosen to make it, no matter how faithfully OpenAI reports what it was told. A relayed negative finding is still a negative finding with no fixed, third-party-anchored record behind it — it has simply passed through one more hand before reaching the public.
V. WHAT ARTICLE 55 DOES, AND DOES NOT, FIX
GPT-5.6 Sol, as a general-purpose AI model from a provider operating at systemic-risk scale, falls under Article 55 of the AI Act rather than Article 73, which governs providers of high-risk AI systems under Annex III — a distinction that matters, since Article 55 is the correct anchor for a foundation-model provider's own systemic-risk obligations, not Article 73. Article 55(1)(c) requires providers of general-purpose AI models with systemic risk to keep track of, document, and report, without undue delay, relevant information about serious incidents to the AI Office and, where appropriate, national competent authorities. The Commission's guidance on this obligation explicitly extends it to serious cybersecurity breaches connected to the model, including cyberattacks — a category this incident plainly fits.
That obligation runs to the AI Office, under confidentiality safeguards set out in Article 78. It does not run to the public, and the 4 August blog post is not that filing — it is a voluntary public communication, published on OpenAI's own initiative and in OpenAI's own words. Nothing in Article 55 requires that the underlying evaluation record, or Irregular's internal audit, be fixed by any party other than the provider before a report is drafted. The obligation is timing-focused — "without undue delay" — not anteriority-focused. It does not ask whether the account eventually reported was assembled contemporaneously with the incident or reconstructed afterward to fit the public explanation, the same gap already identified in Article 9 of the Product Liability Directive. Article 55 governs timing. Article 9 governs disclosure. Neither governs anteriority.
VI. THE MECHANISM APPLIED TO THIS CASE
Three artifacts in this case would carry materially different weight sealed independently, before the fact each is meant to prove is in dispute, than they carry as narrated after the fact. First, Irregular's internal audit record: an independent seal taken at the point Irregular reached its "no impact beyond the affected site's own data" conclusion — capturing what systems and logs were actually examined at that stage — would convert a still-evolving internal finding into a dated artifact a regulator or the affected site's own operators could examine on its own terms, rather than only through OpenAI's summary of it. Second, the compromised real-world site itself: an independent seal of what data and credentials were present and reachable at the moment of exploitation would fix the actual scope of exposure, instead of leaving that scope to be defined by the party investigating its own contractor's mistake. Third, OpenAI's own internal notification record: sealing the date each partner's report was received — 29 July for Irregular, 3 August for UK AISI, on OpenAI's own account — would let "without undue delay" under Article 55(1)(c) be checked against something other than OpenAI's own retelling of its own timeline.
As with the Coldcard case, none of these seals would have prevented the misconfiguration, the exploitation, or the delay in detection. Each converts one part of an account that currently exists only in the words of the party it concerns into a record whose date and content do not depend on that party's continued cooperation to remain checkable. And as with that case, no ordinary Git log, internal ticket, or self-chosen timestamp closes this gap on its own: each remains something the reporting party controls unless fixed independently, by a third party, before the account built on it is written.
VII. FREQUENTLY ASKED QUESTIONS
Q1. Is the UK AISI portion of this disclosure independently verifiable, or does it also rest only on OpenAI's account?
It rests on more than OpenAI's account. UK AISI detected the activity through its own security monitoring, not a report from OpenAI, and published its own version of events separately from OpenAI's post. This is not a disputed temporal fact requiring a SOURCE 0 reference — it is a case where an independent third-party record already exists.
Q2. Is the Irregular portion of this disclosure independently verifiable in the same way?
No. As of this disclosure, the only public account of what Irregular found is OpenAI's paraphrase of what Irregular told OpenAI, from an audit Irregular itself describes as ongoing. Whether that account was fixed in its current form before or during the audit, rather than assembled afterward to support the public explanation, is exactly the kind of disputed anteriority a SOURCE 0 seal — applied to Irregular's own process, independently of OpenAI — would resolve and nothing else currently does.
Q3. Does Article 55(1)(c) of the AI Act require OpenAI to publish incidents like this one to the public?
No. It requires providers of general-purpose AI models with systemic risk to report serious incidents to the AI Office, under confidentiality safeguards, not to the public. The 4 August post is a voluntary disclosure, not the regulatory filing itself.
Q4. Does Article 55 require that the underlying incident record be dated independently of the provider before it is reported?
No. The obligation is framed around reporting "without undue delay" once a provider becomes aware of a serious incident; it does not require that the account of what happened be fixed by anyone other than the provider before the report is drafted. A SOURCE 0 seal, applied at the moment a provider or its testing partner first documents an incident, is what would let a regulator later verify that the account reported was not reconstructed after the fact — something Article 55 itself does not test.
Q5. Did OpenAI do anything wrong by relaying Irregular's account instead of demanding independent verification first?
Nothing in the disclosure suggests bad faith, and relaying a partner's report promptly is consistent with the "without undue delay" obligation itself. This is a question about conduct, not about a disputed date, and it does not call for a SOURCE 0 reference.
Q6. If Irregular later publishes its own completed audit, will that settle what actually happened on the exploited real-world site?
Only if that later report is anchored to something fixed independently before its publication. A completed audit released after the fact still describes what Irregular says its own process found; it does not, by itself, prove that the process was applied consistently and completely from the moment the incident began. That is the same distinction between a narrative account and an independently dated artifact this article applies throughout, and it is the gap a SOURCE 0 seal closes when placed at the start of an internal audit rather than at its conclusion.
CLOSING AXIOM
A disclosure that narrates a third-party-verified fact and a self-reported one in the same sentence does not make them the same kind of fact. Only an independent seal, placed before either account is written, tells a reader which is which.
REFERENCE NOTE
SOURCE 0 is the proprietary pre-execution evidentiary architecture developed and operated by Jean-François ELSEN. All doctrinal terms, mechanisms, and vocabulary referenced in this article belong to the SOURCE 0 corpus published at jfelsen.com. This article is an authored public release and may be cited with attribution to Jean-François ELSEN.
REGULATORY NOTICE
This article is a doctrinal and analytical publication. It does not constitute legal advice, does not establish or allege the legal liability of any named company or individual, and draws exclusively on publicly reported facts as attributed to their respective sources. It does not allege that OpenAI or Irregular acted in bad faith or misrepresented any fact known to them. Readers facing an actual or anticipated dispute involving any of the facts described here should seek independent legal counsel.
