The detail that matters in this week's Klue breach is the one that is easy to skim past: the two cybersecurity firms named as victims were never actually broken into. No attacker touched a Huntress server. No attacker touched a Recorded Future server. The data still walked out of the door, because both firms had handed a third party standing access to their customer records, and that third party was the one that got compromised. If you want a single, clean example of why I keep banging on about digital sovereignty, this is it. You can run an immaculate shop and still be robbed through a key you cut for someone else.

What actually happened

Klue is a competitive-intelligence platform — the sort of software a sales team uses to build battlecards on rivals. It is not a security product. It is a convenience, bolted onto the side of the revenue function, and a great many companies, including a notable number of cybersecurity firms, plugged it into their core systems.

On 11 June, according to SecurityWeek's reporting, attackers reached Klue's backend servers, ran unauthorised commands, and pushed a code update whose job was to harvest the OAuth tokens Klue held for its customers' integrations. Those tokens are the crux of the whole story, so it is worth being precise about what they are. When you connect a SaaS tool like Klue to your Salesforce, you do not hand over a password. You grant an OAuth token — a long-lived key that lets Klue act against your Salesforce on your behalf, without a human and without re-authenticating. Steal the keyring, and you can drive the customer's systems as if you were the trusted application.

That is exactly what followed. Klue notified customers on 12 June and deactivated OAuth tokens, having disabled integrations with Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive and Slack — a list that, read on its own, is a fair map of where a modern company keeps its commercial life. Using the stolen tokens, the attackers turned to the Salesforce REST API and pulled CRM data at industrial speed. The incident responders at ReliaQuest describe a 24-hour exfiltration window including a concentrated burst of nearly a thousand API queries in fifteen minutes and sustained extraction runs of over six hours. On 17 June, Salesforce itself disabled the Klue Battlecards app, citing unusual activity that may have exposed a subset of customer data through the app's connection.

To their credit — and I mean that — both named victims were straight about it. Huntress published that the copied data was business contacts, price quotes and sales messaging, and was clear that no threat data, passwords, payment details or agent engineering data were touched. Recorded Future said the impact appeared limited to business data fields in its Salesforce — client contact names, email addresses, possibly some contract information. Both stressed that the attackers never reached their own systems. That transparency is the right behaviour and it deserves saying. But notice what it concedes: the firms did everything right on their own estate, and it did not matter, because the breach happened one hop away on infrastructure they did not run and could not see.

This is not a freak event, either. The same shape — compromise a connected SaaS vendor, steal the OAuth trust, drain Salesforce through the API — has now played out repeatedly, through the Salesloft Drift and Gainsight incidents earlier this cycle, attributed variously to ShinyHunters and UNC6395. Klue appears to be a new crew — Huntress links it to an extortion group calling itself Icarus that surfaced in April 2026 — but the playbook is identical. When a technique works this reliably against this many targets, it is no longer a series of accidents. It is the market telling you where the soft tissue is.

The trust you cannot audit

Here is the part I want boards and fellow practitioners to sit with. Every SaaS integration you authorise is a standing grant of trust to a company whose security is now indistinguishable from your own — except that you cannot see it, cannot test it, and do not control when it fails. The OAuth token is a key to your data that lives on someone else's keyring, in a building you have never visited, protected by controls you took on faith during a procurement call. You did your due diligence on the vendor. You almost certainly did not do due diligence on the vendor's vendors, or on the engineer whose laptop could push a code update to the backend that holds your token.

When that token is for your CRM, the stakes are not abstract. A security company's CRM is a directory of exactly the organisations that most need defending, annotated with who to call, what they pay, and what they worry about. That is a target-rich document by construction. And it was reachable, this week, from a battlecards tool. The asymmetry is the whole point: a sales-enablement nicety was given standing access to one of the most sensitive datasets the business holds, and the convenience was never weighed honestly against the exposure it created.

This is the argument for digital sovereignty made concrete, and I want to be careful about what I mean by it, because it is easy to caricature as paranoia or as a demand that everyone self-host their email and suffer. It is neither. Sovereignty is not about abstinence from other people's software; it is about knowing and controlling your dependencies rather than accumulating them by default. It is the discipline of being able to describe your stack end-to-end — whose systems hold your data, whose tokens can reach it, what each one can do, and how fast you can sever any of them — and of refusing to hand out standing access simply because an integration was one click away in a settings page. Software security without that ownership is, to borrow my own phrase, decoration on someone else's house.

What I would actually do

The honest response to Klue is not "ban SaaS", which is neither possible nor what I am arguing. It is to make standing third-party access the exception you have to justify, rather than the default you accumulate. In practice that means a few unglamorous things.

Inventory every OAuth grant against your core systems and treat each one as part of your attack surface, because it is. For most organisations this list is longer than anyone expects and nobody owns. Scope every token to the least it needs — read-only where read-only will do, a narrow set of objects rather than the whole CRM — and prefer short-lived, refreshable credentials over the long-lived tokens that made this attack a 24-hour smash-and-grab rather than a fifteen-minute one. Minimise what the SaaS can even reach: a battlecards tool does not need your full contract and contact history, and the data you never expose is the data that cannot be exfiltrated through someone else's breach. Build the muscle to revoke fast and rehearse it, because Klue's customers were ultimately saved time by Klue and Salesforce killing the tokens, not by anything the customers could do themselves. Extend due diligence to fourth parties — ask a vendor not just how they secure themselves but who can push code to the systems holding your keys. And for the genuinely sensitive — the data whose loss is existential rather than embarrassing — accept that the sovereign answer is to keep it on infrastructure you run, and to stop pretending that a tick-box SOC 2 report is the same thing as control.

The mirror

There is an uncomfortable reflection in this story for an industry that sells trust for a living. Firms whose entire proposition is "let us defend you" were exposed through a sales tool they themselves chose to trust. None of them was careless in the ordinary sense. They were simply operating the way everyone now operates — composing the business out of dozens of other people's services and assuming, because the alternative is inconvenient, that each one is as careful as they are. The Klue attackers did not need a zero-day or a clever exploit. They needed the industry's standing habit of trusting by default.

So the question to take away is not whether Klue failed; vendors will always, eventually, fail. The question is why your most sensitive data was reachable from Klue at all — and how many other tools, right now, hold a key to it that you have never gone looking for.