TL;DR: Compromised OAuth tokens in Salesloft Drift gave attackers unauthorized access to connected apps, including Salesforce, and reports said they searched those environments for embedded secrets and credentials, according to Cyera. The incident shows that integration trust, not just login security, now defines the real blast radius for NHI governance.
At a glance
What this is: This analysis shows how compromised OAuth tokens in Salesloft Drift expanded attacker access into connected SaaS applications and turned embedded secrets into downstream exposure.
Why it matters: It matters because IAM and security teams must govern integrations, token scope, and hidden credentials across NHI, autonomous, and human-accessed SaaS workflows.
👉 Read Cyera's analysis of the Salesloft Drift OAuth token exposure
Context
OAuth tokens are designed to let applications exchange access without repeated prompts, but that convenience becomes a governance problem when the token itself is the trust boundary. In this incident, compromised Salesloft Drift tokens opened paths into connected SaaS systems and exposed how integration trust can outrun identity controls.
For IAM and NHI programmes, the issue is not only who signs in. It is also which third-party apps can move data, where secrets are stored inside business records, and how much access an integration inherits once it is connected. That makes SaaS integration governance part of identity security, not a separate data problem.
Key questions
Q: What breaks when OAuth tokens are compromised in connected SaaS environments?
A: When OAuth tokens are compromised, attackers can inherit delegated access without defeating passwords or MFA. In connected SaaS environments, that access can spread into multiple applications, cached data sets, and embedded records. The failure is not only token theft, but the assumption that one app boundary contains the blast radius. That assumption rarely holds once integrations are chained.
Q: Why do third-party integrations increase the risk of secret exposure?
A: Third-party integrations increase risk because they often move data across systems that were never designed as credential stores. If API keys, tokens, or passwords are embedded inside application records, attackers can discover and reuse them through normal app access. The result is a data governance problem that becomes an identity problem the moment secrets can be replayed elsewhere.
Q: How should security teams reduce blast radius in SaaS integration chains?
A: Security teams should reduce blast radius by scoping every integration tightly, removing unused apps, and mapping where sensitive data flows after the initial connection. They also need to know which records contain secrets so a compromise can be contained quickly. Visibility across entitlements and data paths is what makes response targeted instead of broad and slow.
Q: Who is accountable when a third-party SaaS integration exposes customer data?
A: Accountability usually remains with the organisation that granted the access, even when the technical failure originates in a third-party integration. Governance teams must own recertification, offboarding, and scope review for connected apps, because the business retains the risk of exposed data and reused credentials. Frameworks such as NIST CSF and zero-trust governance both assume that delegated access is continuously managed.
Technical breakdown
OAuth token abuse across connected SaaS apps
OAuth tokens are delegated credentials that let one application act on behalf of a user or service without sharing the underlying password. When attackers obtain a token, they inherit whatever scope the token carries until it expires or is revoked. In chained SaaS environments, that scope can extend far beyond the original application because connected systems often trust the token as proof of legitimacy. The practical problem is not only token theft, but the way integration sprawl turns one compromised credential into multiple trusted sessions across business applications.
Practical implication: teams need full inventory and scoping of OAuth-connected apps, not just password and MFA controls.
Secrets hidden inside business records
Attackers do not always need to break encryption or defeat authentication if credentials already live inside application data. In this case, reports indicated they were searching for API keys, tokens, and other secrets embedded in Salesforce objects or customer records. That creates a data layer failure, where sensitive credentials become discoverable through normal application access. Once secrets are stored in records, notes, or attachments, the application becomes both a business system and a credential repository. That dual use is often invisible to traditional IAM tools.
Practical implication: remove secrets from SaaS records and scan application data for credentials as part of routine posture management.
Why blast radius grows faster than remediation
Connected SaaS environments amplify compromise because each integration can become a new trust path before the initial incident is even contained. If one platform is compromised, downstream applications may inherit access, cached data, or exposed secrets that attackers can reuse elsewhere. This is why identity controls alone are insufficient: they may validate the token, while missing where the data and secrets have propagated. The underlying architecture problem is the gap between access entitlement and data visibility across third-party integrations.
Practical implication: map integration data flows alongside entitlements so containment starts with visibility into what each app can reach.
Threat narrative
Attacker objective: The attacker objective was to turn delegated SaaS access into reusable secrets and broader downstream access across connected enterprise applications.
- Entry occurred when attackers abused compromised OAuth tokens tied to Salesloft Drift, giving them unauthorized access into trusted connected environments.
- Escalation followed as the token-derived access extended into linked SaaS platforms such as Salesforce, Google Workspace, and Outlook, widening the attacker's reach without new logins.
- Impact came from the search for embedded secrets and credentials, which could be reused to unlock further systems and expand the blast radius across customer environments.
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
Integration trust is now an identity governance boundary, not a convenience layer. OAuth tokens were designed for delegated access, but this incident shows that the real risk sits in the trust relationship between applications. Once tokens can move across connected SaaS systems, identity governance has to account for where access can travel, not just where it was granted. Practitioners should treat integrations as first-class identity subjects in governance reviews.
Hidden secrets inside SaaS records create a data-driven credential lifecycle failure. The breach worked because credentials and API keys could be discovered inside application data that was never meant to serve as a secrets store. That is not just poor hygiene, it is a lifecycle control gap where secrets outlive their intended location and become reusable attack material. The implication is that credential governance must include data scanning, not only rotation and revocation.
Blast-radius control is becoming the core measure of SaaS identity maturity. The more apps are chained together, the less meaningful a single app-by-app trust model becomes. A compromise in one integration can extend into multiple systems before teams understand where the sensitive data sits. Practitioners should judge identity programmes by how quickly they can localise trust, data, and access paths after a third-party failure.
Third-party app access needs the same lifecycle discipline as privileged internal access. The problem is not simply that vendors connect to SaaS platforms, but that those connections often persist longer than the business justification that created them. Once a third-party integration is live, it can keep access and cached data even when the original use case has changed. Security teams should treat offboarding, recertification, and scope reduction as continuous controls for integrations, not one-time setup tasks.
From our research:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, leaving integration governance materially incomplete.
- This broader visibility gap is why Guide to the Secret Sprawl Challenge matters for teams trying to remove secrets from SaaS records before they become reusable credentials.
What this signals
Integration sprawl is becoming a measurable governance gap, not a theoretical one. With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the problem is not whether integrations exist but whether teams can see their trust paths clearly enough to govern them. The practical shift is toward integration inventory, scope review, and data-path mapping as baseline identity work.
Hidden credential residue is the new attack surface inside SaaS platforms. When credentials live in records, notes, or attachments, identity programmes inherit a data problem that traditional access controls cannot see on their own. That is why SaaS posture work must include both secret discovery and lifecycle controls, not one or the other.
Blast-radius control will increasingly separate mature programmes from merely connected ones. Organisations that can map which integrations touch sensitive data, and remove secrets from those flows, will contain third-party incidents faster. The governance question is no longer whether to use integrations, but how much damage an integration can cause when it fails.
For practitioners
- Audit every OAuth-connected integration Inventory all third-party apps connected to core SaaS platforms, document the scopes they hold, and remove any integration that no longer has a business owner or current use case.
- Scan SaaS records for embedded secrets Search Salesforce objects, notes, attachments, and similar records for API keys, tokens, and credentials, then remove and rotate any exposed material before it can be reused.
- Shorten integration privilege windows Apply least privilege to OAuth scopes, enforce periodic recertification, and rotate or revoke tokens when business context changes rather than leaving long-lived access in place.
- Map downstream data paths before incident response Build an access map that shows which apps can read, copy, or export sensitive data so containment can focus on the integrations that actually widen the blast radius.
Key takeaways
- Compromised OAuth tokens can turn a single SaaS integration into a multi-system access pathway.
- The exposure risk is amplified when secrets are stored inside application data and not managed as credentials.
- Teams need integration inventory, secret discovery, and scope recertification to limit blast radius before an incident spreads.
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-03 | Token abuse and secret exposure align with NHI credential lifecycle and rotation gaps. |
| NIST CSF 2.0 | PR.AC-4 | Delegated access must be continuously managed across connected SaaS applications. |
| NIST Zero Trust (SP 800-207) | PR.AC-1 | Zero trust requires verifying each delegated connection and its downstream reach. |
Treat every SaaS integration as an explicit trust relationship and limit each one to the minimum necessary scope.
Key terms
- OAuth Token: An OAuth token is a delegated credential that lets one application act within a defined scope on behalf of a user or service. In practice, it is only as safe as its expiry, revocation, and scope controls, because anyone who holds the token can often act with the same permissions until it is invalidated.
- SaaS Integration Chain: A SaaS integration chain is the set of connected applications that exchange data, permissions, and trust through APIs or delegated credentials. It matters because one compromised connector can expand access across multiple systems, creating a blast radius that traditional single-application access reviews often miss.
- Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials such as API keys, tokens, and certificates across systems, records, and collaboration tools. It creates hidden attack paths because secrets are easy to reuse, hard to inventory, and frequently left behind long after their original business purpose has ended.
- Blast Radius: Blast radius is the amount of damage a compromise can cause before it is contained. In identity terms, it is shaped by how far credentials, permissions, integrations, and data paths extend beyond the initial point of failure, which is why visibility matters as much as access control.
Deepen your knowledge
OAuth token governance and secret sprawl are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment relies heavily on connected SaaS applications, the course maps directly to that operating reality.
This post draws on content published by Cyera covering the Salesloft Drift exposure: Lessons from the Salesloft Drift Exposure. Read the original.
Published by the NHIMG editorial team on 2025-09-02.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org