TL;DR: OAuth tokens stolen from Drift let attackers use an AI chat integration to access Salesforce data at scale, according to Entro Security, turning a third-party connection into a shared non-human identity blast radius across many tenants. OAuth apps need the same lifecycle, ownership, and revocation discipline as any other NHI.
At a glance
What this is: This analysis shows how stolen OAuth tokens from an AI chat integration turned a trusted Salesforce connection into a multi-tenant NHI exposure path.
Why it matters: IAM, IGA, PAM, and NHI teams need to treat OAuth-connected SaaS apps as governed identities because their scopes, ownership, and revocation determine blast radius.
Context
OAuth-connected AI chat apps create a governance gap when an approved integration can act with delegated access long after the people who approved it have moved on. The issue is not the chat interface itself, but the non-human identity behind it and the scope it inherits inside downstream systems like Salesforce.
In this case, attackers abused stolen OAuth tokens from Drift to access customer data across multiple tenants. That pattern matters because many identity programmes still treat SaaS integrations as peripheral rather than as first-class identities with owners, scopes, and revocation paths.
For identity teams, the practical question is whether every connected app is inventoried, reviewable, and revocable with the same seriousness as a privileged account. If not, the integration layer becomes an invisible extension of the enterprise trust boundary.
Key questions
Q: What breaks when an OAuth-connected AI chat app is not governed like an identity?
A: The app can inherit delegated access that outlives the original approval, which turns a convenience integration into a reusable entry point. Without ownership, scope review, and revocation discipline, the organisation loses track of who can reach what and why. That is how a trusted app becomes a hidden NHI exposure path.
Q: Why do stolen OAuth tokens create disproportionate risk in cloud-connected business systems?
A: Stolen OAuth tokens are dangerous because they inherit the permissions already granted to the connected app, so the attacker often does not need to authenticate again. That makes the token a reusable access bearer for SaaS APIs, and it can blend into normal traffic. The risk rises when tokens span multiple customer environments or sensitive CRM data.
Q: What are the signs that a connected app has become overprivileged?
A: Look for apps that can reach more data than their stated business purpose, generate repeated high-volume API calls, or remain connected long after the original use case has changed. These signals show that scope and ownership are drifting away from operational reality, which increases the chance of mass exfiltration if the token is abused.
Q: Should teams treat SaaS-to-SaaS integrations as privileged access?
A: Yes. A connected app can function like a privileged service identity if it can read, write, or export business data through APIs. Treating it as ordinary application plumbing leaves no clear place for certification, offboarding, or incident revocation, which is exactly where shared blast radius emerges.
Technical breakdown
How OAuth-connected apps become delegated non-human identities
An OAuth-connected SaaS app is not a user account, but it can still hold delegated access tokens that authorize API actions on behalf of an organisation. Those tokens inherit the approval, scope, and lifetime defined at consent time, which means the app can behave like a non-human identity with broad reach into downstream data stores. When the connected app is a chat integration, the risk grows because the integration is often granted access for convenience, not for tightly bounded operational need. The control problem is lifecycle governance: who owns the app, what it can touch, and how quickly its delegated access can be withdrawn when trust changes.
Practical implication: Treat every OAuth-connected app as an identity object with an owner, scope, and offboarding path.
Why stolen OAuth tokens bypass human-centric controls
OAuth tokens are bearer credentials, so possession often equals access until the token is revoked or expires. That makes them structurally different from human authentication sessions that may be guarded by MFA, device posture, or user interaction. In the Drift breach pattern, the attacker did not need to impersonate a person repeatedly; they only needed valid delegated tokens to call APIs at scale. This is why human login controls do not solve machine-to-machine access risk. The relevant security boundary is not the user password or SSO flow, but the token, the scope, and the service-to-service trust relationship.
Practical implication: Shift detection and revocation controls to token issuance, scope review, and immediate invalidation.
How automation turns one token theft into bulk data loss
Once an attacker has valid API tokens, scripted tooling can query records much faster than a human could through an interface. That changes the breach from opportunistic access to industrialized extraction. The integration’s delegated privileges determine whether the attacker can search, enumerate, and exfiltrate at volume, which is why overprivileged scopes amplify impact even when the initial compromise is narrow. In practical terms, the abuse path combines identity compromise with workflow automation: trusted integration, valid token, repeated API calls, and then bulk collection of customer or internal records.
Practical implication: Limit delegated scopes to the minimum API actions needed and monitor for high-rate extraction behaviour.
Threat narrative
Attacker objective: The attacker aimed to extract customer data at scale by turning a trusted integration into a reusable access channel.
- Entry occurred through compromise of the Drift AI chat integration and abuse of its OAuth token creation path, giving the attacker delegated access into connected Salesforce environments.
- Credential access followed when OAuth tokens were harvested and reused as bearer credentials, allowing the attacker to act through the integration rather than through human login flows.
- Escalation came from long-lived, high-privilege API scopes that let the attacker move from a single compromised integration to multiple tenant data stores.
- Impact was bulk exfiltration of customer records across finance, HR, and SaaS environments, forcing token revocation and integration shutdowns.
Breaches seen in the wild
- Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
- 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
OAuth-connected AI chat apps are now identity assets, not optional integrations. Once a third-party app can request tokens and reach production data, it sits inside the identity governance model whether teams acknowledge it or not. The governance question shifts from vendor management to delegated authority, lifecycle ownership, and revocation speed. Practitioners should classify these integrations as first-class NHIs.
Delegated access is only as safe as the scope you can actually see. The breach pattern here was not a password attack, but a scope problem hidden behind a trusted app approval. OAuth scopes often outlive the original use case, which means the blast radius expands quietly until an attacker reuses the token path. Teams should treat scope review as an operational control, not an annual checkbox.
Third-party NHI risk is now a supply-chain problem. A compromised integration can become a shared entry point across many tenants, which means one vendor incident can propagate across customers at once. That is the same governance failure pattern seen in other SaaS-to-SaaS compromises: trust is inherited faster than it is continuously validated. Security teams should assume connected apps can create cross-tenant exposure unless continuously governed.
Identity blast radius is the right concept for AI chat integrations. The article shows how an approved chat app can become a super-user by accident, not design. That makes blast-radius containment, not just compromise prevention, the central governance objective for NHI programmes that now include AI-enabled SaaS integrations. Practitioners should measure how far a single delegated app can reach before it is revoked.
Access review models were built for people, but OAuth apps behave like persistent service identities. The review cadence may be human-paced, yet token abuse happens at machine speed. That mismatch creates an identity control gap between approval, observation, and revocation. Practitioners should design reviews around app ownership, token lifetime, and privileged scope rather than around user-centric certification alone.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: SaaS-to-SaaS and OAuth App Governance Guide
What this signals
OAuth-connected AI chat apps should now be governed as delegated identities with owners, scopes, and offboarding paths. If a tool can act inside Salesforce or similar systems on behalf of the business, it belongs in the same control plane as other NHIs, not in an informal integration register.
Identity blast radius: the useful concept here is not just token theft, but how far a trusted integration can reach before revocation catches up. That is the measurement teams should use when deciding whether an app approval model is safe enough for production use.
The control failure is usually not a single missing setting. It is the accumulation of broad scopes, weak inventory, and slow revocation across SaaS-to-SaaS connections, which means connected-app governance now has to sit inside the core IAM and NHI programme.
For practitioners
- Inventory every OAuth-connected app Build a complete register of connected apps, their owners, scopes, and downstream systems so no AI chat integration sits outside governance.
- Enforce short token lifetimes and rapid revocation Reduce the period in which stolen bearer tokens remain valid and make revocation a standard incident-response action for delegated access.
- Review privileged OAuth scopes quarterly Recertify high-risk app scopes against actual business need, especially where the integration can read customer or HR records.
- Alert on bulk API extraction from trusted apps Detect unusual query volume, repeated export patterns, and scripted access that indicate a delegated integration is being used for data harvesting.
- Separate AI chat integrations from sensitive systems Do not let convenience integrations reach production data without explicit segmentation, least-privilege scoping, and named business ownership.
Key takeaways
- OAuth-connected AI chat apps can function as delegated non-human identities and therefore need explicit ownership, scope review, and revocation control.
- A single stolen bearer token can bypass human-centric protections and give attackers machine-speed access to large data sets.
- Blast-radius reduction depends on short token lifetimes, least-privilege scopes, and active monitoring of high-volume API extraction.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The breach began in a third-party integration trusted by many customers. |
| NHI-05 — Overprivileged NHI | The tokens carried broad API reach beyond the minimum business need. | |
| NHI-07 — Long-Lived Secrets | Stolen tokens remained useful long enough to support bulk extraction. | |
| Recommendation — Inventory third-party apps as NHIs and revoke trust when the integration risk changes. Reduce OAuth scopes to the least privilege required for each connected app. Shorten token lifetimes and invalidate exposed credentials immediately after detection. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth tokens are authenticators that require lifecycle control and revocation. |
| Recommendation — Apply authenticator management controls to rotate, revoke, and track OAuth tokens. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack chain centered on token theft followed by bulk data extraction. |
| Recommendation — Map token abuse to credential access and exfiltration tactics in detections and incident review. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Connected apps need governed entitlements just like human users and service accounts. |
| Recommendation — Review connected-app entitlements against approved business use and remove excess access. | ||
Key terms
- OAuth Connected App: An OAuth connected app is a third-party integration that uses approved scopes and tokens to act inside another system. For security teams, it functions like a non-human identity with persistent access and therefore needs ownership, review, and offboarding controls. Compromise of the token often becomes compromise of the trust relationship.
- Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- 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.
Published by the NHIMG editorial team on May 12, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org