Salesloft token compromise shows the limits of static NHI controls

At a glance

What this is: This is an analysis of the Salesloft supply chain breach and the NHI control gap it exposed, centered on compromised OAuth tokens used to access Salesforce data.

Why it matters: It matters because service account and token governance now has to account for anomalous use, ownership, and revocation speed, not just provisioning and rotation.

👉 Read Andromeda Security's analysis of the Salesloft supply chain breach and NHI exposure

Context

A supply chain breach becomes an identity problem when a trusted connected app token is compromised and used outside its normal operating pattern. In this case, the primary issue is not Salesforce itself but the non-human identity behind the integration, which shows why NHI governance has to include usage baselines, ownership, and fast revocation.

The article’s core point is that static controls are too slow for delegated access paths that can be abused immediately after compromise. For IAM, IGA, and PAM teams, the question is no longer whether the token was issued correctly, but whether the organisation can detect when the identity begins acting unlike itself.

Key questions

Q: What breaks when a stolen OAuth token is used against a trusted integration?

A: The trust model breaks because the system still sees a valid credential, even though the actor behind it is no longer trustworthy. In practice, stolen delegated access can bypass interactive authentication and continue until revocation or expiry, which is why connected app tokens need ownership, monitoring, and fast containment.

Q: Why do service account and token compromises create such broad exposure in cloud and SaaS environments?

A: They create broad exposure because one credential often represents access to many downstream objects, APIs, or tenants. If that identity is over-scoped, the attacker inherits the full permission surface of the integration, not just a single action path, which is why blast-radius control matters so much.

Q: How do security teams know whether NHI behavioural monitoring is actually working?

A: It is working only if it can distinguish normal machine access from anomalous use without overwhelming operators with noise. Useful signals include new source IPs, sudden changes in API mix, and request volumes that do not match the identity’s usual purpose.

Q: Who should be accountable when a third-party connected app token is compromised?

A: Accountability should sit with the team that owns the integration, not only with the platform where the token was used. That team needs to know the scope of access, the revocation process, and the monitoring thresholds, because delegated trust is still an owned identity problem.

Technical breakdown

OAuth token abuse in connected apps

OAuth tokens in connected applications act as delegated credentials, allowing a service to call another system without re-authenticating a person each time. That makes them powerful and also fragile: once stolen, the token can be replayed from any client that can present it. In the Salesloft case, the compromise did not require breaking Salesforce authentication directly. The attacker used the trusted integration path itself, which is why connected app identity has to be governed as an NHI with its own lifecycle, not as a simple application setting.

Practical implication: inventory connected app tokens as first-class NHIs and bind each one to an owner, scope, and revocation path.

Behavioral baselining for NHI access

Behavioral baselining compares current activity to established identity patterns such as source IP, API mix, request volume, and time-of-day usage. For NHIs, this is more useful than human-style anomaly detection because machine identities often have narrow and repetitive patterns that make drift easier to spot. In the article’s example, a new client IP plus a radically different API usage pattern signaled bulk extraction rather than normal application behavior. That kind of detection works because it looks at the identity’s own history, not just at the presence of valid credentials.

Practical implication: establish per-NHI baselines for IPs, API frequency, and data access volume so deviations can trigger immediate containment.

Automated token revocation and privilege zeroing

Once an NHI is compromised, delay is the enemy. If a stolen token remains valid, the attacker can continue using legitimate access until the token expires or is manually revoked. The article’s response model combines instant privilege reduction with token revocation, which is the right sequence for limiting blast radius in delegated access scenarios. This is not the same as password reset for a human account. With NHIs, the control objective is to sever the trust chain quickly enough that the token cannot be reused for further data extraction.

Practical implication: connect anomaly detection to automated revocation and privilege shutdown so confirmed misuse cannot persist across multiple requests.

Threat narrative

Attacker objective: The attacker’s objective was to use a compromised delegated credential to extract Salesforce data at scale without triggering direct authentication failure.

1. Entry occurred through compromise of the Salesloft connected app OAuth token, giving the attacker a valid delegated credential instead of forcing a direct exploit against Salesforce.
2. Escalation happened when the stolen token was used from a new client IP and paired with bulk API activity that exceeded the identity’s normal pattern.
3. Impact came from data exfiltration across hundreds of Salesforce instances, showing how one abused NHI can create broad supply chain exposure.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Connected app tokens are not secondary assets, they are production identities. The Salesloft case shows that a delegated OAuth token can become the real control plane for downstream access, even when the primary platform is not breached. That makes token governance an identity discipline, not an application housekeeping task. Practitioners should treat every integration token as an owned NHI with explicit lifecycle accountability.

Behavioral drift is the failure mode that static trust models miss. A valid token can still be malicious when it appears from a new client IP and begins issuing requests that do not resemble historical usage. The governance gap is not just that access existed, but that the programme assumed valid credentials would keep behaving like valid credentials. Practitioners should reframe NHI monitoring around identity behaviour, not credential presence alone.

Zeroing privilege after detection is a blast-radius strategy, not a complete control model. The article’s automated response is directionally right because it cuts off misuse fast, but it also reveals how much trust was already extended before the anomaly was noticed. That means NHI programmes need ownership, scope, and revocation to work together, or the first sign of compromise will already be a data loss event. Practitioners should align response speed with delegated access risk.

Salesloft-style supply chain breaches collapse the assumption that a trusted integration behaves predictably once issued. That assumption was designed for stable, human-reviewed access paths. It fails when the actor is an NHI that can be replayed from a new client context and used for high-volume extraction without changing the underlying entitlement. The implication is that identity governance must stop treating delegated trust as static after provisioning.

Identity blast radius is the right named concept for this pattern. A single compromised token can radiate through many connected instances because the true unit of exposure is the downstream permission surface, not the original token itself. That is why ownership, least privilege, and immediate revocation need to be measured at the integration boundary. Practitioners should manage the blast radius, not just the secret.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why compromised delegated access is often discovered too late to prevent downstream abuse.
• That visibility gap is one reason to pair identity governance with 52 NHI Breaches Analysis so teams can compare this incident pattern against prior real-world compromises.

What this signals

Identity teams should treat delegated OAuth access as a live production dependency. Once a connected app token is in circulation, the practical risk is not whether it was issued correctly but whether it can still be trusted after the environment around it changes. The right operational model is continuous ownership, behavioural baselining, and immediate revocation when the token no longer fits its own profile.

Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to our Ultimate Guide to NHIs. That gap becomes acute in SaaS supply chains, where third-party connectivity multiplies the number of places a stolen credential can be replayed. The programme signal is clear: if offboarding is still manual, the organisation is accepting avoidable exposure.

Blast-radius control is becoming a central design principle for NHI governance. The broader your connected app permissions, the more likely one compromised token can move from a local identity issue to a multi-tenant data event. Teams that want to reduce that exposure should align least privilege, owner accountability, and rapid containment with the actual downstream systems each identity can reach.

For practitioners

• Inventory all connected app tokens as owned NHIs Map each OAuth token, API key, and service credential to a human owner, business purpose, and explicit revocation path so integrations do not become anonymous trust channels.
• Baseline normal NHI behavior by source and API mix Track client IPs, request frequency, and endpoint usage per identity so a new source or a sudden shift in call patterns can be detected as identity drift.
• Tie anomaly detection to immediate containment Automate privilege shutdown and token revocation when a delegated credential shows bulk extraction behavior, because manual review happens too late once replay begins.
• Review third-party integration scopes against actual data access Compare granted permissions to the minimum required for the integration’s live workload, then remove dormant scopes that widen the blast radius if the token is stolen.

Key takeaways

• The breach shows that a compromised OAuth token can function as the real attack surface in a supply chain incident.
• The scale of the remediation gap is stark, because stolen secrets often stay valid long enough for attackers to use them repeatedly.
• Teams should focus on ownership, behavioural detection, and instant revocation if they want to shrink NHI blast radius.

Key terms

• Connected app token: A connected app token is a delegated credential that lets one system call another on behalf of an approved integration. In NHI governance, it must be treated as a production identity because its scope, ownership, and revocation determine how far a compromise can spread.
• Behavioral baselining: Behavioral baselining is the practice of learning how an identity normally acts so deviations can be detected quickly. For non-human identities, the baseline often includes source IPs, API mix, request frequency, and data access volume rather than human login patterns.
• Identity blast radius: Identity blast radius is the amount of downstream access exposed when a credential, token, or account is misused. It is a useful way to measure delegated trust because one compromised NHI can affect many systems, tenants, or records if permissions are broad.
• Delegated access: Delegated access is permission granted to one identity to act within another system without re-authenticating for every request. It is common in SaaS and cloud integrations, which makes governance depend on ownership, least privilege, and the ability to revoke trust immediately when behaviour changes.

What's in the full article

Andromeda Security's full research covers the operational detail this post intentionally leaves for the source:

• The article shows how Andromeda baselines client IPs and API usage patterns for each NHI.
• It explains the automated response sequence used after detecting a new client IP and abnormal behaviour.
• It describes how zeroing out permissions and revoking the token are combined to stop further misuse.
• It frames the Salesloft incident as a practical example of identity-based supply chain defence.

👉 Andromeda Security's full post covers the token compromise, anomaly detection logic, and containment steps in detail.

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.