OAuth token abuse shows how AI chat integrations widen NHI risk

TL;DR: Attackers compromised Drift, harvested Salesforce OAuth tokens, and then used scripted tools to exfiltrate customer records across finance, HR, and SaaS environments, according to Salesloft and Google Threat Intelligence. The breach shows that OAuth-connected AI chat integrations can become shared non-human identity blast radii unless access, ownership, and revocation are tightly governed.

At a glance

What this is: This is an analysis of how compromised OAuth tokens in an AI chat integration became a scalable entry point into Salesforce tenants.

Why it matters: It matters because OAuth-connected AI apps behave like non-human identities, so their permissions, lifecycle, and revocation process directly shape enterprise blast radius.

👉 Read Salesloft's analysis of the Drift OAuth token breach and Salesforce exposure

Context

OAuth-connected AI chat integrations can function as non-human identities with delegated access, persistent scopes, and weak operator visibility. When one of those identities is compromised, the issue is not just account theft. It becomes a governance failure across every tenant that trusted the integration, which is exactly the problem space NHI practitioners need to control.

In this breach, the security gap was not at the human login layer. It was in the trust chain around a third-party integration that could mint and use tokens on behalf of customers, then move data at machine speed. That starting position is increasingly typical as enterprises add more SaaS and AI-linked connectors without treating them as governed NHIs.

Key questions

Q: How should security teams govern OAuth-connected AI integrations?

A: Treat them as non-human identities with owners, scopes, and a lifecycle. Require explicit business justification, limit permissions to the minimum needed, review access on a schedule, and verify that revocation actually removes access. If a connector can reach sensitive data, it needs the same control discipline as a privileged service account.

Q: Why are OAuth tokens risky in SaaS integrations?

A: OAuth tokens are risky because they can preserve delegated access after the original user action is long gone. If an attacker steals a valid token, they may bypass MFA and login controls entirely, then use normal APIs to access or extract data. The risk comes from reusable authority, not just from password theft.

Q: What is the difference between a SaaS app permission and a human user session?

A: A human session is usually short-lived, interactive, and constrained by user context. A SaaS app permission is often non-interactive, long-lived, and capable of acting at machine speed through APIs. That difference matters because the app can keep working after compromise unless the token or scope is actively revoked.

Q: How can organisations detect token abuse before data loss becomes large?

A: Baseline normal API behaviour for each integration, then alert on bulk exports, unusual query volume, unusual timing, and repeated access across many records. Pair that monitoring with fast token revocation and owner notification. The goal is to spot machine-speed extraction while it still looks abnormal enough to stop.

Technical breakdown

How OAuth-connected AI apps become non-human identities

An OAuth app is more than a connector. Once approved, it receives delegated authority that can outlive a user session and operate without human interaction. In NHI terms, that makes it a machine identity with its own secrets, scopes, and lifecycle. The risk is not only whether the app is malicious. It is whether the trust boundary around the app is visible, reviewable, and revocable. If an integration can mint tokens or keep long-lived scopes, it can act as a durable access path even when no person is actively present.

Practical implication: Treat every AI-connected OAuth app as a governed identity with ownership, scope limits, and documented revocation steps.

Why OAuth scopes and long-lived tokens create blast radius

OAuth scopes define what an app can reach, but scopes are often granted broadly at install time and then forgotten. Long-lived tokens preserve that access until they are revoked, which turns a single compromise into repeatable API abuse. In this incident, the issue was not authentication in the human sense. It was delegated machine access that still worked after compromise. That pattern is common in SaaS ecosystems because the control plane trusts the token, not the operator's current intent. The result is a hidden super-user effect across connected business systems.

Practical implication: Review OAuth scopes as standing privilege and shorten token lifetime wherever the platform permits.

How scripted exfiltration changes the breach model

Once attackers obtain valid tokens, they do not need noisy exploit chains. They can use normal APIs, automate collection, and pull records at bot scale. That shifts the breach from opportunistic access to industrialized theft. The important technical point is that machine identities often bypass the controls built for humans, such as MFA prompts, device checks, and user awareness. When the identity is an integration, defenders need telemetry for API volume, unusual query patterns, and token abuse, not just login anomalies.

Practical implication: Instrument API abuse detection and token-use baselines for every high-value integration.

Threat narrative

Attacker objective: The attacker objective was bulk access to customer data through a trusted integration path rather than through direct exploitation of Salesforce itself.

1. Entry occurred when attackers compromised the AI chat integration and obtained the ability to create or abuse OAuth tokens tied to customer Salesforce access.
2. Escalation happened because those tokens carried long-lived API permissions that functioned like privileged delegated access across tenants.
3. Impact followed when scripted tools used the stolen tokens to exfiltrate customer records at scale.

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

OAuth-connected AI tools should now be treated as first-class NHIs, not helper apps. They hold delegated authority, persistent scopes, and revocation risk just like service accounts and API keys. The governance mistake is assuming that a user-installed integration is lower risk than a backend identity. Practitioners should place these apps inside the same ownership, review, and monitoring model used for other non-human identities.

Identity blast radius is the right concept for shared SaaS integrations. A single compromised connector can affect many tenants because the trust model is distributed but the token is reusable. That means exposure is not limited to one account or one vendor relationship. Security teams should define blast radius for every integration before approval, then reduce it through scope restriction, segmentation, and fast revocation.

Machine-speed exfiltration makes traditional human-centric monitoring insufficient. When attackers use valid tokens, the dangerous activity looks like normal API consumption until volume or pattern changes reveal the abuse. That is why detection must focus on non-human behaviour, not only on failed logins. Teams should build token-use baselines and alert on abnormal extraction patterns before data loss becomes obvious.

Third-party OAuth visibility is now an audit requirement, not a convenience feature. The harder question is not whether a connector exists, but who owns it, what it can reach, and how fast it can be cut off. Many organisations still cannot answer those questions cleanly. Practitioners should treat inventory completeness and rapid revocation as control objectives, not after-the-fact response tasks.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• 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 control framework, OWASP NHI Top 10 helps teams map agentic and integration risk into practical governance decisions.

What this signals

OAuth-connected AI integrations are now part of the non-human identity surface, which means inventory quality and token governance will influence incident outcomes as much as endpoint security. Third-party visibility gap: when organisations cannot see which apps are connected, they cannot defend what those apps can reach. With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security, the programme-level response has to be continuous discovery, not annual review.

The practical signal for security leaders is that integration risk now sits inside identity governance, not beside it. Teams should align SaaS approvals, token review, and revocation testing with the same controls used for privileged access. That shift becomes more urgent as AI chat tools, automation connectors, and service accounts converge into one shared trust layer.

For practitioners

• Map every OAuth-connected AI integration Inventory each integration, record the business owner, the data it can access, and the exact scopes granted. Include revoked, dormant, and shadow integrations so you can identify stale trust paths before they become incident paths.
• Reduce standing privilege in token scopes Remove broad scopes that are not required for daily operation and prefer narrower delegated permissions where the platform supports them. Reassess long-lived access grants on a fixed schedule and revoke anything that no longer has a clear business purpose.
• Build API exfiltration detections Alert on unusual query volume, bulk record export behaviour, and token use from atypical automation patterns. Normal human login controls will not catch this class of abuse, so your detection model must focus on API activity and extraction velocity.
• Test emergency revocation workflows Run a live exercise for disabling an integration, invalidating tokens, and confirming that downstream access is actually cut off. Include the steps needed to notify business owners and replace the connector without leaving the old identity active.

Key takeaways

• OAuth-connected AI integrations can operate as hidden non-human identities with enough delegated access to create major blast-radius risk.
• The breach shows that token reuse and API automation can turn a single compromised connector into high-volume data theft across many tenants.
• Security teams need inventory, scope reduction, and fast revocation workflows before integration trust becomes the weakest control in the stack.

Key terms

• OAuth-connected non-human identity: An OAuth-connected non-human identity is a machine identity created when an application receives delegated access through an authorisation grant. It can act on behalf of a tenant without a person present, which makes scope, ownership, and revocation as important as authentication.
• Identity blast radius: Identity blast radius is the amount of data, systems, or tenants an identity can reach if it is compromised. For NHIs, the blast radius is shaped by scopes, token lifetime, and connected applications, so reducing it requires deliberate permission design and fast cutoff paths.
• Token abuse: Token abuse is the misuse of a valid credential after it has been issued, stolen, or over-scoped. In non-human identity environments, it often bypasses human-centric controls because the token is accepted as legitimate until defenders revoke it or detect abnormal API behaviour.

What's in the full article

Salesloft's full article covers the operational detail this post intentionally leaves for the source:

• The breach timeline showing how the Drift integration was compromised and how the OAuth tokens were obtained
• The specific victim organisations and the types of customer data exposed across Salesforce tenants
• The scripted extraction workflow used to automate data theft at scale after token compromise
• The containment actions taken to disable integrations, revoke access, and limit further exposure

👉 The full Salesloft article includes the breach anatomy, victim examples, and containment steps

Deepen your knowledge

OAuth-connected AI integrations, token governance, and non-human identity lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a programme around SaaS connectors and machine identities, it is worth exploring.