Edition 13

Two things are true at once, and you have to hold both. First, the warning is real and correct: AI-enabled attacks are coming, they will hit critical infrastructure, and a coordinated public-private response is genuinely the right call. After the summer we have had, an industry that spent two years downplaying this finally saying it out loud is progress. Second, read the signatory list with clear eyes. The companies building the most attack-capable models are the same ones selling you the defence, and this letter doubles as a coordinated launch announcement for Daybreak, Mythos and Perception.

So take the signal, keep your wallet closed for a beat. The systemic warning does not obligate you to buy anyone's new AI-defence platform, and it certainly does not replace the fundamentals I keep hammering. The right response to "AI attacks are coming" is not a shiny new AI product bolted onto a shaky foundation, it is finishing the boring work underneath, the same work that would have stopped most of the summer's incidents. Buy the defensive tooling if it earns its place. Do not let a well-timed open letter make that call for you.

This is the whole AI-security argument in one weekend project, and it is worth more than the coalition letter above it. Not because it is sophisticated, but because it is trivial. A guy, mildly irritated at his monitor, pointed a commercial AI at the closed firmware of everyday gadgets and owned all of them. The barrier that used to protect obscure hardware, that reverse-engineering it was slow, specialised, expensive work, is exactly the barrier AI just removed. That is the real story of this era: not new magic, but the collapse of the cost of competence.

For your threat model, two takeaways. One, every peripheral is a small, connected, barely-protected computer, and your asset inventory almost certainly does not include the webcam, the monitor or the meeting-room devices that can be reflashed to persist below the operating system. Two, this is why the browser-permission prompts matter, WebUSB, WebHID and WebBluetooth mean a malicious website can reach that hardware if a user clicks allow. If your supply-chain and endpoint programmes stop at laptops and servers, they stop too early.

Sit with the 86 percent, because it is the number that should reorganise your priorities. Most organisations cannot see what their people are sending to AI, which means most AI governance policies are documents describing a reality nobody is actually measuring. This is the shadow-AI and shady-AI problem from a few weeks back, now with telemetry: banning tools does not work, it just pushes usage onto personal accounts where you have zero visibility. The only thing that works is a sanctioned, monitored path that is easier to use than the shadow one.

But do not miss the part that is genuinely new, because it is where next year's incidents live. The centre of gravity has moved from employees pasting text into a chatbot to agents wired directly into your systems through MCP, and Netskope is watching that traffic quadruple. That is a different risk: not what a human types, but what an autonomous agent is authorised to reach, and a fourfold jump in connective tissue between your data and external models is a fourfold jump in blast radius. If your AI governance still assumes the risk is a copy-paste into ChatGPT, you are governing last year's problem.

I have had prospects raise this in the last week, so let me be direct about why the usual framing is wrong. Quantum is not correctly filed as a future problem, and the reason is not the hardware timeline, which nobody can pin down. It is harvest now, decrypt later. The moment your encrypted data is captured, the clock starts, and the decryption simply happens later. So the honest question is not "when will quantum arrive," it is "how long does my data need to stay secret, and is that longer than the time until someone can break the crypto protecting it." For most regulated data, contracts, health records, trade secrets, the answer is already yes. Which means it is already exposed.

And this compounds everything else in this newsletter. Every breach I have covered where "only encrypted data" was taken is a deposit in someone's vault, waiting. Crypto that was already weak, misconfigured TLS, ancient key sizes, homegrown schemes, does not need a quantum computer to worry about, it needs one now and a quantum computer later. The first move is not panic or a rip-and-replace, it is a cryptographic inventory: know where you use cryptography, which algorithms, which key sizes, in which systems, including the ones your suppliers run. You cannot migrate what you cannot see, and the EU wants that inventory done by the end of this year. This is a 2026 project wearing a 2032 costume.

This is the balance I want you to actually think through, because both extremes are sold as best practice and both are traps. Fragmentation is real: fifty disconnected tools, five dashboards and three teams working to three timelines is how a contained incident becomes a 276-day breach. So consolidation is genuinely good hygiene. But run it too far and you arrive exactly where DORA and NIS2 tell you not to be: concentration risk, your entire security posture resting on one provider that is now a single point of failure and a single, juicy target. DORA names this explicitly, over-reliance on a critical ICT third party is a risk you are required to manage, not an efficiency to maximise.

So the answer is not a slogan, it is a judgement, and it is yours to defend. Consolidate for integration and visibility, the things fragmentation destroys, but keep deliberate independence at the points where a single supplier's bad day would take you down with it. Map your critical dependencies, ask which of your providers you genuinely could not survive losing, and make sure the answer is not all of them and not just one. That is the real work behind vendor strategy, and it is exactly the muscle NIS2 and DORA are trying to build. Neither one throat to choke nor best-of-breed everything is a strategy. The balance is.