Edition 18

I'll take this one personally, because I've used that vocabulary. I wrote about swarms in July, in August and again last month, and the word carried a story that let everyone look at the machine instead of the perimeter around it. The facts don't change. The framing does. An agent with internet access it shouldn't have had, a package registry nobody watched, credentials with no expiry: each one is something a person configured. I'm dropping the word.

The useful part is the architecture. Jacob Krell of Suzu Labs puts it well: traditional controls are atomic, inspecting one request or one permission, while an agent chains several individually survivable failures into a working path. So build so that intent doesn't matter. Strong isolation, deny-by-default networking, immutable access lists, narrowly scoped credentials, an independent check at every tool call, and a kill switch running outside the agent's control. An agent doesn't need malicious intent. It needs enough access and one bad decision.

There is a human in the loop here, and that human is not a safety control. They're a quality rater with no mandate to escalate anything, which means the most serious material passes in front of a person who has been told their job is to judge whether the pixels look right. Everyone assumes the opposite. It's the same shape as the item above: the control exists, it runs exactly as designed, and it was never pointed at the thing you thought it was pointed at.

Two things for your organisation. The data protection question is obvious once you see it: the people whose faces appear are often not the user, have been told nothing, and blurring would be trivial. You can opt out of training, not out of a stranger looking. And the practical one: when staff put a document or a photo into a consumer AI tool, the question is no longer only whether it trains a model. It's whether a contractor in a country you never assessed will read it.

The check was real and it ran. It validated that a message was well formed and never asked where the message came from, which is the same failure pattern I wrote about last week in a payment signing process and an MFA token. And sit with the rest of it: hand-rolled RSA validation, inside the component whose entire purpose is to talk to hardware security tokens, in corporate banking. We protected the key in hardware and then exposed it through a browser extension.

Two practical notes. Browser extensions remain the blind spot in almost every asset register, and this is the worst version of that, because the extension is the thing enforcing strong authentication. Under DORA, SConnect is a critical third-party component sitting inside your authentication chain, and it is in nobody's register. Go and look at which signing or token extensions your finance team runs, and on which version.

Everything on the compliance side of this carries a date. The breach, the sanction, the injunction deadlines, the appeal ruling to come. The subscriber's side carries none. After a password breach you change the password and the exposure collapses in minutes. Here the file holds names, dates and places of birth, addresses and IBANs. A name does not change. An IBAN technically can, on request to your bank, but then you re-paper every direct debit, so almost nobody does. The half-life of that file is measured in years. That's the timeline to put in front of your board, not the fine.

And notice which failing came back around. The regulator sanctioned Free Mobile for keeping former subscribers' records it could not justify, and lawyers reading the decision found close to three million contracts terminated more than ten years earlier still sitting in the database. Coverage filed that away as an administrative footnote next to the real subject, security. It is the security subject. Deleted data cannot be exfiltrated, resold, or used to make a fake invoice credible. I've written the full thing up, link above.

The fundamentals are right. I've written them all year and I'll write them again. But look at what this issue just showed you and the question has moved. It isn't "do you have multifactor authentication". Last month it was enabled and not enforced. Last week it was satisfied without ever being performed. Having a control is now the easy half. Knowing it still works when somebody tests it is the half nobody budgets for.

So here's what I'd do with the attention you get this month. Instead of a poster, test one control. Plant a honeytoken in a file share and see whether an alert reaches a human. Run a content security policy in report-only mode for a week and read what is actually executing in your customers' browsers. Rehearse an eviction and check the attacker is really gone. And give Recover a real run, because it's the R almost nobody can demonstrate, and under NIS2 and DORA it stopped being optional.