Salesforce and Drift token abuse exposes the NHI trust gap

At a glance

What this is: This analysis examines how stolen Salesforce OAuth tokens tied to Drift enabled trusted-integration impersonation, data exfiltration, and credential exposure across SaaS records.

Why it matters: It matters because IAM and NHI programmes have to govern SaaS-to-SaaS trust, not just user sign-in, when integrations can carry standing access into core business systems.

Context

Salesforce OAuth tokens are machine credentials that let one application act inside another system without a human login. In this case, that trust boundary was the point of failure, not the CRM itself. When integrations accumulate broad access and store sensitive material, identity governance has to cover the whole SaaS trust chain.

The article also frames Salesforce as an unintended secrets repository. That is a common failure mode in cloud software estates: records, support notes, and workflow data become a place where credentials live long after the original system of record was meant to hold them. The problem is not only exposure, but the persistence of access after the integration context is no longer trustworthy.

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 SaaS platforms create hidden credential risk?

A: Because business teams often store API keys, passwords, and cloud tokens inside records, notes, or support fields that were never designed as secrets vaults. That turns ordinary application data into a secondary credential store. Once those secrets are exposed, attackers can move from the original SaaS compromise into other environments that trust the same credentials.

Q: How should security teams govern third-party access when integrations create new trust boundaries?

A: Security teams should treat every third-party integration as a distinct trust boundary with its own access model, review cycle, and rollback plan. Scope credentials as narrowly as possible, validate data flows, and require logging that makes vendor activity attributable. The goal is not to block integrations, but to control how far a partner can reach, what it can change, and how quickly it can be cut off if behavior drifts.

Q: What should security teams do after embedded credentials are found in SaaS records?

A: Revoke and rotate the exposed secrets, then assume any downstream system that trusted those credentials may also be at risk. After that, review the surrounding integration scope, access logs, and connected applications to determine whether the original SaaS compromise has created a broader identity chain that needs to be broken.

Technical breakdown

How stolen OAuth tokens become trusted application access

OAuth tokens allow an application to authenticate and authorise on behalf of a connected service without re-entering user credentials. When those tokens are long-lived and broadly scoped, they become durable access carriers rather than transient session artefacts. In this incident, the stolen token let the attacker act as a legitimate Drift integration, query Salesforce objects, and blend into normal SaaS activity. The technical risk is not only theft, but the fact that the platform still treats the caller as trusted once the token is in hand. That makes token provenance and scope the real control boundary.

Practical implication: govern OAuth tokens as privileged machine credentials, with scope review and revocation paths tied to integration ownership.

Why SaaS platforms become de facto secrets stores

A CRM is not built to serve as a secrets custodian, yet business users often paste API keys, passwords, and cloud tokens into records, notes, and support fields. Once that happens, the platform becomes a shadow repository for high-value credentials that sit outside normal secrets management. The attacker’s value came from this secondary abuse path: token theft opened Salesforce, and Salesforce then exposed additional credentials that could be reused elsewhere. This is a classic trust expansion pattern. The initial compromise is one thing, but the hidden credentials create a second blast radius that extends beyond the original application.

Practical implication: locate and classify embedded credentials inside SaaS records, then remove the assumption that business applications are not holding secrets.

How token abuse turns SaaS trust chains into lateral movement paths

The compromise did not end at data theft. Once an attacker can use an integration token, they can often enumerate connected objects, extract stored material, and pivot into other systems if the exposed secrets are reusable. That is why SaaS-to-SaaS trust deserves the same scrutiny as workload-to-workload identity. Each connection becomes part of an attack path when the token is long-lived, over-scoped, or insufficiently monitored. Deleting query jobs may reduce obvious traces, but it does not undo the trust relationship that made the abuse possible. The real issue is delegated access without strong lifecycle controls.

Practical implication: treat integration tokens as part of your lateral-movement surface and review every trust chain for downstream reuse risk.

Threat narrative

Attacker objective: The objective was to abuse trusted SaaS integration access to steal data and reusable credentials from Salesforce-connected environments.

1. Entry occurred through stolen Salesforce OAuth tokens associated with the Drift integration, giving the attacker legitimate-looking access to Salesforce.
2. Escalation followed as the attacker used that access to query Salesforce objects at scale and harvest embedded credentials from records.
3. Impact was data exfiltration and broader credential exposure that could support further compromise outside Salesforce.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• GitHub OAuth token breach 2022: Stolen Heroku and Travis CI OAuth tokens let an attacker clone private repos from dozens of orgs, including npm, and reuse an AWS key found in them.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Token trust is the real control plane in SaaS-to-SaaS identity. This incident was not a failure of user authentication but a failure of delegated machine trust. Once an OAuth token is issued, the platform often treats the caller as inherently legitimate even when the token is stolen or repurposed. The implication is that identity governance for SaaS has to shift from account-centric controls to token-centric trust boundaries.

Secrets sprawl inside business platforms creates a hidden second breach surface. Salesforce was used as a repository for embedded credentials even though it was never intended to be a secrets vault. That means application data, support notes, and workflow fields can become downstream credential stores with no lifecycle oversight. Practitioners need to treat this as a structural governance problem, not an isolated hygiene issue.

Vendor integrations create overextended trust relationships by default. Drift and similar SaaS connectors often receive broad permissions because the business value is obvious and the governance burden is deferred. Over time, those permissions become standing machine privilege with weak ownership, poor visibility, and uncertain revocation. The implication for identity programmes is that third-party NHI governance must include application-to-application trust review, not just human access review.

Credential reuse inside SaaS collapses the boundary between data access and infrastructure access. Once secrets stored in records can be reused elsewhere, a CRM breach becomes an access path to cloud and operational systems. That is why the issue is not merely data theft but identity propagation through unmanaged secrets. Practitioners should read this as evidence that SaaS data stores can become identity launchpads when governance stops at the application boundary.

Identity blast radius is now determined by where integrations can read, not where users can log in. In this model, the largest risk comes from what a connected service can access after authentication, not from the login event itself. That changes how teams should assess exposure across NHI, PAM, and SaaS governance. The practitioner conclusion is simple: map integration scope before an attacker does.

From our research library:

• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.

What this signals

Ephemeral trust is the wrong mental model for SaaS integrations. The problem is not whether an integration is authenticated, but whether its access remains appropriate after the business context changes. Teams need to reclassify SaaS connectors as governed identities with expiry, ownership, and revocation controls.

Secrets hidden in application data extend the attack surface beyond the original platform. When records can contain credentials, the platform becomes part CRM, part identity store, and part shadow secrets repository. That should change how organisations think about data classification, retention, and access reviews.

Third-party NHI governance now has to cover application-to-application trust chains. Reviewing users and service accounts is not enough if the connected apps themselves can read valuable business objects. The control point is the token, the scope behind it, and the business justification for keeping that trust alive.

For practitioners

• Review connected application scopes Inventory every Salesforce-connected integration, then reduce OAuth scopes to the minimum required for operation. Reauthorise any integration whose scope is broader than its documented use case.
• Search for embedded credentials Scan Salesforce objects, notes, and workflow records for API keys, passwords, and tokens, then remove or rotate anything that should never have been stored there.
• Build a machine-identity inventory Track each OAuth token, service account, and third-party integration as a governed non-human identity with named ownership, revocation criteria, and review cadence.
• Constrain connected-app network access Apply IP restrictions and login ranges to reduce where integration tokens can be used, especially for high-trust SaaS connectors that reach customer or financial data.
• Tie token revocation to offboarding When a vendor relationship, integration, or workflow changes, revoke the associated tokens immediately instead of letting old trust relationships persist by default.

Key takeaways

• Stolen OAuth tokens can let attackers impersonate trusted integrations and bypass the normal user login story entirely.
• The incident shows how a business application can become a secondary secrets repository when users store credentials in records or notes.
• Teams need to govern token scope, offboarding, and embedded credential cleanup as part of the same NHI control surface.

Key terms

• OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Third-Party NHI: Third-Party NHI is a non-human identity owned or operated by an external organization, partner, contractor, or supplier. It includes service accounts, API keys, certificates, tokens, and automated agents that access systems outside the primary enterprise boundary. Governance must cover issuance, scope, monitoring, revocation, and contractual accountability.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.