In 2025, attackers tracked as UNC6395 obtained OAuth tokens associated with the Salesloft Drift integration and used them to reach into the Salesforce environments of a large number of downstream organizations, exfiltrating data at scale. The painful detail is the arithmetic: the attackers did not have to breach hundreds of companies individually. They compromised one connected application’s credentials and inherited the access that hundreds of customers had already granted it.
This is the structural problem with OAuth-connected integrations, and it is not specific to any one vendor. When you authorize a SaaS app to read your CRM, your code, or your inbox, you are issuing a long-lived, broadly scoped grant to an identity you do not operate and cannot fully observe. That grant is a non-human identity living inside your tenant — and its security is now partly someone else’s problem.
Why connected-app grants concentrate risk
Three properties make these grants dangerous in combination. They are standing: they persist until explicitly revoked, often for years. They are broad: integrations frequently request more scope than they strictly need, and customers approve it once and forget. And they are concentrated: a single popular integration holds equivalent grants across many tenants, which makes it a high-value, single point of failure for an attacker.
The consequence is that the blast radius of one stolen integration token is not one company — it is the union of everyone who connected that app. You can do everything right inside your own walls and still be exposed through a grant you issued in good faith to a third party whose breach you will learn about from the news.
The attackers did not breach hundreds of companies. They compromised one app’s credentials and inherited the access hundreds had already granted it.
Map the reach before the breach
You cannot reason about a risk you cannot see. The defensive move that actually helps is unglamorous: enumerate every connected application in your estate, resolve the scopes each one holds, and translate those scopes into concrete reach — which data stores, which records, which capabilities each integration could touch if its token were stolen tomorrow. Then rank by that reach, not by vendor reputation.
This is exactly the kind of mapping TrustFix is built to produce: every connected-app identity discovered, its scope made legible, and its potential blast radius quantified before anything goes wrong. With that map in hand, the over-scoped integration nobody remembers approving stops being an invisible liability and becomes a decision: keep it, narrow it, or remove it.
The limit we will not paper over
Here is what mapping cannot do, and we will say it plainly: it cannot stop the upstream vendor from being compromised. If a SaaS provider is breached and its tokens are stolen, no inventory of yours prevents that event. The provider’s security is genuinely outside your control, and any tool that implies otherwise is selling you comfort, not safety.
What visibility changes is everything downstream of that event. When the news breaks, the organizations that pre-mapped their integrations already know which grants are affected, exactly what those grants could reach, and which to revoke first — in minutes, not days. The ones that did not are starting their investigation by asking which apps they even had connected. The breach is the vendor’s. The blast radius is yours to have measured in advance.
A short checklist
Inventory every OAuth-connected app across your SaaS and cloud estate, including the ones approved by individual users rather than central IT. Record the scopes each holds and the owner responsible for each. Translate scopes into reach so you can rank integrations by blast radius rather than by name. Set an expectation that high-reach grants are reviewed and re-justified on a schedule. And keep a current map, so that when the next connected-app compromise is disclosed, your first response is action rather than discovery.