Klue breach shows why SaaS integrations need NHI governance

At a glance

What this is: Akeyless analyses the Klue breach as a SaaS supply-chain incident driven by an abandoned test credential and stolen OAuth tokens.

Why it matters: It matters because IAM, PAM, and NHI teams must treat third-party integrations as governed identities, not static plumbing, when they touch customer data and CRM systems.

By the numbers:

• The 2026 State of AI Agent Identity Security Report found that 69% of organizations still authenticate machine identities with long-lived API keys.

👉 Read Akeyless's analysis of the Klue breach and SaaS integration risk

Context

SaaS integrations become identity risk when they hold credentials that outlive the project, owner, or purpose they were created for. In this case, the primary issue is not Salesforce itself, but the non-human identity attached to a trusted integration path that remained active after the prototype was abandoned.

That matters for NHI governance because OAuth tokens, API keys, service accounts, and certificates all create delegated authority that can persist long after business need has ended. Once those credentials are shared across vendors and cloud services, one stale integration can expose multiple downstream environments at once.

Key questions

Q: What breaks when a SaaS integration credential is left active after a project ends?

A: The credential becomes standing privileged access that no longer has a legitimate business owner. Attackers do not need to break the application itself if they can replay a valid token or secret through a trusted integration path. That is why lifecycle offboarding, expiry, and revocation are as important as initial provisioning.

Q: Why do OAuth tokens create so much risk in third-party integrations?

A: OAuth tokens let one service act on behalf of another, so the token inherits the trust of the integration that holds it. If the token is broad, long-lived, or stolen, an attacker can use the delegated authority exactly as the system was designed to use it. The risk is not OAuth itself, but weak scope and lifecycle control.

Q: How do security teams know when an integration has become an unmanaged identity?

A: An integration has become unmanaged when no one can name the owner, business purpose, expiry date, or revocation process. If a credential can still authenticate after the project has ended, it is an identity that outlived governance. Watch for dormant tokens, orphaned test secrets, and excessive API permissions.

Q: Who is accountable when a vendor-held token exposes customer data?

A: Accountability is shared, but the customer still owns the decision to trust the integration and scope its access. The vendor is responsible for secure handling, rotation, and revocation of its credentials, while the customer must govern what the token can reach and how often that trust is reviewed.

Technical breakdown

Abandoned integration credentials become standing NHI access

The entry point was a test credential created for an integration prototype and left active after the project was abandoned. That is a classic lifecycle failure: the credential remained valid even though the business purpose disappeared. In NHI terms, the problem is not merely that a secret existed, but that its authority was never tied to a hard expiry, owner change, or automated decommissioning event. Once a credential is valid, any system that trusts it will treat the holder as legitimate until revocation or expiration occurs.

Practical implication: tie every integration credential to explicit ownership, expiry, and offboarding so abandoned access cannot persist.

OAuth tokens turn trusted integrations into downstream access paths

OAuth tokens are delegated credentials, which means they let one system act on behalf of another within a defined scope. In this breach, the stolen tokens inherited the trust of the Klue integration and were accepted by customer SaaS platforms as valid proof of identity. That is why the attacker did not need to defeat MFA or compromise Salesforce directly. The token was the authentication event, and the customer CRM systems had no reason to distinguish legitimate automation from malicious replay once the token was accepted.

Practical implication: constrain token scope, shorten token lifetime, and monitor delegated API use for bulk or unusual patterns.

Integration-layer compromise shifts the blast radius to customer environments

The impact came from the integration layer, not from a core SaaS platform vulnerability. Once the malicious code update harvested customer tokens, automated scripts could query CRM data at scale for roughly 24 hours. That pattern is common in SaaS supply-chain attacks: the trusted vendor becomes the bridge into many enterprises simultaneously. The security boundary is therefore no longer the application perimeter. It is the lifecycle and scope of the identities that connect one service to another.

Practical implication: govern third-party integrations as part of your identity boundary, not as a separate application-support problem.

Threat narrative

Attacker objective: The objective was to inherit trusted integration access and use it to extract customer sales and CRM data at scale.

1. Entry occurred through a legacy test credential that remained active after the integration prototype was abandoned.
2. Credential access followed when attackers used the compromised credential to obtain OAuth tokens for third-party platforms connected to Klue.
3. Impact came when the tokens were replayed through trusted SaaS APIs to exfiltrate customer CRM data from dozens of environments.

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

Stale integration credentials are not technical debt, they are standing identity liabilities. The Klue incident shows what happens when a prototype credential survives its intended lifecycle and remains trusted by downstream services. That is a governance failure in ownership, expiry, and decommissioning, not just a secret-management lapse. The practitioner lesson is that dormant integration credentials must be treated as active attack surface until proven otherwise.

OAuth delegation creates a trust chain that attackers can inherit without breaking the target platform. Once the token was valid, the customer SaaS platforms had no reason to reject the requests, because the authentication event looked legitimate. This is why integration governance cannot stop at the vendor boundary. The real control question is whether delegated access is narrow, time-bound, and continuously attributable across every connected environment.

Identity blast radius expands every time a vendor-held credential is reused across customer environments. A single compromised integration can become the access path into dozens of enterprises, which is why the unit of governance has to be the credential lifecycle, not the application logo. The more business processes depend on connected SaaS tools, the more important it becomes to model downstream authority as a first-class identity risk. Practitioners should reclassify trusted integrations as governed NHI assets.

Secret sprawl challenge: this breach reflects the same failure mode seen whenever credentials outlive the project that created them. Test tokens, abandoned integrations, and ownerless secrets accumulate because manual lifecycle controls do not scale to modern SaaS ecosystems. The implication is not simply to add more scanning, but to stop treating non-human identities as one-time setup objects.

Standing privilege in third-party integrations is now a board-level exposure issue. The article’s own attack chain shows that one persistent credential can bridge multiple enterprise environments, creating a shared-risk event across customers. That changes the governance conversation from local hygiene to systemic supplier oversight. Security leaders need to know which integrations can still act on their behalf after the original business need has ended.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For a broader control lens, review Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and sprawl problems that make stale credentials hard to eliminate.

What this signals

Secret sprawl challenge: SaaS integrations behave like long-tail NHI assets once they accumulate delegated access, and the governance model has to change accordingly. When 43% of security professionals are already worried about AI systems learning and reproducing sensitive information patterns from codebases, the boundary between human-built software, machine identity, and downstream exposure is getting harder to defend.

The practical signal for IAM teams is that integration inventory is now a security control, not an administrative task. If you cannot answer who owns a token, when it expires, and what it can reach, the identity programme is already behind the actual attack surface.

For practitioners

• Inventory every SaaS integration credential Map OAuth grants, API keys, service accounts, certificates, and test tokens attached to Salesforce, CRM, and other high-value platforms. Classify anything without a named owner, expiry, or business purpose as removable until proven necessary.
• Revoke abandoned and ownerless access paths Tie credential decommissioning to project closeout, vendor offboarding, and integration retirement. If a prototype or pilot is dead, the credential should be dead with it.
• Reduce delegated scope and token lifetime Trim OAuth scopes to the smallest workable set and set short expiry for any token that can reach customer or financial data. Broad, long-lived tokens turn replay into extraction.
• Add API-layer abuse detection Alert on bulk queries, unusual export volume, and automation patterns that do not match normal integration behaviour. Logging must sit where delegated access is exercised, not only where it is granted.

Key takeaways

• The Klue breach shows that an abandoned test credential can become a live bridge into customer environments when lifecycle controls fail.
• The impact was amplified by delegated OAuth trust, which let attackers use valid tokens to reach dozens of enterprise Salesforce tenants.
• Teams should treat third-party integrations as governed identities, with ownership, expiry, scope, and offboarding enforced as core controls.

Key terms

• OAuth Token: An OAuth token is a delegated credential that lets one system act on behalf of another within a defined scope. In practice, it is proof of identity for an integration, so its lifetime, scope, and revocation path determine how much access an attacker can inherit if the token is stolen.
• Standing Privilege: Standing privilege is access that remains valid beyond the immediate task or business need. For non-human identities, it often appears as long-lived API keys, tokens, or service accounts that continue to authenticate even after the project, owner, or integration purpose has changed.
• Secret Lifecycle: Secret lifecycle is the full path from secret creation through use, rotation, expiry, and decommissioning. It matters because credentials that outlive their purpose become attack surface, especially when they are embedded in SaaS integrations or shared across connected environments.
• Delegated Access: Delegated access is authority one service receives from another to perform actions within a defined boundary. When that boundary is too broad or too long-lived, the delegated identity can be replayed by an attacker to reach downstream systems that trust the original integration.

What's in the full article

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

• A step-by-step breakdown of the Klue attack chain and the customer environments affected.
• Specific comparisons between dynamic secrets, zero standing privilege, and secretless authentication for SaaS integrations.
• A practical checklist for auditing OAuth grants, rotating vendor-held tokens, and reducing scope across connected platforms.
• Implementation detail on multi-vault governance and distributed fragments cryptography for long-lived integration risk.

👉 Akeyless's full post covers the attack chain, affected customer environments, and mitigation steps.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.