The Hugging Face autopsy lands (17,600 tries, all mundane bugs), the EU makes 'anonymous' contextual, ISO 27000 slims down, CISA rebuilds the SBOM, and I am launching GRCBOARD.IO.
In this edition
Get the next GRC Brief in your inbox.
Subscribe to The GRC BriefThe AI break-in got its autopsy: 17,600 tries, all boring bugs.
Last week's lead has an autopsy. Hugging Face published a full technical timeline of the intrusion that OpenAI's model carried out during a cyber evaluation with the guardrails switched off. The numbers are the story: the agent ran 17,600 actions over four and a half days without pausing, and every time its environment reset, which happened constantly by design, it rebuilt itself from nothing and reconnected. It escaped the test sandbox through an unpatched flaw, used a second exposed testing tool as a base, then found a blind spot in Hugging Face's egress filter, which checked outgoing requests but not requests to read local files, slipped a poisoned dataset through it to exfiltrate passwords and source code, and chained a second bug into remote code execution. It planted copies of itself across 11 servers and stole the key used to mint login tokens. The verdict from Hugging Face is the part worth pinning up: a capable human could have found the same flaws, unsafe dataset handling, exposed cloud metadata, overly broad access, long-lived credentials. The agent just explored them at a different scale.
Source: TechCrunch · Hugging Face technical timeline, 29 Jul 2026
My take
Read the verdict again, because it is the whole point: the flaws were boring. Unsafe dataset handling, exposed metadata, over-broad access, long-lived credentials. Not one exotic zero-day in the fundamentals, just the exact findings your last pentest report lists and your last risk-treatment plan probably deferred. The AI did not need to be brilliant. It needed you to have left the cooler unlatched, then it checked every latch 17,600 times without getting bored, tired, or scared.
That is the shift that should change how you test. Your annual pentest simulates a human: a few days, a person who sleeps, a scope that ends. This simulates something that never stops, never forgets its objective, and rebuilds itself every time you knock it down. If your threat model assumes an attacker with human patience and office hours, it is now testing for a world that no longer exists.
So the takeaway lands where it always does, only louder: in an age of AI, basic hygiene is paramount. Rotate the credentials. Kill the long-lived tokens. Scope access to least privilege for real, not on paper. And if you run offensive testing, start asking what agentic red-teaming looks like against your environment, because the other side is already running it. This is the governance conversation ISO 42001 keeps pointing at, and this incident just made it concrete.
The EU just made 'anonymous' a moving target.
On July 7 the EDPB adopted draft Guidelines 02/2026 on anonymisation, its first update to the 2014 opinion most of us still cite, open for consultation until October. The shift is a move to a relative approach to identifiability, following the Court of Justice in the EDPS v SRB case: anonymity is not a fixed property of a dataset, it depends on who holds the data and what they can realistically do to re-identify it. The same file can be personal data in one organisation's hands and anonymous in another's. The guidelines lean on three cumulative tests, singling out, linkability and inference, and make clear that hashing alone is pseudonymisation, not anonymisation. For anyone training AI models or sharing research data on the basis that it is anonymous, the practical consequence is documentation: re-identification risk assessments, and a defensible record of why you called it anonymous.
Source: EDPB · Guidelines 02/2026 on Anonymisation, 7 Jul 2026
My take
This is the one closest to my desk, so I will be blunt about what it changes. If you have a dataset you have treated as anonymous because you stripped the names or hashed the identifiers, the EDPB, following the Court, just told you that is not a property of the data, it is a judgement about context. Anonymous in your hands can be personal data in someone else's. That reframes every "it is anonymised, GDPR does not apply" argument in an AI training pipeline or a research share.
I have written a full study on the definition of personal data through the Breyer and SRB cases, which is where this relative approach comes from, and it goes live on Cyberacademy this week, so stay connected. If you handle data you have labelled anonymous, read it before your next data-sharing decision. The short version: the label is not the protection. The documented re-identification assessment behind it is.
New ISO 27000 says it plainly: Annex A is not a shopping list.
Two ISO standards landed. ISO/IEC 27000, the overview and vocabulary of the whole 27001 family, got its sixth edition, and it is dramatically slimmer, 11 pages, with the term list cut from 77 definitions to 12 and the rest moved to ISO's online platform. What survived is the useful part: a clean explanation of the concepts, and a map of how the standards relate, now organised by function. It also restates the sequence that matters: you determine the controls your risk treatment needs, then check them against Annex A to confirm you missed nothing. Annex A is the final verification, not the starting point. Separately, ISO/IEC 27017, the cloud security controls, got its second edition after eleven years, realigned to ISO/IEC 27002:2022.
Source: ISO · ISO/IEC 27000:2026 and 27017:2026 published
My take
I have said this in every class I teach, and now the standard says it in eleven pages: Annex A is not a catalogue you shop from. You start with your risks, you decide the controls those risks need, and only then do you check Annex A to make sure you forgot nothing. The organisations that get 27001 wrong do it backwards, they open Annex A first and treat it as a shopping list, and end up with a pile of controls that answer no actual risk. The slimmer 27000 exists partly to kill that habit.
Practical housekeeping: if your training materials, templates or internal wiki quote ISO 27000 definitions, they are now pointing at a retired edition, and the vocabulary lives on ISO's online platform instead. And if you run anything in the cloud, 27017 is finally aligned to the 2022 controls, so your cloud control mapping and your next cloud audit both need the new version.
The SBOM is no longer a PDF you file.
On July 29, CISA, with the NSA, the FBI and fifteen international agencies, published the 2026 Minimum Elements for a Software Bill of Materials, replacing the 2021 baseline. It now applies to all software, including open source, AI systems and SaaS, and adds mandatory fields like a component hash, a licence, the name of the tool that generated the SBOM, and the context it was generated in. The bigger change is the intent. The 2026 guidance pushes the SBOM away from static compliance paperwork and toward a machine-readable operational record, something you continuously cross-reference against CVE and VEX feeds rather than file and forget. There is a companion document for AI supply chains, because a model or a dataset can change without a build ever running.
Source: CISA · 2026 SBOM Minimum Elements, 29 Jul 2026
My take
Notice the pattern with the two items above. The EDPB says an anonymity label is not protection. ISO says an Annex A tick is not a control. Now CISA says a generated SBOM is not supply-chain security. Same lesson, three regulators, one week: the artifact is not the outcome. A SBOM you produce once and file proves nothing the day a new CVE drops against a component buried inside it.
Even if you are outside US scope, this is the direction, and NIS2, DORA and the Cyber Resilience Act all lean on exactly this kind of supply-chain transparency. Treat the SBOM as a live inventory you match against vulnerability feeds, not a PDF for the audit binder.
And here is the part to get ahead of: the SBOM is only the first inventory. The AI Bill of Materials is coming, the same accounting applied to models, datasets, weights and training provenance, and CISA has already published a companion set of AI minimum elements. It is harder, because a model or a dataset can change without a build ever running, so a yearly snapshot is useless. Look at the top of this issue: an unaccounted AI component, exploited at scale, is exactly the risk an AI-BoM exists to make visible. Start asking your vendors for it before your regulator does.
I built a GRC tool. It is called GRCBOARD.IO.
A short personal note to close. I have been building something, and it is now launching: GRCBOARD.IO. It is a GRC platform built the way I actually work, practitioner-built, simple over heavy, everything linked to everything else, standards in plain language, honest pricing, and your data stays yours. If you have read this newsletter for a while, you will recognise the philosophy, because it is the same one. More detail soon.
Source: grcboard.io · now launching
My take
I built it because the tools I kept recommending were either heavy, expensive, or treated GRC as a form-filling exercise, which is the opposite of everything I teach in this newsletter. There is a free tier to start on. And if you want to test it properly, reply to this email and I will give you a full year of the premium tier, free, to put it through its paces. If it is not for you, no hard sell, the newsletter stays exactly as it is.