TL;DR: A July 2025 campaign abused stolen OAuth tokens from Salesloft Drift integrations to access Salesforce and Google Workspace, then mine data for follow-on secrets, according to Oasis Security. The incident shows why token ownership, lifecycle control, and app-level monitoring matter more than user-centric controls when NHIs become the entry point.
At a glance
What this is: A Salesloft-linked OAuth compromise turned stolen app tokens into repeatable NHI access across SaaS platforms, with credential harvesting used to extend the blast radius.
Why it matters: IAM teams need to treat connected apps, tokens, and service identities as governed access paths, because user-focused controls can miss app-authenticated abuse across Salesforce, Google Workspace, and adjacent systems.
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps - 38% have no or low visibility, and a further 47% have only partial visibility.
👉 Read Oasis Security's analysis of the Salesloft OAuth compromise and NHI exposure
Context
OAuth token theft is an identity problem, not a platform defect. When a connected app is trusted to act as the user or service it represents, the token becomes the identity boundary, and any weakness in ownership, scope, or revocation becomes an access path.
The Salesloft-Drift compromise shows how NHI governance debt accumulates across SaaS integrations. A stolen app grant can be reused across multiple services, while cleanup in one plane does not automatically remove access in the others.
Key questions
Q: What breaks when a connected app token is stolen?
A: When a connected app token is stolen, the attacker authenticates as the app rather than as a person, so MFA and user login checks often never trigger. The result is app-level access to data and APIs that can look legitimate in logs. The right response is to revoke the token, trace dependent grants, and treat the token as the real identity boundary.
Q: Why do OAuth-connected NHIs create hidden blast radius?
A: OAuth-connected NHIs can reach multiple platforms through a single delegated trust relationship, so one compromised grant can expose data, secrets, and adjacent services. The hidden blast radius comes from scope drift, stale ownership, and weak dependency tracking. Teams should measure how many integrations can still operate after the original business owner leaves.
Q: How can security teams tell if token governance is failing?
A: Token governance is failing when grants remain active without clear owners, scopes no longer match business need, and revocation requires manual hunting across platforms. A strong signal is when cleanup in one console does not remove access in related SaaS or cloud services. That tells you the lifecycle model is fragmented.
Q: Who is accountable when a third-party integration is abused?
A: Accountability belongs to the business owner, the platform owner, and the identity team together, because connected apps sit across operational boundaries. If no one can state who approved the grant, who renews it, and who revokes it, the organisation has a governance gap. Ownership must be explicit before incidents happen.
Technical breakdown
How stolen OAuth tokens become app-level access
OAuth tokens are bearer credentials, which means possession is enough to authenticate as the app or delegated integration. In connected SaaS environments, that token can inherit broad read and write rights, often across multiple tenants or application surfaces. Once an attacker obtains the token, the activity often looks like legitimate app traffic, not a login anomaly. That is why human-centric controls such as MFA prompts do not fire and why attribution becomes fragmented across the app, the SaaS platform, and the identity provider.
Practical implication: inventory every connected app token, its scopes, and its revocation path before you need them during an incident.
Why credential harvesting extends the blast radius
The compromise described a credential-harvest loop, where exfiltrated CRM data was used to search for secrets that could power follow-on access. This is a common NHI failure mode because one app compromise becomes a discovery channel for other credentials hidden in records, exports, attachments, and logs. In practice, the attacker is not just stealing data. They are mining the data plane for reusable secrets, API keys, and tokens that open new systems.
Practical implication: search high-value exports and file stores for credential patterns, then treat any discovered secret as a live access path until proven otherwise.
Why multi-SaaS trust chains complicate containment
A connected app sitting between Salesforce, Google Workspace, and other integrations creates a trust chain that is only as strong as its least-governed link. Revoking access in one platform may leave downstream tokens, mirrored grants, or related sessions active elsewhere. That is why containment has to be identity-centric rather than platform-centric. The control plane must answer who owns the app, where the token lives, what it can reach, and which dependencies must be removed together.
Practical implication: build containment runbooks around identity relationships and dependency maps, not around a single vendor console.
Threat narrative
Attacker objective: The attacker objective was to turn a single stolen integration token into repeatable access, data theft, and downstream secret discovery across multiple SaaS environments.
- Entry occurred when the threat cluster abused stolen OAuth tokens from Salesloft Drift integrations to authenticate as the app inside customer environments.
- Escalation followed when the actor used that app-authenticated access to run bulk queries in Salesforce, then pivot into Google Workspace tied to the Drift Email application.
- Impact came through data exfiltration and credential mining, which expanded the blast radius into follow-on access opportunities across cloud and data platforms.
Breaches seen in the wild
- Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Ownerless connected apps are a governance failure, not a tooling gap. The breach worked because the integration token had enough authority to behave like a trusted identity, yet the governance model treated it as a configuration detail. Once ownership is unclear, revocation slows, scopes drift, and stale grants outlive business need. Practitioners should treat connected-app ownership as a control boundary, not an admin convenience.
Credential harvest loops are the modern NHI blast-radius amplifier. The attacker did not need to stop at the initial platform because CRM and collaboration data can contain the next secret, token, or API key. That turns exfiltration into a discovery mechanism for further access. The implication is that NHI governance must cover both direct access and the secondary credentials hidden inside business data.
Token governance debt is now a first-order security variable. OAuth grants age in place, scopes expand, and rotation often lags behind reality. This incident shows that a persistent grant can remain a live pathway long after the original business case has changed. Teams need to measure how many app credentials still outlive their intended lifecycle.
Identity-centric detection outperforms user-centric detection when the actor is an app. The compromise was API-driven, time-boxed, and fragmented across multiple services, which means human login analytics would see only a partial picture. NHI monitoring has to follow the token, the owner, the scope, and the dependent services together. Otherwise the security team is reconstructing the incident after the fact instead of containing it in motion.
Lifecycle governance is the missing control plane for SaaS integrations. Offboarding, ownership attestation, and scope review were designed to keep access aligned with business need, but many teams apply them inconsistently to service identities and connected apps. That leaves access surviving the relationship that justified it. Practitioners should treat lifecycle drift as an access exposure, not an audit finding.
From our research:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps - 38% have no or low visibility, and a further 47% have only partial visibility, according to The State of Non-Human Identity Security.
- In the same research, only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
- For a broader breach pattern view, The 52 NHI breaches Report shows how credential exposure and governance gaps repeatedly turn into cross-platform access.
What this signals
Token governance debt is now the control issue to watch. As SaaS ecosystems accumulate more delegated access, the gap is no longer whether teams can authenticate users. It is whether they can prove which app tokens still need to exist, who owns them, and which dependencies must be revoked together. That is a lifecycle problem first and a detection problem second.
Identity blast radius: the real risk is not the first token theft but the chain of secrets, exports, and adjacent grants that follow from it. In practice, that means security teams need a way to trace connected-app scope across collaboration and CRM systems before the next incident forces the inventory work. The 85% visibility gap documented in our NHI research shows why this is still hard at scale.
If your programme still treats connected apps as low-friction integration details, the next compromise will surface the same weakness in a different SaaS stack. The safer posture is to operationalise ownership, scope review, and dependency-aware revocation now, before the trust chain becomes the incident chain.
For practitioners
- Map every connected app to a named owner Build an authoritative inventory of Salesforce, Google Workspace, and similar integrations, then require a named human owner for each token, grant, and service identity. Revocation and escalation should fail closed when ownership is missing.
- Search for secrets inside business data Scan exports, files, messages, and records for API keys, refresh tokens, private key headers, and cloud credential markers. Treat any match as a live secret until it is revoked and reissued.
- Tie revocation to dependency maps Document which downstream apps, tenants, and service accounts rely on each connected grant so you can remove related access paths together. One revoked token is not enough if mirrored or adjacent grants remain active.
- Enforce lifecycle attestation for integrations Run recurring attestation on high-privilege connected apps, with explicit sign-off on scope, business purpose, and rotation status. If the business owner cannot justify the grant, it should be removed or reduced.
Key takeaways
- The Salesloft-Drift compromise shows that stolen OAuth tokens can function as high-value NHI credentials across multiple SaaS systems.
- The evidence points to a credential-harvest loop, where exfiltrated business data becomes a source of secrets for follow-on access.
- Connected-app ownership, lifecycle attestation, and dependency-aware revocation are the controls that would have reduced the blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Connected-app token abuse is a core NHI identity and authorization failure. |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and authentication controls must cover app identities, not just humans. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Least-privilege and continuous verification matter when a token can traverse multiple platforms. |
Apply least-privilege review to connected apps and enforce continuous monitoring on delegated access paths.
Key terms
- Connected App: A connected app is a third-party or internal application granted permission to access another platform through delegated identity. In NHI governance, it must be treated as a first-class identity with an owner, scope, lifecycle, and revocation path, not as a technical integration detail.
- OAuth Token: An OAuth token is a bearer credential that allows an application to act on behalf of a user or service within approved scopes. For non-human identities, the token itself becomes the access boundary, so theft, scope drift, and delayed revocation create direct operational risk.
- Credential Harvest Loop: A credential harvest loop is an attack pattern where stolen data is searched for secrets that can unlock additional systems. In NHI incidents, the first compromise often becomes a discovery channel for API keys, refresh tokens, and other reusable credentials that expand the blast radius.
- Identity Blast Radius: Identity blast radius is the total set of systems, data, and downstream access paths that become reachable when one identity is compromised. For connected apps and service identities, it depends on scope, hidden dependencies, and how quickly revocation propagates across platforms.
Deepen your knowledge
OAuth token governance and connected-app lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are managing SaaS integrations with opaque ownership or stale grants, it is worth exploring.
This post draws on content published by Oasis Security covering the Salesloft OAuth compromise: The Salesloft OAuth compromise: what it changed, and what to do next. Read the original.
Published by the NHIMG editorial team on 2026-05-27.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org