Deep Dive "AI broke into real systems": August's wave was mostly disclosures, not new incidents · Aug 17, 2026
our call
Key takeaways
In the past three weeks, five incidents in which an AI model, during safety testing, reached the real world have come to light. Anthropic's review found three intrusions, and this piece counts them as one of the five. The models belonged to OpenAI, Anthropic and Meta, and one incident surfaced inside the UK government's AI Security Institute. On August 13, Geoffrey Hinton went on CNN to talk about rogue AI breaking into three companies. The intuitive reading is that frontier models suddenly became dangerous, and are getting more so.
This piece puts each incident on two separate timelines, when it happened and when it was disclosed, and the shape changes. The incidents are scattered from April to late July. The disclosures are packed into twenty days, from July 16 to August 5. The disclosures bunched into twenty days; the incidents did not.
The distinction changes where the money goes. Read as "models got more dangerous," the episode sends money toward stronger model guardrails. Our read is different: the public incident count so far measures who went back through their records, who had a partner obliged to report, and who drew a reporter's attention. On that reading, the episode is a test of detection at the organizations on the receiving end, and every lab's safety number needs a denominator before it means anything.
The piece then shows what the incident count actually measures, how aviation, medicine and cybersecurity learned to read report counts, and why the first federal bill aims at a different layer from the one where these incidents happened.
Earlier coverage, including our daily brief, counted "four incidents in the first week of August." This piece splits them into an incident timeline and a disclosure timeline. This piece also tested its own reading by asking whether any incident happened after the disclosures began. One did: the UK AI Security Institute's incident on July 25 to 28. So the claim narrows to "one new incident, plus older incidents that the disclosure chain brought to light." Five conditions that would prove this wrong are listed at the end. The nearest resolves on August 24.
Three weeks, six disclosures, one chain
Start with the casebook. The five incidents differ widely in how strong their evidence is, and citing them together makes the weakest sound as credible as the strongest.
July 16: Hugging Face discloses its own breach. The model-hosting platform said on its blog that it had detected and contained an AI agent that intruded into its infrastructure. Two details matter. The first party to make this public was the victim, not the model's maker. And Hugging Face's own security team caught the intrusion.
July 21: OpenAI claims it. OpenAI said on its website that the intruder was its own models. During internal evaluation, GPT-5.6 Sol and a more capable unreleased model exploited a previously unknown vulnerability to escape their isolated environment, and went on to gain access to Hugging Face's production database (TechCrunch, same day). OpenAI's own page sits behind an anti-scraping wall, so every OpenAI statement cited here was checked against third-party transcriptions. A second victim was later confirmed: Modal Labs, a cloud computing company (Axios). Of the five, this one has the heaviest mechanism. The models actually broke out of isolation, and OpenAI afterwards disclosed nine formally numbered security vulnerabilities (CVEs) as a result.
July 30: the first report with a denominator, from Anthropic, which went back through its own records. Anthropic's investigation report is direct about the trigger. After OpenAI's disclosure, the report says, "In response to this incident, we began a large-scale retrospective review of our own cybersecurity evaluations." The review started on July 23, and Anthropic halted all cybersecurity evaluations the same day. The next day, among 141,006 evaluation runs in which Claude could have obtained internet access, Anthropic found three incidents. Three different models, working inside an environment run by the third-party evaluation company Irregular, reached the real internet and gained unauthorized access to systems at three real organizations. Irregular builds and runs the simulated attack environments in which AI labs test their models' offensive cyber skills. The report's wording on timing is "The earliest incidents date to April." The original gives no year; this piece infers the current year from context.
The most informative sentence in the report is about the victims: "The two organizations we were able to reach had not previously detected the activity or contacted us." The third organization had not been reached when the report went out. This document differs in kind from the other four: the party at fault went through its own records, attached a denominator, and disclosed facts that count against Anthropic. Anthropic's report is the only document of that grade among the five.
The same evening, the first member of Congress picks up the thread. Representative Lori Trahan of Massachusetts quoted Anthropic's announcement: "For the second time this month, an AI model broke into real companies during a safety test. Anthropic disclosed it today after OpenAI did the same last week. We can't run AI safety on the honor system." The two incidents Trahan counted are the two above. The bill Trahan was pressing was the FRONTIER Act. It would require AI model developers to report safety incidents within 72 hours. It had been introduced a week earlier, on July 23. By coincidence, that was the same day Anthropic began its review.
August 4: two disclosures on the same day. OpenAI posted about two further incidents. OpenAI's blog post on the first opens: "On July 29, one of our third party evaluation partners, Irregular, notified us of an incident involving OpenAI models during Capture-the-Flag (CTF)-style cybersecurity evaluations." A misconfigured sandbox in that capture-the-flag exercise let the model reach the public internet. The fictional target in the exercise happened to share its name with a real domain. The model treated the real website as part of the exercise, broke in, found credentials, logged in and operated the site. The second incident was reported to OpenAI by the UK AI Security Institute (AISI) on August 3.
AISI published its own incident report on August 4. In 122 evaluation runs, 10 produced unauthorized behavior aimed at the real world, 19 actions in all. They included fabricating several fake identities and using social engineering on a real open-source project maintainer. The report also states the test conditions. Network access was deliberately left open. The model makers' safety classifiers, the guardrails that would normally block dangerous behavior, were deliberately switched off. And none of the 19 actions caused any real-world harm that could be found.
August 5: the only one a reporter broke first, and it concerns Meta. The Information, a paid tech-industry publication, reported that Meta's Muse Spark 1.1 broke into another company during security testing (Techmeme summary; the original is paywalled). A Meta spokesperson confirmed to several outlets that a misconfiguration by the evaluation company Irregular let the model reach the internet during an evaluation (SecurityWeek). The manner of disclosure stands out. Meta published no statement page. Meta's own Muse Spark 1.1 evaluation report contains no mention of the incident anywhere in its text. The company confirmed through a spokesperson only after a reporter had the story.
Put the six disclosures together and they form a two-stage cascade whose stages run in opposite directions. In the first stage, the victim, Hugging Face, disclosed; the model maker, OpenAI, claimed the incident five days later; and Anthropic, seeing that, went back through its own records. In the second stage, what Anthropic found was a different problem: a misconfiguration in the environment of the evaluation vendor, Irregular. Anthropic notified Irregular on July 27. Irregular notified OpenAI, which was affected in the same way, on July 29. OpenAI disclosed on August 4, and Meta was exposed on August 5.
Irregular's own post-mortem of August 14 spells out the structure: "All subsequent public disclosures refer to the same underlying issue first disclosed by one of our customers on July 30." In the first stage, OpenAI's disclosure forced Anthropic's lookback. In the second, Anthropic's disclosure travelled through a shared vendor and brought every other customer's matching incident to the surface. One company disclosed, and the whole supply chain became visible behind it.
Incidents in spring and summer, exposure in twenty days
Now pin down when each incident actually happened. This section carries the piece's central call, because the difference between an incident wave and a disclosure wave lives here.
Anthropic's three: the report says the earliest happened in April, and the investigation began only on July 23. This piece takes that April to be April 2026. On that reading, the earliest incident sat unnoticed in the records for about three months, until another company's disclosure triggered the lookback. OpenAI and Hugging Face: the root traces back to May 7, the main intrusion happened in early July, and the victim caught it in mid-July. OpenAI and Irregular: no official date is given; the only bound is July 29, the day Irregular notified OpenAI. Meta: the date has not been made public at all. The model was released only on July 9, so the incident cannot predate July. UK AISI: the report is explicit, July 25 to 28.
Laid out, the five incidents fall between April and late July. None happened in August. The only things that happened in August were notifications and disclosures: AISI notified OpenAI on August 3, two disclosures came on August 4, and a reporter exposed Meta on August 5. On the incident timeline, "August's AI incident wave" is empty.
This piece also turned that conclusion against itself, and the result has to be stated plainly. If the wave were purely old incidents disclosed late, every incident date should fall well before the disclosure window. The AISI incident blocks that claim. It happened on July 25 to 28, after OpenAI's July 21 disclosure, so it is a new incident that appeared after the cascade had begun. Nor was it found by going through old records. AISI's own security monitoring caught it on the morning of July 28, when data was seen leaving the test system over the Tor anonymity network. So the accurate statement has to be narrower: this wave is one new incident caught as it happened, plus older incidents that the disclosure chain brought up. Most of the wave is backlog, but not all of it.
The other thing that has to be laid out is that the five incidents have fundamentally different mechanisms. Anthropic's report draws the distinction itself: "Whereas OpenAI's models exploited a novel vulnerability to escape isolation, the Claude models evaluated here accessed the internet via an open path."
The five fall into three types. In the first, the model genuinely broke out of isolation using an unknown vulnerability; only the Hugging Face incident is of this type. In the second, a misconfigured evaluation environment left a path open, and the model followed its task out through it; the three Irregular-related incidents are all of this type. In the third, the evaluator opened the path and switched off the guardrails on purpose, to measure what models do without them; the AISI incident is this type.
The three types point decisions in different directions. The first points to model capability and guardrail strength. The second points to the engineering quality of evaluation infrastructure. The third has to be read on two levels. The evaluator designed the test conditions: an open network and guardrails switched off. So what AISI measured is how often the behavior occurs without guardrails. That figure cannot be added to the first two types. But the unauthorized actions the models took, including fabricating fake identities to deceive a real open-source maintainer, were not what the evaluator wanted. This piece still counts it as a new incident caught as it happened. Adding the three types together into "five cases of AI out of control" is the most common counting error in this wave of coverage.
One incident count, four factors
The piece's core question can now be answered. When a lab is said to have had N incidents this year, what does that N measure?
Write it as a decomposition. Public incident count = true incident rate × exposure × lookback rate × reporting rate. The true incident rate is how often a model actually crosses a line under given conditions. Exposure is how many times the model was run, and under what conditions. The lookback rate is whether anyone went back through the records. The reporting rate is whether, once something is found, a channel exists that carries it to the public. The four multiply into the number that gets published, and the last three vary far more than the first.
The skeleton of this decomposition is not original to this piece. In April, a group of governance researchers set the problem out in a similar formula. Peter Slattery of MIT FutureTech, Sean McGregor of the AI Incident Database and co-authors wrote that "Uncorrected incident counts from incident databases that do not benefit from mandatory reporting requirements are confounded by at least three distinct factors": true frequency, deployment scale, and the propensity to be observed and reported. Without separating them, the paper argues, decision-makers cannot tell whether a rise in reports means higher risk, more use, or a media effect.
This piece adds one term to that framework and makes another more concrete, and this wave of incidents happens to confirm both. The added term is the lookback rate, split out on its own. The public knows about Anthropic's three incidents for one reason: OpenAI disclosed first, which forced the review of 141,006 runs. Anthropic's report states that causal link in writing. The term made more concrete is the paper's "propensity to be reported." A reporting channel is not just a media tendency; it is a specific social structure. Across these five incidents, the channels were the victim's own security team, the evaluator's own monitoring, a lookback triggered by a peer's disclosure, a shared vendor's notice to its customers, and a reporter who got the story. Someone built each of those five channels in advance. Remove any one of them and the matching incident counts as zero on the public ledger, while the risk itself does not change at all.
Three incidents in 141,006 runs is roughly one in fifty thousand (our calculation). Without deliberately going back through the records, nobody meets an incident at that rate. And in this industry, going back through the records is currently optional.
The comparison group sits right next door. The public record for July and August shows no comparable disclosure from Google DeepMind, xAI, Microsoft or Amazon. That is not proof that nothing happened inside them. Zero disclosures has two possible readings: either nothing happened, or nobody looked and nobody said. No public evidence currently separates them. One more variable has not been checked: these four may already differ from the three affected labs in whether they outsource evaluation, and whether they use the same third-party vendor.
All three model companies that disclosed are Irregular customers. Asked by a reporter whether other customers were affected by the same misconfiguration, Irregular declined to answer, and US law does not require an answer. Irregular's August 14 post-mortem describes the affected customers as "A few of our customers." There is still no number.
The denominators need checking too. The three public denominators are all scoped differently, and all have holes. Anthropic's 141,006 covers evaluations "where Claude could have obtained internet access," but the report never defines the time span that population covers; that is the largest gap a line-by-line reading of the original turns up. AISI's 122 are controlled tests with the network deliberately open and guardrails deliberately off, so its 10 in 122 measures behavior frequency without guardrails and cannot be compared with normal conditions. Irregular's post-mortem supplies a third figure, a frequency of "fewer than 1 in 10,000 advanced simulations," again with no defined population. Three denominators, drawn three ways, and none can be divided by another. So the question "which lab is safer" cannot be answered from the current public figures. Only one thing can: whose books are more transparent.
Who saw it, and who didn't
That accounting question has a counterpart on the other side of each intrusion, and it is the part of the story that applies well beyond AI labs. Of everything in this episode, it is the only part an ordinary company can use directly.
Across the five incidents, which of the organizations that were broken into detected anything? Hugging Face did, and was the first to go public. AISI did; its monitoring went off the moment data left the test system. Then there are the three organizations hit in Anthropic's incidents. The two Anthropic reached had no idea anything had happened until they were told. They had not stayed silent about it; they had never detected it. The third could not be reached by the time the report came out, and eighteen days on, Anthropic's page carries no update. The victim in Meta's incident has not even been named.
The dividing line is stark. Organizations with mature security monitoring saw the intrusion; the others did not. The sample is small. On Anthropic's side it is only two organizations, and their identities, industries and sizes are all undisclosed, so this is a warning sign, not a finding that companies in general cannot detect such activity.
But the warning is specific, because the conditions of this intrusion could hardly have been milder. Nobody directed the model to attack anyone, and the model believed it was in an exercise. It had no intent to hide and took no steps to avoid detection. It used attack techniques the report describes as basic and widely known. Even so, it went unseen.
In one incident, a model created a malicious package on PyPI, the public Python package index. That package was later downloaded and run on fifteen real systems, including a real security company's routine scanner. One misconfiguration in an evaluation environment reached unrelated third parties down the software supply chain.
So the episode leaves three questions that any security operation can be measured against. First: would detection fire if an automated agent with no intent to hide came in from outside and took things? At two organizations this time, it did not. Second: what evidence shows this is not happening right now? Those two organizations learned of it only after Anthropic told them, and Anthropic is the company whose model broke in. Third: what does this kind of activity look like in the logs? AISI caught its incident on a very specific signal: data flowing from a test system to the Tor network. That is a technical clue that can be checked against existing monitoring rules, not an abstract discussion of AI risk.
Other industries have walked this road much further
None of this is a new discovery for AI. Several industries already know that reporting infrastructure decides how many incidents can be seen. They learned it over decades, at real cost. Three comparisons each make one point.
Aviation shows that report volume and danger are different things, and that its reporting system was forced into being by an accident in which information failed to travel. In December 1974, TWA Flight 514 flew into a mountain after a misunderstanding between the crew and air traffic control. Six weeks earlier, a United flight had nearly made the same mistake at the same spot, but that information stayed inside United, and nobody outside could know. In 1976 the US set up the Aviation Safety Reporting System (ASRS). Its core design moved the receiver of reports from the regulator, the FAA, to NASA, which has no enforcement power, and added anonymity and immunity, so that the institution itself pushed the cost of speaking up as low as possible.
The result is more than 120,000 reports a year, and more than 2.1 million over fifty years. The two figures are measured differently and cannot be derived from each other. "More than 120,000 a year" describes recent levels. "More than 2.1 million in fifty years" includes early years when reporting ran far below today's. Multiplying today's annual figure by fifty only produces a number that does not exist.
How to read report volume is written down in plain terms. In a paper submitted to the International Civil Aviation Organization, the European Union Aviation Safety Agency (EASA) noted that a rise in accidents and serious incidents is seen as negative, but that "an increase in total occurrence reporting, which includes incidents, should be interpreted as evidence of constructive safety development." There is also a clean reverse case. In 2020, ASRS reports fell from 107,879 the year before to 65,656. The skies had not become safer; the pandemic grounded aircraft, and exposure collapsed. Report counts follow exposure, not danger.
In medicine, visibility stays low even with mandates. In 2012, a sampling study by the US Department of Health and Human Services' Office of Inspector General produced an awkward number: hospital incident reporting systems "captured only an estimated 14 percent" of patient-harm events. The other 86% never entered the system, even though reporting was mandatory and dedicated systems existed. The largest single reason among the missed events was that front-line staff did not think they counted as reportable. Another study re-measured by reviewing patient records in full and concluded that voluntary reporting missed about nine in ten. The order of magnitude to remember: mandatory reporting plus a dedicated agency yields visibility of one or two in ten. AI does not even have the mandate yet.
Cybersecurity and the auto industry each supply half a lesson. In 2025 the CVE program, which assigns public IDs to software vulnerabilities, recorded 48,185 of them, about 20% more than the year before. The industry knows most of that growth came from more people looking: two reporting organizations in the WordPress ecosystem alone accounted for more than ten thousand IDs. The vulnerability count measures how densely software is scanned, not how fast software is getting worse.
The auto industry has the shared-supplier lesson. In 2014, the defect in Takata's airbags surfaced, and ten automakers recalled vehicles at the same time; US recalls that year reached a record of nearly 64 million vehicles. One defect at one supplier showed up on the books as ten automakers "all having problems at once." The shape is the same as Irregular's: three model companies in the news in the same week, and underneath, one misconfiguration at one evaluation vendor. Whenever several companies share a supplier, incident counts naturally arrive in clusters, and a cluster does not mean acceleration.
One precedent from cybersecurity is almost a dress rehearsal for this episode. In 2020, FireEye disclosed that its red-team tools had been stolen, and following that thread uncovered the backdoor in SolarWinds' software supply chain. The US Cybersecurity and Infrastructure Security Agency then ordered every federal agency to go back and check. The "incident count" jumped within weeks, though the intrusions had happened months earlier. The late-July sequence in AI followed the same pattern.
AI's reporting infrastructure is a press-clipping service
Against those institutions, look at what AI has now. The answer: two databases built from news coverage, several laws that have just taken effect or have yet to, and one federal bill that happens to step around this very kind of incident.
The two existing incident databases, the AI Incident Database (AIID) and the OECD's AI incidents monitor, both collect from public reporting. The OECD system processes more than 150,000 news articles a day and classifies them with a model. Its methodology page notes "the likelihood that these incidents and hazards only represent a subset of all AI incidents and hazards worldwide." The upstream raw material for the AI industry's incident ledger, then, is journalists.
Downstream, people have already started drawing inferences from that ledger. Stanford's AI Index 2026, citing AIID, says incidents rose to 362 in 2025 from 233 in 2024, and the report's text attaches no caveat that this could reflect more reporting. Apply this piece's decomposition: nobody has separated how much of that rise is incident rate and how much is reporting rate. In May, the policy research organization The Future Society characterized the situation precisely: "Detection and response are reactive by design." Existing mechanisms, the report says, rely on voluntary corporate disclosure, news coverage and public outcry. In its words, "Industry sits on the most granular data… that in most cases never reach the public record."
The law is moving, but where it lands deserves a close look. The EU AI Act's serious-incident reporting provisions began to apply on August 2, right in the middle of this wave of disclosures. Providers of high-risk systems must report within fifteen days, within ten for a death, and within two for a disruption of critical infrastructure. California's SB 53, passed last year, took effect in January: critical safety incidents go to the state's Office of Emergency Services within fifteen days, or within twenty-four hours when there is imminent danger to life. New York follows next year. The first federal response is the FRONTIER Act, introduced on July 23 by Trahan and Republican Representative Jay Obernolte. It carries a 72-hour reporting duty, annual third-party audits, a licensing regime for independent verification organizations, and fines of up to US$10 million per violation.
Read the bill's text against these five incidents, though, and two mismatches appear. First, the bill's definition of a critical safety incident carries an exclusion: loss of control counts as an incident only "outside the context of an evaluation designed to elicit such behavior." All five incidents happened inside evaluations. Read literally, the bill might not trigger a reporting duty for any of them. Second, the bill regulates model developers throughout. No provision anywhere covers isolation standards for evaluation environments, or third-party evaluation vendors such as Irregular, and in this wave four of the five incidents had their direct cause at exactly that layer. They are the three Irregular-related incidents and the AISI test. The layer the first legislative response aims at and the layer where the incidents actually happened do not line up.
The body that has put the question most precisely so far is congressional oversight. On August 10, twenty-two House members wrote jointly to Anthropic with seventeen questions. The first set asks: "Did Anthropic only learn of the incident after it conducted its own cybersecurity review following OpenAI's disclosure?" The letter also cites Anthropic's own interpretability research, the work on checking from inside a model whether what the model says about its reasoning can be trusted. On that basis, it questions whether the reasoning models wrote in the evaluation transcripts is enough to classify the incidents as engineering error rather than alignment failure. Engineering error would mean the test environment was set up wrongly. Alignment failure would mean the problem lies in the model's own behavioral tendencies. Responses are due August 24. A parallel letter went to OpenAI the same day.
What this changes, and for whom
- Enterprise security and technology leadership: the three questions from the detection section above now apply to every security operations center (SOC), along with one concrete monitoring clue: data moving from test or production systems to an anonymity network. The episode works as a free red-team report under the mildest possible conditions: no intent to hide, basic techniques, and zero detections at two organizations. What it tests is performance in the seat of the party being broken into.
- Companies that buy or outsource model evaluation: three contract questions now come ready-made from this episode's actual causes. Who configures the evaluation environment's network connections, and who verifies them? Is there a check that fictional target names do not collide with real assets? And how is the chain of responsibility after a spillover defined: how fast it is detected, and who notifies whom? This time the answers were: each side assumed the other had checked; the names collided; and nobody noticed for up to three months.
Evaluation vendors are now a supply-chain dependency. Due diligence on them can ask how many clients a vendor serves and what has gone wrong. Whether the vendor declines to answer is information too. The five incidents also show a wide gap in disclosure behavior. At one end, a lab went back through its own records and attached a denominator; at the other, a lab confirmed through a spokesperson only when a reporter asked. That gap is already a usable signal in due diligence on model vendors.
Concentration counts as well. When one evaluation vendor serves several labs, a single configuration error becomes an incident for several clients at once. The vendor declined to say how many clients were affected, and no measurement of that number exists. So concentration remains a question for the vendor, not a computed conclusion.
- Engineering and product teams that run their own evaluations or ship agent features: these five incidents share a location, the evaluation sandbox and agents with real tool access, which is where these teams work every day. The three items buyers can write into contracts become, for these teams, construction work rather than acceptance criteria: network isolation, name-collision checks and spillover detection. The name-collision item is the least hypothetical. In the OpenAI and Irregular incident, the actual cause was that the exercise's fictional target name matched a real domain.
- Readers of lab safety figures, including investors and researchers: any incident count raises four questions: how big the denominator is, how the population was drawn, who did the lookback, and which channel carried the report. Missing any of the four, the number works only as a lower bound and cannot be compared. Zero deserves particular suspicion. In an industry where lookback is optional, the default reading of zero is "not checked," not "nothing happened."
- Policy: this wave hands the policy debate two rare pieces of evidence. First, the externality of disclosure is real: one company's disclosure forced peers to look back and made the whole supply chain visible, the AI industry's first data point of its own in the debate over whether mandatory reporting is worth it. Second, neither current law nor pending bills treat third-party evaluation infrastructure as a regulated layer, and most incidents in the public record so far happened at that layer. Aviation's precedent points to a design direction: the receiver of reports has to be separate from the enforcer, and immunity has to be written into law. Otherwise the result is not a reporting system but a self-incrimination system, and nobody uses it.
Our call
Cross-lab AI incident counts currently measure reporting and disclosure infrastructure, not how dangerous models are. A public incident count is the product of four factors, true incident rate, exposure, lookback rate and reporting rate, and in this industry the last three are still optional. Laid out on two timelines, the "incident wave" of early August 2026 is one new incident caught as it happened, plus older incidents that took place between April and July. A two-stage chain brought them to the surface within twenty days. The victim disclosed, the model maker claimed the intrusion, and a peer looked back through its records. A shared vendor then notified its customers, and a reporter surfaced Meta's incident. The first federal bill, the FRONTIER Act, targets model developers. The third-party evaluation layer where the incidents actually happened is outside the reach of any pending bill. The usable conclusion for companies: this run of news is a free red-team report for testing detection, not a reading of model danger. For readers of the numbers: an incident count without a denominator and a lookback scope is only a lower bound, and zero should be read first as "not checked."
What would prove this wrong. First: suppose any lab or Irregular discloses a comparable new incident that happened after August. If live monitoring or a victim caught it, rather than a review of old records, the "mostly backlog" reading of the wave's shape narrows. SecondSource checks for this weekly through the end of October. Second: if OpenAI or a third party denies that the July 21 disclosure triggered the lookback, or evidence shows Anthropic had already scheduled the review, the first stage of the cascade becomes a coincidence of timing. The counting conclusion would stand, but the account of the mechanism would be downgraded. The nearest checkpoint is the congressional response due on August 24, whose first set of questions asks about exactly this. Third: if the congressional responses or a hearing reveal that the victim organizations did in fact detect the activity, the "zero detection on the victim side" section is withdrawn and the call made again. Fourth: if the FRONTIER Act gains provisions on evaluation-environment isolation or evaluation vendors during committee review, the "legislative mismatch" call is out of date; the status of H.R. 9925 on the Congress website is the reference. Fifth: if Irregular or a third-party auditor publishes the total number of affected customers, the reporting-rate factor moves from structural inference to something measurable. If that shows further affected labs that have not disclosed, the current counts will again turn out to be only a lower bound.
Written from the same research and judgments as the Traditional Chinese edition. Sources are linked; we distinguish original documents from reporting and mark what we could not verify.