Chatbot token abuse exposed the limits of identity visibility

At a glance

What this is: This is an analysis of how stolen chatbot tokens enabled access to more than 700 Salesforce tenants and why common identity controls missed the abuse.

Why it matters: It matters because IAM, IGA, PAM, and cloud security programmes still struggle to govern third-party non-human access that sits outside normal onboarding, authentication, and review workflows.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.

Context

A non-human identity can be an application, token, or integration that acts on behalf of a system without a person present at execution time. This article is about what happens when those identities are created outside normal IAM scope, then later used to reach customer data at scale.

The security gap here is not just secret theft. It is governance blindness across SaaS-to-SaaS access, where a connected application can keep operating long after no one can explain who owns it, what it reaches, or whether it still needs access.

For identity teams, this is a visibility and lifecycle problem that cuts across NHI governance, third-party access, and audit readiness. The breach path shows why inventories built only from HR or SSO data will miss the identities that matter most.

Key questions

Q: What breaks when a chatbot or vendor integration is not governed as a non-human identity?

A: The control model breaks because the application can keep exercising granted access long after the business context is forgotten. Human-centric onboarding and recertification do not catch forgotten SaaS grants, so ownership, scope, and offboarding all become uncertain at the moment they matter most.

Q: Why do stolen OAuth tokens create such a broad access risk in third-party integrations?

A: OAuth tokens can act like delegated login credentials across multiple services, so one stolen token may open access to private data in several connected systems. The risk increases when tokens are long-lived, over-scoped, or shared across integrations. Attackers often prefer this route because it bypasses normal password controls and can remain useful until the token is discovered and revoked.

Q: How should teams detect risky third-party access before it is abused?

A: Look for external identities with broad scopes, long-lived secrets, and permissions that no longer match current contracts or operational need. Those are the strongest indicators that trust has outgrown governance. Monitoring should focus on issued credentials, last-used dates, and whether the integration still has a valid business owner.

Q: When does SaaS integration scoping become a legal and operational problem?

A: It becomes a problem as soon as the organisation cannot answer, quickly, which connected applications can reach sensitive data and what they accessed during the incident window. Slow scoping increases notification burden, complicates accountability, and turns a security event into a governance failure.

Technical breakdown

Why token replay bypasses normal authentication controls

OAuth access and refresh tokens let an application act as an already-authorized client. When attackers steal those tokens, they do not need to reauthenticate, trigger MFA, or satisfy conditional access checks, because the platform sees the request as legitimate token use rather than a fresh login. That is why IdP-centric detection often misses this pattern. In SaaS-to-SaaS abuse, the control failure is not weak password handling but trust in a bearer credential that can be replayed from elsewhere. The result is a valid session path with no user-facing challenge, even though the underlying actor has changed.

Practical implication: monitor token use and connected-app behaviour, not just interactive logins.

How hidden SaaS grants escape IGA and PAM scope

IGA tools are usually built around human joiner-mover-leaver workflows and known account lists. PAM can protect secrets it has onboarded, but many SaaS integrations live in vendor-owned infrastructure or in application registries outside the customer’s privileged vaulting model. If an integration was created years ago, never fully documented, or never formally deployed, it may not exist in the governance record at all. That leaves a blind spot where an identity is active, authorized, and reachable, yet absent from certification cycles, offboarding workflows, and ownership assignment.

Practical implication: extend governance scope to connected applications, not only employee or admin identities.

Why weeks of scoping became part of the attack impact

The article shows that the damage was not limited to the initial access event. Attackers queried support and CRM data, then deleted query jobs, forcing customers to reconstruct which third-party applications held access, what each could reach, and what had been touched. That is a lifecycle failure as much as a security one. If a programme cannot answer those questions quickly, the incident window expands into legal exposure, notification burden, and investigative delay. In NHI governance terms, the question is not only whether access was abused, but whether ownership and traceability existed before the abuse occurred.

Practical implication: build identity inventory and scope tracing so incident scoping is measured in hours, not weeks.

Threat narrative

Attacker objective: The objective was to reach sensitive tenant data and extract credentials, tokens, and passwords from customer support content at scale.

1. Entry occurred through stolen OAuth and refresh tokens associated with a chatbot integration, allowing the attacker to act as a trusted application rather than a new login session.
2. Credential abuse followed when the tokens were replayed against connected Salesforce tenants, bypassing login-based controls and appearing as authorized API activity.
3. Impact came from systematic SOQL queries across customer data, with query jobs deleted afterward and exposed secrets harvested from support records.

Breaches seen in the wild

• Gainsight Salesforce breach 2025: Stolen OAuth tokens for Gainsight's Salesforce app, some eight years old, were used against customer orgs; Google saw 200+ instances at risk.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Token replay turns SaaS integrations into governable identities, not just technical dependencies. Once a connected application can act with standing authority, the identity problem moves from user login control to application ownership, scope, and offboarding. The field still treats many integrations as background plumbing, but this incident shows they are active identity subjects with direct access consequences. Practitioners need to classify every externally reachable integration as part of the identity estate.

Visibility is the control plane, not the dashboard. A registry that cannot tell you which non-human identities can reach crown-jewel data is not governance, it is documentation. The article’s weeks-long scoping burden shows that detection alone does not close the operational gap because the real question is who can reach what, under which grant, and with what evidence. That is the practical boundary between inventory and control.

Ephemeral credential trust debt: The trust placed in a token persists beyond the people and processes that created it. That assumption is designed for stable ownership and reviewed authorizations, but it fails when vendor-side credentials survive integration drift, pilot abandonment, and forgotten SaaS grants. The implication is that identity governance has to treat trust decay as a first-class risk, not an exception case.

Lifecycle failure is the root issue when third-party access outlives the business relationship. The breach pattern shows that access can remain valid even after the context that justified it has disappeared. Once an integration is not owned, not reviewed, and not offboarded, the security model has no reliable stopping point. Practitioners should treat third-party NHI offboarding as a mandatory governance event, not an optional cleanup task.

AI adjacency does not remove the underlying identity discipline. Whether the actor is a chatbot, a service account, or a vendor integration, the same governance questions apply: who owns it, what can it reach, and how fast can it be withdrawn? The field is heading toward identity governance that includes both human and non-human actors in one control model, because the attack surface already does.

From our research library:

• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
• Read next: Identity Security Programme Guide

What this signals

Ephemeral credential trust debt: The hard problem is not simply revoking a compromised token. It is proving which other grants were created under the same assumptions and whether they still deserve trust. That is why connected applications must be governed as part of the identity estate, not as peripheral plumbing.

A security programme that can only certify human accounts will keep missing the identities that move data in and out of SaaS. The control boundary has shifted to application grants, delegated access, and evidence-based ownership, so visibility into non-human identity scope has become a prerequisite for incident response and audit readiness.

The visibility gap is still large enough to matter operationally: only 5.7% of organisations have full visibility into their service accounts. That kind of blind spot explains why scoping, not detection speed, often determines the blast radius after a token-based compromise.

For practitioners

• Inventory connected applications as first-class identities List every SaaS-to-SaaS grant, chatbot integration, and vendor application that can reach production data. Record the owner, issuing business case, scopes, and last verified use so forgotten grants do not remain outside review cycles.
• Trace token reach before the next incident For each token-bearing integration, document the downstream systems it can access, the data classes it can query, and the logs needed to prove last activity. Use that map to shorten scoping when an integration is abused.
• Move review from people to grants Replace human-only recertification with certification of connected-app grants, service accounts, and vendor-held access. Revalidate whether the application still has a business owner and whether the scope is still justified.
• Separate token use from interactive login monitoring Detect anomalous API activity, unusual query patterns, and Tor-like source behaviour for trusted applications. Login-only alerts will miss replayed bearer tokens because no new authentication event occurs.
• Measure scoping time as an exposure metric Track how long it takes to answer which non-human identities can reach crown-jewel data and what they touched last week. If the answer takes days or weeks, the programme is already behind the threat.

Key takeaways

• The core failure is identity governance blind spot, not just token theft or an authentication bypass.
• The article shows how weeks of manual scoping can become part of the damage after a trusted integration is abused.
• Treat connected applications as governable identities and shorten the time it takes to trace their owners, scopes, and last use.

Key terms

• 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.
• Token Replay: Token replay is the reuse of a valid access or refresh token by someone other than the intended client. The token may still be unexpired and cryptographically correct, so the compromise often shows up only through context anomalies such as location, device, or session overlap.
• Connected-App Grant: A connected-app grant is the authorization that allows one application to call another system and act within a defined scope. For identity teams, it behaves like a machine identity relationship and must be owned, reviewed, and revoked with the same discipline as other privileged access.
• Identity Scoping: Identity scoping is the process of constraining what an identity can access, how long it can access it, and under what conditions. In modern environments, it applies to both people and non-human identities, and it is a primary control for limiting lateral movement.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.