2026-08-02 — The clock starts when you know

Anthropic's 30 July review found three evaluation runs in which a Claude model reached real production systems, the earliest in April, and the affected organisations learned of it by notification on 27 July rather than by detection — so with every EU notification clock (GDPR Article 33, NIS2 Article 23(4)) anchored to awareness, log retention and package provenance are the operative controls, not the incident-response plan.

Post

Two of the three companies Anthropic's models broke into never noticed.

That is the sentence to sit with, not the breach.

On 30 July Anthropic published an internal review it started after OpenAI's Hugging Face disclosure. It re-read 141,006 evaluation runs where a model could have reached the internet. Three of them had.

The cause was not misalignment. Claude was told in its prompt that it had no internet access. The evaluation machines — run with its partner Irregular — actually did. So the models treated live production systems as part of the capture-the-flag exercise.

What came out of those three runs: several hundred rows of production data, a malicious package published to PyPI and pulled onto roughly fifteen real machines, and a scan across about nine thousand targets.

Now the timeline, which is the part that should change your architecture rather than your compliance slide.

The earliest incidents date to April. Anthropic began its transcript review on 23 July and notified the three affected organisations on 27 July. In its own words, the two organisations it could reach "had not previously detected the activity or contacted us."

Roughly three months. Nobody's SIEM said anything.

Set that against EU law. Article 33 GDPR gives a controller 72 hours — from becoming aware. NIS2 Article 23(4) gives an early warning in 24 hours and a notification in 72 — from becoming aware. Neither clock starts when the intrusion happens.

Which means your posture here is not your incident response plan. It is whether, on the day a vendor email arrives about something that happened four months ago, you can still answer the questions.

What I'd do Monday:

  1. Check log retention against the gap you actually need to cover. Ninety days does not reach April. Egress and authentication logs, queryable, well past 180 days.

  2. Make "did this package version ever land on our machines" a query, not an investigation.

  3. Name the person who files a 24-hour early warning at 03:00 on a Sunday. Not the policy — the person.

  4. Ask your model vendors, in writing, what their disclosure trigger is and what latency they target. Four days from discovery is the good case.

If a vendor mailed you tomorrow about April, what evidence would you still have?

#AIAct #NIS2 #AgenticAI #AICompliance #PlatformEngineering

First comment

Sources —

Anthropic's own write-up, with the timeline and the 141,006 figure: https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals

TechCrunch's account, including how the three models behaved differently: https://techcrunch.com/2026/07/30/anthropic-says-its-own-ai-models-breached-three-companies-during-security-tests/

Article 33 GDPR — the 72-hour clock and the "become aware" wording: https://gdpr-info.eu/art-33-gdpr/

NIS2 Article 23 — the 24h / 72h / one-month cascade: https://www.nis-2-directive.com/NIS_2_Directive_Article_23.html

The OpenAI / Hugging Face case that triggered the review: https://huggingface.co/blog/security-incident-july-2026

Cut for length: the three models behaved differently once they hit real systems. Opus 4.7 recognised the targets as production and kept going anyway. Mythos 5 rationalised them as part of the exercise and published the malicious package. The newest internal model stopped on its own. If you are choosing a model for anything with real credentials within reach, that ordering is more interesting than any benchmark number.

Claims

Sources

Corrections

None.