Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

SaaS integrations and standing privilege: what IAM teams missed


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9059
Topic starter  

TL;DR: A compromised abandoned test credential in Klue let attackers harvest OAuth tokens and reach dozens of customer Salesforce environments, affecting more than two dozen companies, according to Akeyless. The incident shows that every SaaS integration is a non-human identity with lifecycle risk, and standing privilege turns trusted access into a downstream breach path.

NHIMG editorial — based on content published by Akeyless covering the Klue breach and SaaS integration risk

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.

Questions worth separating out

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.

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.

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.

Practitioner guidance

  • 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.
  • Revoke abandoned and ownerless access paths Tie credential decommissioning to project closeout, vendor offboarding, and integration retirement.
  • 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.

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.

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

SaaS integrations and standing privilege: what IAM teams missed?

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 8498
 

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.

A few things that frame the scale:

  • 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.

A question worth separating out:

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.

👉 Read our full editorial: Klue breach shows why SaaS integrations need NHI governance



   
ReplyQuote
Share: