There is a specific kind of breach that has quietly become the dominant story of the last year, and it does not start with a zero-day or a phishing email landing in your inbox. It starts in someone else's environment. An attacker compromises a single SaaS vendor you connected to your CRM eighteen months ago, steals the OAuth tokens that vendor was issued, and then walks straight into your Salesforce instance wearing that vendor's trusted badge. No password prompt. No MFA challenge. The connection you authorized is the attack.
This is the SaaS-to-SaaS supply chain, and it is the part of the attack surface most security teams have the least visibility into. You can inventory your own endpoints. You can patch your own code. But the long-lived token sitting in a third party's database, granting that third party read access to every record in your CRM, is invisible to almost every tool you own. When that third party gets popped, the blast radius is your data.
What Actually Happened: Two Breaches, One Playbook
The pattern is not theoretical. Two recent incidents made it concrete, and they ran almost the same play.
The first was the Salesloft Drift breach, disclosed in late August 2025. According to Google's Threat Intelligence Group, a threat actor tracked as UNC6395 compromised tokens associated with the Salesloft Drift application and used them to systematically export data from Salesforce instances across more than 700 organizations between roughly August 8 and August 18, 2025. Reporting indicates the attackers first gained a foothold in Salesloft's GitHub environment earlier in 2025, pivoted into the Drift AWS environment, and harvested the OAuth tokens tied to customer integrations. Salesloft and Salesforce responded on August 20 by revoking all active Drift access and refresh tokens, and Salesforce pulled the Drift app from AppExchange pending investigation. Named victims that publicly confirmed exposure included Cloudflare, Palo Alto Networks, Proofpoint, PagerDuty, Tanium, and Zscaler.
The second was the Klue breach, identified on June 12, 2026. Klue is a competitive-intelligence platform, and its integration reached into a long list of connected systems. Per reporting from CSO Online, the affected platforms included Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive, and Slack. The attacker reportedly accessed a compromised legacy credential tied to an integration service account that Klue had created to prototype an integration and never deactivated, then used that access to push unauthorized code that harvested the OAuth tokens customers used to connect Klue to those third-party platforms. From there they generated OAuth tokens and ran automated Python scripts against the Salesforce REST API for about 24 hours, according to ReliaQuest's analysis. Salesforce disabled the Klue Battlecards integration and blocked reconnection until further notice. Huntress and Recorded Future were named among the affected customers, alongside an undisclosed number of others.
Read those two paragraphs again and notice what is missing. Nobody phished your users. Nobody brute-forced your login. The attacker never touched your authentication at all. They borrowed a relationship you had already approved.
Why OAuth Grants Are Such a Clean Target
OAuth was designed to be convenient, and that convenience is exactly the problem. When you connect a SaaS app to Salesforce, you grant it a token, and that token tends to have three uncomfortable properties.
First, it is long-lived. Refresh tokens are built to survive so the integration keeps working without re-prompting a human. That is great for uptime and terrible for containment, because a stolen refresh token can mint new access tokens for as long as nobody revokes it. The Klue scripts reportedly ran for roughly a day, but the tokens themselves had been valid far longer.
Second, the scope is usually far broader than the job requires. A chatbot or a competitive-intelligence tool rarely needs full read access to every object in your CRM, yet that is frequently what the default grant requests, and what an administrator clicks through. The token does not know the difference between the records the integration actually uses and the ones it merely can reach. The attacker does, and they query all of it.
Third, the token bypasses your front-door controls. MFA, conditional access, IP allowlisting, and session policies generally apply to interactive logins. A valid OAuth token is a machine identity authenticating through an API, and in the Drift campaign the use of those tokens reportedly bypassed MFA and user-level controls entirely. Your strongest authentication investments simply do not sit in this path.
Put those three together and you have the ideal credential: durable, over-permissioned, and exempt from the defenses you are proudest of. An attacker who steals it does not need to escalate. They already have what they came for.
The Economics That Make This Worse Every Year
There is a brutal multiplier at the center of this trend. Compromising 700 companies one at a time is hard, slow work. Compromising one SaaS vendor that holds tokens for 700 companies is a single operation with a 700x payoff. The supply chain inverts the attacker's cost curve, and they have noticed.
It also changes who the victims are. Both campaigns disproportionately hit technology, SaaS, and security vendors, which is not a coincidence. Those organizations connect the most third-party tools and hold the most valuable secondary data: API keys, tokens, and credentials sitting inside CRM notes and support tickets. The Drift attackers reportedly searched the exfiltrated data specifically for embedded secrets they could use to pivot further. The CRM dump is not the end of the attack. It is the next set of keys.
And the data itself is the extortion lever. You do not need ransomware to encrypt anything when you have quietly exported every customer record, deal note, and support transcript. Data extortion built on top of a trusted integration is cleaner, quieter, and harder to attribute than dropping a payload on an endpoint.
What Governing This Actually Looks Like
The uncomfortable truth is that you cannot patch your way out of a vendor's breach. What you can do is shrink the blast radius before it happens and detect the abuse while it is in progress. A few things genuinely move the needle.
Inventory every OAuth grant, including the ones you forgot. Most organizations cannot produce a current list of which third-party apps hold tokens into their Salesforce, Google Workspace, and Microsoft 365 tenants. That inventory is the foundation; you cannot govern what you cannot see. Treat every connected app as a vendor with standing access, because that is exactly what it is.
Scope tokens down and kill the dormant ones. If an integration only needs a handful of objects, do not grant it the whole CRM. Audit grants for the difference between what an app uses and what it can reach, and revoke tokens for apps nobody has touched in months. A token that is not issued cannot be stolen.
Monitor authorization behavior, not just logins. The Klue activity looked like a service account running API queries, because that is what it was. The tell was the volume and pattern: automated REST calls pulling records far faster and broader than the integration's normal behavior. Anomalous query rate, new IP ranges, and sudden bulk exports through a legitimate token are the signals worth alerting on. Treat your connected SaaS apps as part of your third-party risk program, with the same scrutiny, scorecards, and offboarding discipline you apply to any vendor handling your data.
How Safeguard Helps
Safeguard treats every connected SaaS app and OAuth grant as a supply-chain component with provenance, not an invisible convenience. Our vendor policy registry and vendor scorecards bring third-party integrations into the same TPRM workflow as your code dependencies, so over-scoped tokens, dormant grants, and unreviewed app authorizations surface as policy-gate failures before they become someone else's incident. Our Multi-Agent TAOR Deep Think engine runs verification above the model layer, correlating anomalous authorization behavior with vendor risk so you act on verified findings instead of drowning in alerts, and the platform is model-agnostic so your existing detections plug in as components. If your CRM, collaboration, and AI tools are wired together through tokens nobody is watching, reach out and we will map your third-party grant exposure with you.