When the Klue breach surfaced this month, the detail that should stop every security leader cold wasn’t the attacker’s sophistication. It was the victim list.
Market-intelligence vendor Klue disclosed in mid-June that an attacker had reached its integration backend through a single dormant legacy credential, then harvested the OAuth tokens its customers used to connect Klue to their own systems — Salesforce first among them. A new extortion crew calling itself Icarus claimed it. And the organizations that have since confirmed they lost Salesforce data read like a who’s-who of the security industry itself: Huntress, Recorded Future, Tanium, Jamf, Sprout Social, Gong, and Insurity, among others — with more names surfacing as disclosures continue.
Sit with that. Companies whose entire business is helping others detect and respond to threats had data walk out of their Salesforce instances — not because their platforms were breached, but because of a tool they connected to it. If the firms that do this for a living can’t see a token being abused inside a vendor they don’t operate, that should reframe how the rest of us think about the problem.
The real question
The instinct, when a story like this lands, is to ask whether the perimeter still holds. That’s the wrong question, and it has been for a while.
The perimeter didn’t fall. What changed is that the number of trust relationships running through a modern enterprise has exploded — and our ability to govern them hasn’t kept pace. The average mid-market company now runs north of 200 SaaS applications, most of them wired to each other through OAuth grants that no one inventories, scopes down, or expires. Every one of those grants is a standing authorization: a key handed to an application, on behalf of your data, that keeps working long after anyone remembers issuing it.
So the real question isn’t “is my perimeter secure.” It’s this:
Do I have visibility into — and governance over — the trust I’ve already extended?
For most organizations, the honest answer is no — and that gap is exactly what Klue exploited downstream.
We’ve handed non-human identities — apps and AI agents — the keys, with only limited controls, and placed them between our people and our most critical assets. A data fabric is what lets you understand what they’re doing, and how.
Why a stolen token beats your MFA
Here’s the mechanic worth internalizing, because it explains why this class of attack is so quiet and so effective.
When an attacker steals an OAuth token, they aren’t logging in. They’re replaying an authorization that was already granted. Practically, what gets stolen is usually a refresh token — the long-lived artifact an integration uses to silently mint new short-lived access tokens. With it, the attacker connects straight to the target system and pulls data out in bulk — in the Salesforce cases, exporting whole tables of accounts, opportunities, and support cases at once. To the identity provider and the SaaS app, this is the same trusted integration doing the same thing it does every day. Multi-factor authentication never enters the transaction, because MFA happens at the moment of interactive login — and this isn’t a login. The token already exists, and connected-app traffic typically isn’t subject to the same conditional-access policies as a user session.
These grants are also durable in ways that defy normal incident response. A stolen refresh token generally survives a password reset. It survives the user changing their credentials entirely. In many configurations the only thing that closes the door is explicit revocation of the grant (or the connected app), or a policy that forces re-consent. Which means an organization can do everything its playbook says — reset passwords, rotate credentials, force re-authentication — and the attacker keeps their access, because none of those actions touch the artifact actually being abused. Worse, the abuse hides in the noise: a malicious export looks structurally like a legitimate sync, just larger, and most teams have no baseline for what “normal” volume on a given integration even is.
The uncomfortable truth of the OAuth mesh is that we grant standing permissions to software, hand them out broadly, watch them rarely, and revoke them almost never.
This is a pattern, not an incident
Klue is the freshest example, but it is not the first, and treating it as a one-off is the mistake.
In 2025, attackers compromised OAuth tokens tied to Salesloft’s Drift integration and used them to reach into the Salesforce environments of more than 700 organizations — among them some of the largest names in technology and security. The method was identical in spirit: don’t break the front door, steal the key that a trusted third party was already holding, and walk through hundreds of back doors at once. And the operators knew exactly what they were after — beyond CRM records, the queries deliberately hunted embedded secrets in those records: AWS keys, Snowflake tokens, and other credentials that turn a single SaaS theft into the seed of the next intrusion.
The access side is industrializing too. Consent-phishing kits sold as a service have begun tricking users into approving malicious OAuth applications outright — one such operation reportedly compromised hundreds of Microsoft 365 organizations within weeks of going live, and the grants it planted reportedly persisted through password resets for weeks (per incident reporting from The Hacker News and Mitiga). Industry trackers have followed OAuth consent abuse across hundreds of tenants and thousands of accounts. The through-line across all of it: the attacker’s goal is no longer your password. It’s your grant.
This is why the numbers have moved. In the 2026 Verizon Data Breach Investigations Report, third-party involvement climbed to roughly 48% of breaches — up from 30% a year earlier, a figure that had itself doubled from the year before. And the report ties much of that exposure back to basic identity failures: missing MFA, weak credential rotation, and absent least-privilege enforcement. The connective tissue between systems has become the most efficient place for an adversary to stand.
What the market is already telling us
If you want confirmation that this is a structural shift and not a news cycle, look at where the security market is putting its money. Spending on SaaS security posture management — the discipline of finding and fixing exactly this kind of exposure — is on a steep climb, with analysts sizing the category in the low billions today and projecting it to roughly triple over the next several years. A cohort of vendors has organized specifically around the problem, and tellingly, at least one has built its differentiation explicitly on SaaS-to-SaaS supply-chain risk — the Klue-shaped threat. When a buyer category forms around a single failure mode, that failure mode has stopped being an edge case.
The convergence is just as visible on the detection side. Identity threat detection and response has moved from a niche to a checkbox on the enterprise security roadmap, and the platform players are racing to claim it: the leading endpoint and identity vendors now market OAuth-attack detection across SaaS estates and are extending coverage to non-human and machine identities, while the major SIEM platforms ship more identity and SaaS connectors with each release. That’s healthy — but it also creates the trap every CISO knows well. The instinct will be to buy another point tool for SaaS, another for identity, another for non-human identities, and end up with three more consoles and no more clarity. The disjointed-tooling tax is real, and it is precisely what an attacker exploiting the seams between systems is counting on.
For buyers and boards, the real question isn’t “which OAuth-security product do we add,” but “where does the correlated picture live?” That splits cleanly into two halves — governing the grants, and watching them — which is where any serious program starts.
What to do about it: govern the connections, and watch them
If the problem is trust we’ve handed out and stopped tracking, the answer isn’t another wall. It’s giving every software connection the same scrutiny we already give human users — the work the market calls SaaS posture management and identity threat detection. It comes in two halves.
Govern them: treat every connection like a user account. Most companies can’t even produce a list of which outside apps currently hold keys into their most important systems. Building that list is step one. From there:
- Inventory every connected app and OAuth grant from each major SaaS and identity provider — Salesforce Connected Apps and OAuth usage, Microsoft Entra and Google Workspace app-consent and token logs.
- Assign an owner to each grant — a named person accountable for why it exists.
- Scope to least privilege, and gate high-risk scopes behind admin approval so users can’t self-consent.
- Expire and review on a cadence, and aggressively revoke grants that have gone dormant.
Watch them: connect the dots across your systems. Governance is a snapshot, and attackers work in the gaps between snapshots. A stolen token looks legitimate by design, so you won’t catch it from any single login or device — you catch it by piecing together signals from the logs that hold the evidence:
- Pull the right logs — Salesforce Event Monitoring, Entra ID sign-in and audit logs, Google Workspace admin logs, and network flows.
- Baseline each integration — know its normal source, volume, and cadence, so “abnormal” means something.
- Alert on what matters — a connected app calling from a new network or geography; an export far above its trailing baseline; a dormant grant springing back to life; a refresh token minting access tokens at an abnormal rate.
- Automate the response — revoke the grant, kill the session, page the owner.
Take one concrete example:
No single signal is conclusive on its own — each will misfire on a legitimate data migration or a new sync. But stacked across your identity, SaaS, and network data, they become a pattern a person or a model can act on.
Who owns this matters as much as what gets done: CISOs own setting the policy, identity and SaaS owners own the inventory and review, and detection engineers own the cross-log correlation and the automated responses.
That is where the architecture matters more than any single product — and where the market’s “just buy a tool” reflex falls short. The signals about OAuth abuse don’t live in one place. They’re scattered across identity providers, SaaS audit logs, and network flows that have historically been owned by different teams and different tools, often with inconsistent retention and no common schema. Normalizing them and pulling them into a common analytical layer — the direction the industry now describes as a security data fabric, and the thinking behind moves like Cisco’s data-fabric strategy — is what turns three inconclusive signals into one actionable detection. The point isn’t the brand of the fabric. It’s that you cannot correlate what you cannot see together, and token abuse is invisible to anyone watching only one layer.
Where this goes next
The reason to get ahead of this now is that the trust surface is about to expand again, faster.
Every AI agent or assistant an enterprise adopts is another non-human identity, granted its own permissions, holding its own keys, acting on its own — and often set up by developers outside the normal identity-governance process. Machine and non-human identities already outnumber human ones in most enterprises by a wide margin — industry estimates range from roughly 45-to-1 to north of 100-to-1 — and the agentic-AI wave only steepens that curve. We are about to issue more standing authorizations in the next two years than in the last ten — and the Klue and Salesloft playbook works just as well against an agent’s token as a human’s. That shift is already rewriting how the SOC operates. The discipline is the same as everywhere else in this piece: treat every new AI agent or assistant as a high-value account in its own right — it needs an owner, least-privilege access, an expiration date, and monitoring. The organizations that will weather this are the ones that start now: building the inventory, governing the grants, and standing up the cross-source visibility to see a trusted connection behaving untrustably.
The lesson of the Klue victim list isn’t that the defenders failed. It’s that no one is exempt from a risk they can’t see. The trust we’ve extended into the SaaS mesh is real, useful, and here to stay. The work — overdue, and squarely within reach — is to govern it like we mean it, and to build the visibility to watch it the way we already watch everything we think of as our own.
Sources
- Klue / Icarus OAuth breach and victim list — BleepingComputer, Help Net Security, Recorded Future
- OAuth token abuse, MFA bypass, refresh-token persistence, consent phishing — The Hacker News, Obsidian Security, nhimg.org
- Salesloft Drift / Salesforce — 700+ orgs, secret-hunting in exports — Mitiga, FINRA
- Third-party breach involvement (~48%, 2026) and identity root causes — Verizon 2026 DBIR, SpyCloud DBIR takeaways
- 200+ SaaS apps, SSPM discipline and market growth — Nudge Security, Reco AI, Kings Research
- ITDR convergence and SaaS/NHI detection coverage — CrowdStrike ITDR, Microsoft Sentinel connectors (RSAC 2026)
- Non-human identities outnumber human identities — The Hacker News / NHI, CSO Online
- Security data fabric / Cisco Identity Intelligence + Splunk — Cisco Duo, Splunk Lantern
