Shadow AI supply chain risk is widening the NHI attack surface

At a glance

What this is: This analysis argues that supply chain attacks now intersect with Shadow AI, creating hidden app-to-app trust paths that can expose tokens, credentials, and customer data.

Why it matters: IAM and NHI teams need to govern third-party integrations and autonomous tools as persistent identity risk, not as isolated application features.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Wing Security's analysis of supply chain attacks and Shadow AI

Context

Supply chain risk has shifted from isolated vendor compromise to identity-driven expansion across SaaS apps, integrations, and AI assistants. In practical terms, every OAuth connection, refresh token, and delegated app permission becomes part of the non-human identity surface that security teams must govern.

The article uses the Salesloft-Drift breach to show how a compromised integration can cascade into customer environments when visibility is thin and tokens remain powerful for too long. That is a typical pattern for modern NHI risk, not an edge case, because unmanaged app-to-app trust is now common in enterprise workflows.

Key questions

Q: How should security teams govern SaaS integrations that use OAuth tokens?

A: Security teams should treat OAuth integrations as non-human identities with defined scopes, lifetimes, and revocation paths. Approval should require least privilege, documented business purpose, and periodic revalidation. If a token can reach sensitive systems, it needs the same governance discipline as any privileged service account. The key control is not trust in the app, but control over the authority the app receives.

Q: Why does Shadow AI create more risk than ordinary shadow IT?

A: Shadow AI can execute actions, call APIs, and move data without direct human supervision, which turns a hidden tool into an active identity. That increases risk because the tool may hold persistent tokens, connect to sensitive systems, and operate outside normal inventory and approval processes. Ordinary shadow IT is a visibility problem. Shadow AI is a visibility and authority problem.

Q: What is the difference between app visibility and identity visibility in SaaS security?

A: App visibility tells you which tools exist. Identity visibility tells you which tools can act, what they can access, and how far that authority reaches. For NHI governance, identity visibility is the stronger control because a small number of integrations can have broad, persistent access even when the application inventory looks complete.

Q: How can organisations reduce blast radius after a third-party integration compromise?

A: Organisations should predefine revocation paths, segment token scopes, and maintain a connection map that shows which systems each integration can reach. That lets teams disable the right access quickly instead of searching tenant by tenant after a compromise. The goal is to shrink the time between detection and token invalidation.

Technical breakdown

How OAuth tokens become the control plane for shadow integrations

OAuth and refresh tokens are the practical trust layer for many SaaS integrations and AI assistants. Unlike passwords, they often persist after the user forgets the app exists, and they can authorize machine-to-machine access without repeated prompts. If the token scope is broad, the token holder inherits that broad access until revocation or expiration. That makes the integration itself a non-human identity with real authority. When attackers steal the token, they do not need to defeat primary authentication again. They operate through the trust the enterprise already granted to the app.

Practical implication: Review token scope, lifetime, and revocation paths as part of every integration approval and access review.

Why shadow AI increases identity sprawl in SaaS environments

Shadow AI is not just unsanctioned software. It is unsanctioned execution authority that can connect to data sources, process content, and expose secrets through embedded integrations. The risk is not limited to the tool itself. It includes the permissions chain behind it, especially when employees connect assistants to email, CRM, storage, or code systems with default or inherited access. In that model, the AI tool becomes a new identity broker, often outside normal IAM governance and asset inventory. The result is hidden trust relationships that outlive the business need that created them.

Practical implication: Treat every AI assistant integration as a governed identity relationship, not a productivity shortcut.

How lateral exposure happens after a third-party compromise

Once an attacker compromises a third-party app, the next step is usually pivoting through connected systems that trust it. In SaaS ecosystems, that often means data export, token reuse, or permission chaining rather than traditional network movement. This is why app-to-app maps matter. Security teams need to see which integrations can touch which tenants, which resources, and which secrets. Without that graph, one compromise can create a long and opaque blast radius across multiple customer environments.

Practical implication: Build and maintain connection maps that show where third-party identity trust can reach sensitive systems.

Threat narrative

Attacker objective: The attacker objective is to turn a trusted SaaS integration into a reusable access path for stealing credentials and sensitive customer data.

1. Entry via compromised OAuth and refresh tokens tied to the Drift integration with Salesforce.
2. Escalation through authorized access to customer Salesforce environments and connected resources.
3. Impact through exfiltration of AWS access keys, passwords, and Snowflake tokens from downstream environments.

Breaches seen in the wild

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

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

NHI Mgmt Group analysis

Shadow AI turns SaaS governance into identity governance. The article is strongest when it frames integrations and AI assistants as access paths rather than features. That is the correct mental model for NHI risk, because the issue is who or what can act with authority, not which user interface is attached to it. Security programs that still separate SaaS, automation, and AI oversight will miss the actual control plane.

Compromised integrations create identity blast radius, not just data exposure. Once OAuth or refresh tokens are in circulation, the relevant question is how far those tokens can reach and how quickly they can be revoked. The breach pattern described here shows that one trust relationship can fan out across many customer systems. Practitioners should treat blast radius as a measurable governance variable, not an after-action metric.

App-to-app trust is now part of the enterprise attack surface. Traditional SaaS inventories that list applications but not their delegated permissions are incomplete for NHI governance. The enterprise needs a view of which identities can call which APIs, what scopes they hold, and how long they persist. Without that, policy cannot follow execution.

Persistent token authority is a stronger risk signal than app popularity. Security teams often prioritize the most visible applications, but the more relevant control is the set of permissions and lifetimes behind them. A small, unsanctioned assistant with broad token scope can be more dangerous than a well-known sanctioned app with tight controls. Governance should follow authority, not brand recognition.

Shadow AI is accelerating the need for continuous identity discovery. The market is moving toward a world where users can bind tools, models, and data sources with minimal friction. That makes static inventories obsolete quickly. The practical conclusion is simple: discover, classify, and review every non-human identity continuously or accept blind spots as normal.

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.
• That fragmentation makes continuous discovery and access review the practical next step, as described in Top 10 NHI Issues.

What this signals

Shadow AI is likely to accelerate identity sprawl faster than most IAM programmes can inventory it. The control gap is not only that employees adopt new tools, but that those tools inherit authority through tokens and delegated permissions. With 43% of security professionals already concerned about AI systems learning and reproducing sensitive information patterns from codebases, per The State of Secrets in AppSec, the programme risk is now both access and leakage.

Identity blast radius becomes the metric to watch. Once integrations can reach CRM, cloud, storage, and developer systems, the question is how far one compromised token can travel before containment. Teams should build revocation playbooks around connected systems, not around individual app names.

Security leaders should expect more third-party and AI integration reviews to land in the same governance queue as service accounts and API keys. That convergence is healthy, because the underlying risk is the same: persistent machine authority that outlives the operator’s awareness.

For practitioners

• Implement continuous discovery for SaaS and AI integrations Inventory sanctioned and unsanctioned apps, then map every connection to data sources, APIs, and secret-bearing workflows. Reconcile that view with identity governance records so hidden integrations are not excluded from review.
• Constrain OAuth scope and token lifetime Require least-privilege scopes, short-lived tokens where possible, and explicit revocation workflows for third-party apps. Review refresh token retention and rotate or revoke access when the business need changes.
• Map app-to-app blast radius Track which integrations can reach CRM, email, storage, code repositories, and cloud accounts. Use that map to prioritize protections around the systems that would expose the most sensitive secrets if compromised.
• Add Shadow AI to governance reviews Extend security questionnaires and approval workflows to AI assistants that connect to enterprise data, especially where employees can self-approve or import tokens. Require ownership, purpose, and expiration criteria for each integration.

Key takeaways

• Supply chain compromise now overlaps with Shadow AI, which makes delegated access a first-class identity risk.
• OAuth tokens, refresh tokens, and hidden integrations create blast radius that conventional app inventories do not capture well.
• Continuous discovery, token scoping, and fast revocation are the controls that matter most when third-party trust is compromised.

Key terms

• Shadow AI: Shadow AI is the use of AI tools, assistants, or agentic integrations outside formal security oversight. In practice, it creates hidden access paths because the tool may hold tokens, connect to enterprise data, and act with authority that is never fully inventoried or reviewed.
• OAuth Token: An OAuth token is a delegated credential that allows an application to access resources without a user re-entering a password. In NHI governance, the important control questions are scope, lifetime, revocation, and whether the token can reach systems that contain sensitive data.
• Identity Blast Radius: Identity blast radius is the amount of downstream access a compromised identity can reach before containment. For non-human identities, it depends on token scope, connection depth, and how quickly teams can revoke or segment access once misuse is detected.
• App-to-app Trust: App-to-app trust is the set of permissions and delegated relationships that allow one software system to act on behalf of another. It is a core NHI risk because it often persists longer than the original business need and is rarely visible in basic application inventories.

Deepen your knowledge

Shadow AI governance and delegated token control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to bring SaaS integrations and AI assistants under identity control, the course provides a practical starting point.

This post draws on content published by Wing Security: Supply chain attacks meet Shadow AI. Read the original.