Token theft is widening the attack path in SaaS supply chains

At a glance

What this is: This analysis argues that stolen access tokens have become a hidden supply chain risk because they can be reused across connected SaaS and AI systems with broad, persistent permissions.

Why it matters: For IAM and NHI practitioners, token theft matters because app-to-app trust often outlives the users, projects, and controls that created it.

By the numbers:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Wing Security's analysis of token theft in SaaS supply chains

Context

Token theft is an identity problem, not just a data problem. In SaaS and AI-integrated environments, access tokens often carry delegated authority across services, so a stolen token can function like a standing credential even when passwords and MFA are intact. That makes token lifecycle control part of NHI governance, because the real risk sits in app-to-app trust and the permissions attached to it.

The article’s central claim is that traditional perimeter and endpoint tools do not see enough of this layer to stop abuse early. That is a familiar pattern in NHI security: the connection is legitimate, the token looks valid, and the abuse only becomes visible after lateral movement or data exfiltration has already started. For teams, the starting assumption that integrations are inherently safe is increasingly untenable.

Key questions

Q: How should security teams handle token theft in SaaS environments?

A: Treat tokens as delegated non-human identities, not disposable implementation details. Inventory them, assign ownership, restrict scope, and automate revocation for stale or over-privileged access. Then monitor token use for unusual source systems, unusual locations, and unexpected downstream access chains so replayed credentials are caught before they spread.

Q: Why do stolen access tokens bypass MFA risk controls?

A: Because the attacker is often not authenticating at all. They are replaying a credential that was already issued and accepted, so MFA is not part of the second transaction. That makes token lifecycle, revocation speed, and scope control more important than the authentication ceremony that created the token.

Q: What is the difference between a password compromise and token theft?

A: A password compromise usually targets the person or account login path, while token theft targets delegated authority that can already be trusted by downstream apps. The practical difference is that a token can carry app-specific permissions and survive user changes, which makes it harder to notice and easier to reuse silently.

Q: When does token sprawl become a governance problem?

A: When the organisation can no longer answer who owns each token, what it can reach, when it expires, and how it is revoked. At that point token sprawl is no longer a tooling issue. It is a governance failure that expands the attacker’s blast radius across SaaS and AI workflows.

Technical breakdown

Why OAuth tokens behave like non-human identities

OAuth and similar tokens are delegated credentials. They let one application act on behalf of a user, service, or workload without re-authenticating every time, which is why they are so useful in SaaS ecosystems. The security trade-off is that the token often inherits the original trust boundary and scope, even after the user who authorised it has changed roles or left. If revocation is weak, a token can remain a live identity long after the business context has vanished. In practice, this turns token inventory into identity inventory, and unmanaged tokens become standing NHI risk.

Practical implication: Inventory tokens with the same discipline used for service accounts and revoke stale delegated access on a fixed cadence.

How token theft becomes lateral movement

A stolen token can bypass MFA because the attacker is not logging in as a person, they are replaying an already-authorised credential. If the token has broad scopes, the attacker can move from one SaaS app to another through linked integrations, API permissions, and backend automation. This is why app-to-app compromise often appears as legitimate system activity. The danger grows when tokens are reused across workflows, copied into automation, or never tied to a clear owner. In NHI terms, the blast radius is determined by scope, trust relationships, and revocation speed, not by the number of passwords in the environment.

Practical implication: Map token scope and downstream dependencies before you can estimate the blast radius of any single compromise.

Why traditional controls miss token abuse

CASB, endpoint, and identity provider tooling can reduce exposure, but they are not always built to observe every token exchange across distributed SaaS and AI workflows. Many integrations happen outside the line of sight of central IAM teams, especially where shadow AI or ad hoc automation is involved. That creates a gap between authentication events and real authority in the environment. The practical failure mode is not always theft at first use. It is the existence of dormant, over-privileged, or forgotten tokens that remain available to an attacker once one trust relationship is compromised.

Practical implication: Add token telemetry, ownership, and anomaly detection to the same control plane used for other NHI credentials.

Threat narrative

Attacker objective: The attacker’s objective is to turn one trusted integration into a reusable access path that exposes multiple downstream systems and secrets.

1. Entry via compromised OAuth tokens stolen from a trusted SaaS integration.
2. Escalation through token reuse across linked customer environments and connected services.
3. Impact through exfiltration of access keys, passwords, and other secondary secrets that expand the attacker’s reach.

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

Token theft is now an NHI governance problem, not a niche SaaS issue. A token is a non-human credential with delegated authority, persistent scope, and a lifecycle that often escapes ordinary access review. Once organizations accept that, token theft stops looking like an edge-case and starts looking like a control-plane failure. The right response is to govern tokens as first-class identities with ownership, scope limits, and revocation.

Application-layer trust creates the identity blast radius. In connected SaaS and AI environments, the attacker rarely needs to defeat primary authentication if a valid integration token already exists. The blast radius depends on which apps trust each other, how broadly the token was scoped, and whether the organisation can revoke it fast enough to matter. Practitioners should treat integration mapping as a prerequisite to access governance.

Dormant authority is the real weakness. Tokens frequently outlive the people, projects, or automations that created them, which means the organisation continues to carry access it no longer understands. That is a textbook NHI risk: high privilege, low visibility, and weak lifecycle enforcement. Security teams should prioritise cleanup of forgotten tokens before they invest in more alerting.

Shadow AI increases the number of unreviewed token paths. As new automation and AI tools are connected into SaaS workflows, teams create more machine-to-machine trust faster than they can inventory it. That expands the attack surface even when the underlying applications look well managed. The practical conclusion is simple: discover, classify, and review every token-bearing integration before it becomes attacker infrastructure.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• Internal repositories are 6x more likely to contain secrets than public ones, with 32.2% versus 5.6% exposure, according to The State of Secrets Sprawl 2026.
• For the broader control picture, see 52 NHI Breaches Analysis for how credential misuse turns into repeatable breach patterns.

What this signals

Token theft will keep bypassing program boundaries until teams treat app-to-app access as governed identity. The practical shift is toward continuous ownership, expiry, and revocation for every token-bearing integration. As SaaS and AI workflows expand, organisations that do not map their downstream trust chains will keep discovering the problem only after lateral movement has already occurred.

Identity blast radius: the measurable spread between a stolen token and the systems it can touch. Once teams start modelling that radius, they can prioritise the integrations that need tighter scopes, faster revocation, and stronger monitoring. This aligns directly with the access-control discipline described in the Top 10 NHI Issues.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the governance question is no longer whether machine-to-machine trust exists, but whether it is visible and revocable. Teams that link token inventory to the OWASP Non-Human Identity Top 10 will be better placed to classify which integrations deserve emergency controls.

For practitioners

• Discover all token-bearing integrations Build an inventory of every SaaS, API, and AI integration that uses OAuth or similar delegated access. Include shadow AI, service accounts, and automation created outside central IAM so you can see where app-to-app authority actually exists.
• Tighten token scope and ownership Require a named business owner, least-privilege scopes, and explicit expiry for every new token. Remove broad default permissions and force periodic re-approval for integrations that can reach sensitive systems.
• Automate revocation for stale or dormant tokens Set rules to revoke tokens that are unused, orphaned, or tied to decommissioned workflows. Tie revocation to offboarding, project closure, and integration replacement so old authority does not linger.
• Monitor token activity for lateral movement patterns Alert on unusual token use such as new geographies, new source apps, atypical API calls, and access chains that do not match the original workflow. Treat token telemetry as part of your detection baseline, not as an optional add-on.
• Map integration blast radius before incidents occur Document which downstream systems each token can reach, then use that map to prioritise monitoring and emergency revocation playbooks. If one token can touch multiple business-critical environments, its control level should match that reach.

Key takeaways

• Token theft is dangerous because it turns delegated app-to-app trust into a reusable access path across SaaS and AI systems.
• Visibility alone is insufficient if tokens remain valid after their business purpose ends or their owners change.
• The strongest near-term control is not another perimeter layer, but disciplined token inventory, scope reduction, and fast revocation.

Key terms

• Access Token: A token is a delegated credential that allows one application or service to act on behalf of a user or workload. In practice, it can carry scopes, expiry, and downstream permissions, which means it must be governed like any other non-human identity with ownership and lifecycle controls.
• Token Sprawl: Token sprawl is the accumulation of too many active, forgotten, or overlapping tokens across SaaS and automation workflows. It creates visibility gaps, increases the chance of over-privilege, and makes revocation slow when an incident forces a response.
• Identity Blast Radius: Identity blast radius is the extent of systems, data, and workflows an attacker can reach after compromising one identity or token. For non-human identities, it is shaped by scopes, trust relationships, and revocation speed rather than by a single account boundary.
• Shadow AI: Shadow AI is the use of AI tools, agents, or automations that have not been discovered, approved, or governed by the organisation. These systems often create hidden tokens and integration paths that expand the non-human identity attack surface without central oversight.

Deepen your knowledge

Token theft, token lifecycle control, and delegated access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a program around SaaS and AI integrations, it is worth exploring.

This post draws on content published by Wing Security: Token Theft, the Hidden Risk Fueling Modern Supply Chain Breaches. Read the original.