Notifications
Clear all
Topic starter
11/06/2026 11:04 pm
TL;DR: Attackers used stolen OAuth tokens tied to the Salesloft Drift integration to access multiple Salesforce environments, forcing token revocation and internal investigations across major firms, according to AuthMind. The incident shows that delegated trust and long-lived tokens can create enterprise-scale exposure even when core platforms are not breached.
NHIMG editorial — based on content published by AuthMind covering the Salesloft Drift token abuse incident: stolen OAuth tokens and SaaS trust exposure
Questions worth separating out
Q: What breaks when OAuth tokens are stolen from a trusted SaaS integration?
A: A stolen OAuth token can bypass password-based controls and act with the permissions already granted to the integration.
Q: Why do delegated tokens increase breach impact in cloud and SaaS environments?
A: Delegated tokens often carry broad scopes and long lifetimes, so one compromise can expose multiple environments before anyone notices.
Q: What do security teams get wrong about OAuth and SAML access?
A: Teams often treat federated and delegated access as a setup detail instead of a governed identity path.
Practitioner guidance
- Inventory all delegated SaaS integrations Map every OAuth, SAML, and API-token relationship across core business systems, then assign an owner, purpose, and expiry expectation to each connection.
- Classify tokens as governed identities Treat each active token like a non-human identity with scope, lifecycle, and revocation rules, rather than a background technical artifact.
- Monitor behavioural drift in delegated access Alert on unusual access volume, new source locations, and repeated machine-like activity from identities that normally behave like low-frequency integrations.
What's in the full article
AuthMind's full research covers the operational detail this post intentionally leaves for the source:
- Telemetry examples showing how identity behaviour shifted across affected environments before containment.
- The access-pattern signals AuthMind used to distinguish normal automation from suspicious delegated use.
- Context on how the investigation linked source IP reputation, access spikes, and nonhuman-like activity.
- Operational response examples, including how teams could isolate an identity and revoke a token once anomalies appeared.
👉 Read AuthMind's analysis of the Salesloft Drift token abuse incident →
Salesloft OAuth token abuse: what it means for IAM teams?
Explore further
12/06/2026 7:34 am
Delegated SaaS access is now a primary identity perimeter. The breach was not a Salesforce compromise, it was a trust compromise inside the integration layer. OAuth tokens converted a third-party connection into durable access, which means identity governance has to extend beyond users and service accounts into every delegated app relationship. The practitioner takeaway is that integration trust must be governed as an identity control surface, not a convenience feature.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who is accountable when a third-party integration is abused?
A: Accountability sits with both the organisation that issued the access and the team that approved or failed to review it. Governance should assign clear ownership for token lifecycle, integration approval, and revocation. If no one owns the delegated path, the breach response will always be slower than the attacker.
👉 Read our full editorial: Salesloft token abuse shows why trust is the new attack surface
