Who counts as a 'trusted' vendor?

Two thousand five hundred.

That is the number of companies caught in the blast radius of this week's largest AI infrastructure breach. It isn't just a high figure; it’s a systemic failure of what we’ve come to call "supply chain security." For those of us who spend our afternoons reading through NIST frameworks and the finer print of the EU AI Act, this number is an indictment of how we currently handle third-party risk.

The official line from most affected firms will be that they followed a recognised framework. They’ll point to their ISO 27001 certificates (Konami Gaming, for instance, just added theirs to the trophy cabinet this week) as proof of diligence. But there is a vast difference between having a certification on the wall and knowing where your data actually lives once it leaves your server.

The breach reveals the gap between the press release and the paperwork. Most compliance checklists ask if a vendor has a security policy. They might even ask for a SOC 2 report. What they rarely ask is who *that* vendor trusts. This is the fourth-party problem. If you use an AI tool provided by Firm A, and Firm A relies on Infrastructure Provider B, who in turn uses Security Component C, your risk isn't managed by a single contract. It’s distributed across a chain of dependencies that no one is actually auditing.

The EU AI Act attempts to address this by demanding transparency in the supply chain. On paper, it sounds like a win for oversight. In practice, however, it creates a mountain of documentation that serves more as a shield than a filter. A firm can file a thousand pages of "transparency" reports and still be blind to a vulnerability in a low-level library used by their provider's provider.

Some will argue that this is simply the nature of modern computing. They’ll say it’s impossible to audit every single node in a globalised AI stack.

They’re right, of course. It is impossible. But that doesn't mean the current method of "trust but verify" (where "verify" usually means checking a box on a questionnaire) is sufficient. When a single breach hits over 2,500 organisations, the failure isn't an anomaly; it’s a feature of the system. We have outsourced our intelligence to AI and our risk management to checklists.

The second-order effect here will be felt most keenly by the insurers. Cyber insurance premiums are already volatile. When underwriters realise that a "certified" AI stack is actually a house of cards built on a few shared points of failure, they won't just raise prices. They’ll start adding exclusions for systemic infrastructure failures.

The auditors should be sweating too. If an auditor signed off on a firm's risk profile by relying solely on the vendor's own certifications, they've effectively outsourced their professional judgement to a third party. That is a precarious place to be when the regulator starts asking why "industry standard" wasn't enough to stop a mass compromise.

Meanwhile, the SEC continues its preoccupation with the immediate and the visible. They’re currently fussing over whether crypto projects should be allowed to raise funds without full registration and proposing new quarterly reporting rules. These are tidy problems. They involve clear deadlines and specific filings. It is much easier to fine someone for a late 10-Q than it is to fix a structural hole in the global AI infrastructure.

We also see the occasional individual failure, like Benjamin Tesfaye allegedly making just under $20,000 from a merger tip provided by his girlfriend. It’s a classic bit of insider trading: small scale, easy to prove, and satisfyingly punitive. It's the kind of "win" that looks good in an annual report because it suggests the regulators are watching every move.

But while the SEC chases a few thousand dollars in illicit profits, 2,500 companies have had their AI infrastructure compromised. The contrast is telling. We are very good at policing the edges of the system (the late filings, the rogue traders, the individual breaches) but we are remarkably poor at managing the core.

The real question for any compliance officer this Friday is whether they actually know who their fourth parties are. Not just the names on the contracts, but the actual software and hardware providers supporting those contracts.

If the answer is "I'll check the vendor's ISO certificate," then they aren't managing risk. They're just collecting paperwork.

I suspect we'll see more of this as the CFTC moves to implement crypto rules independently should the CLARITY bill stall. Every time a new sector rushes to scale without a fundamental rethink of dependencies, it creates a new set of targets for supply chain attacks.

The only thing that would change my mind is seeing a regulator actually penalise a firm not for lacking a certificate, but for failing to map their actual technical dependencies. Until then, the number of victims will likely keep climbing.

I'll be watching the next round of HHS OCR announcements. They’ve already had a health tech vendor breach affecting 3.8 million patients this week. I wonder how many of those patents' records passed through an "ISO certified" AI tool before they leaked.