TL;DR: Threat actors compromised third-party OAuth tokens tied to Gainsight applications, then used those non-human identities to access Salesforce customer instances and drive exfiltration activity, according to Astrix Security. The breach shows that app-to-app trust and persistent integration access remain weak points when lifecycle controls and visibility lag behind SaaS sprawl.
At a glance
What this is: Astrix Security describes how compromised Gainsight OAuth tokens were used to access Salesforce customer instances, then links the incident to persistent third-party NHI governance gaps.
Why it matters: IAM and security teams need to treat SaaS integrations as governed identities, because token-based third-party access can outlive the controls used to grant it.
Context
This incident is a third-party NHI governance problem, not just a SaaS compromise. Compromised OAuth tokens let an external integration act inside Salesforce with persistent access that was difficult to distinguish from legitimate application activity.
The security gap is familiar: app-to-app trust is often granted once and then left in place while ownership, scope, and monitoring drift. In environments with many overlapping SaaS integrations, the identity estate becomes harder to inventory than the user estate.
For IAM, IGA, PAM, and SaaS governance teams, the lesson is that third-party access must be managed as a lifecycle issue. Revocation, scope review, and offboarding are as important for integrations as they are for employees and contractors.
Key questions
Q: What breaks when a third-party OAuth app is compromised?
A: A compromised OAuth app inherits whatever delegated scopes users already approved, so the attacker can act through legitimate tokens instead of noisy intrusion methods. That breaks the assumption that user consent remains trustworthy after the app's security posture changes. The practical result is broader access to mail, documents, directories, and other linked systems until the grant is revoked.
Q: Why do SaaS-to-SaaS compromises create such a large blast radius?
A: Because a single trusted integration often connects multiple business systems, one stolen token can inherit access across several services. That means compromise in one app can become data theft in another, then pivot into collaboration or cloud platforms. The risk grows with every downstream connector that shares trust but lacks separate lifecycle governance.
Q: What are the signs that OAuth token abuse is happening inside a SaaS environment?
A: Common warning signs include token use outside normal business hours, large bursts of SOQL or API queries, repeated searches for passwords or API keys, and deletion of query logs. Requests with scripted user agents or traffic routed through unusual infrastructure also matter. Security teams should correlate these signals with privileged app activity and support-case access.
Q: What should organisations do when a third-party NHI is no longer trusted?
A: They should revoke access, disable related integration users, rotate any shared secrets, and confirm that no secondary apps still depend on the same trust relationship. Offboarding must be treated as a complete lifecycle event, not a single token revocation step.
Technical breakdown
How compromised OAuth tokens become a Salesforce access path
OAuth tokens let one application act on behalf of another without re-authenticating a person each time. In this incident, the Gainsight integration token became the access boundary, so compromising the token gave attackers a valid path into Salesforce customer instances. That is why NHI security is not just about secret storage. It is about who can mint, retain, and use delegated access across SaaS systems, and how quickly that access is invalidated when trust changes.
Practical implication: Treat OAuth-connected apps as governed identities with explicit ownership, scope, and revocation controls.
Why persistent third-party integrations expand blast radius
Third-party integrations often receive broad, durable permissions because they are expected to run continuously. Once those permissions are delegated, they can be used for bulk API activity, data export, or support-case access without triggering the same controls used for human logins. That makes the blast radius larger than a single account compromise. The problem is not only token theft. It is standing integration privilege combined with weak visibility into which applications are still trusted across the environment.
Practical implication: Inventory every app-to-app connection and remove excess permissions before the next revocation event forces the issue.
Why token revocation alone does not finish the job
Revoking active and refresh tokens closes the immediate access path, but it does not answer whether the integration touched other systems, stored secrets elsewhere, or left behind secondary access routes. In this case, the article notes connections to Salesforce, Slack, Entra ID, Google Workspace, and browser-based components, which means the trust graph can be wider than the initial incident surface. Effective containment requires understanding where the integration was embedded, not only where the token lived.
Practical implication: Map all downstream systems touched by the integration before declaring the exposure contained.
Threat narrative
Attacker objective: The attacker aimed to access and exfiltrate data from Salesforce customer instances by abusing delegated third-party application trust.
- Entry began with compromise of third-party OAuth tokens tied to Gainsight applications, giving the attacker a valid delegated access path into Salesforce-connected environments.
- Escalation occurred through legitimate integration privileges that enabled broad access to customer instances and support data without needing a user password.
- Impact followed through reconnaissance, preliminary testing, and then mass exfiltration activity using distinctive tooling and multiple proxy locations.
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.
- BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Third-party OAuth trust is now a first-class identity control surface: The breach works because integrations are trusted as durable actors rather than governed credentials with lifecycle boundaries. Once a token is issued, the app can keep operating long after ownership, intent, or risk has changed. Practitioners should treat every external integration as an NHI with an accountable owner and a revocation path.
Vendor access without lifecycle offboarding is the failure mode this incident exposes: The problem is not simply token compromise, but the absence of reliable offboarding for third-party access that spans multiple systems. When the same integration touches Salesforce, Slack, Entra ID, Google Workspace, and browser extensions, revocation becomes a distributed governance problem. The implication is that offboarding must be based on identity relationships, not just application lists.
NHI blast radius is determined by delegated scope, not by the original compromise point: A stolen token can reach far beyond the first connected app when permissions were granted broadly and left unreviewed. That makes inventory accuracy, scope minimisation, and ownership clarity the controls that define practical containment. Security teams should measure integration privilege as a live attack surface, not a configuration record.
Ephemeral trust debt: Third-party NHI access accumulates risk the longer it survives without revalidation. This article shows that stale integration trust can sit unnoticed until an external compromise turns it into an active exfiltration channel. The practical conclusion is that SaaS governance must continuously prove each integration still deserves the access it already has.
Visibility gaps turn NHI governance into an incident multiplier: The article’s own remediation advice assumes organisations may not know where Gainsight was connected. That is a governance failure, not just an operational inconvenience, because it delays containment and leaves residual access unconfirmed. Teams should assume the hidden integration is the default condition until proven otherwise.
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: NHI Lifecycle Management Guide
What this signals
Third-party SaaS access now behaves like a distributed identity programme: The practical risk is not just token theft, but the number of systems that inherit trust from one integration. Governance teams should expect revocation work to span multiple platforms, because app-to-app access rarely lives in one place.
Ephemeral trust debt grows whenever integrations are granted persistent scope and then left to age without revalidation. The longer those credentials survive, the more difficult it becomes to prove what they can still reach and whether the business still needs them.
The safest operating assumption is that every external integration needs an owner, a scope boundary, and a documented offboarding path. Without those three things, NHI governance becomes reactive incident cleanup instead of preventive control.
For practitioners
- Revoke and reissue delegated access Identify every Gainsight-published token, refresh token, and related integration credential, then disable the associated integration users before restoring service on a reviewed basis.
- Map the full SaaS trust graph Trace where the affected integration connected into Salesforce, Slack, Entra ID, Google Workspace, and browser extensions so you can close every downstream access path, not just the original app.
- Reduce permissions on connected apps Review every third-party integration for least privilege, then remove permissions that are not required for the app’s current function or operating owner.
- Audit event logs for bulk access patterns Search Salesforce logs for anomalous exports, bulk API calls, and unusual integration-user activity around the suspected compromise window to confirm what the token reached.
- Build offboarding into integration governance Require an explicit decommission step for every third-party NHI so access cannot survive a vendor change, product change, or integration ownership change.
Key takeaways
- The breach exposes a recurring weakness in SaaS governance: third-party integrations are often trusted for long periods without enough ownership or review.
- The article says Salesforce and other vendors revoked active and refresh tokens and removed affected apps while investigators traced unauthorized access and exfiltration activity.
- The control gap is lifecycle offboarding for delegated access, because revocation only works when teams can identify every place the integration was embedded.
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 sets 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 incident centers on compromised third-party integration tokens used to access Salesforce. |
| NHI-05 — Overprivileged NHI | The article describes persistent access that likely exceeded what the integration needed. | |
| NHI-01 — Improper Offboarding | Revocation and removal of affected apps were central because the access had to be shut down after compromise. | |
| Recommendation — Inventory third-party NHIs and revoke trust relationships when vendor-controlled integrations are exposed. Reduce integration scope to the minimum permissions required and re-certify standing access regularly. Build offboarding steps for every third-party NHI so access is removed cleanly when trust changes. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth token revocation and rotation map directly to authenticator lifecycle control. |
| Recommendation — Apply IA-5 to manage issuance, revocation, and rotation of integration authenticators. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The attack pattern involved token abuse followed by bulk data extraction. |
| Recommendation — Map token abuse to TA0006 and prioritise detection of bulk exfiltration patterns under TA0010. | ||
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.
- 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.
- Off-boarding: Off-boarding is the process of removing a departing user’s access, credentials, and related entitlements from the environment. In mature IAM programmes, it also includes reviewing sessions, shared secrets, delegated roles, and linked non-human identities so that exit events do not leave behind hidden access paths.
- Ephemeral trust debt: Ephemeral trust debt is the accumulated risk created when short-lived access, credentials, or trust relationships are issued quickly and not fully governed. In practice, it appears when temporary permissions, tokens, or sessions outlive their intended purpose, lack clear ownership, or are not revoked, audited, or rotated with enough discipline.
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 June 7, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org