SaaS supply chain attacks are exposing NHI governance gaps

At a glance

What this is: This analysis argues that SaaS supply chain risk now sits in connected identities, not just the applications teams directly administer.

Why it matters: It matters because IAM and NHI teams need visibility and control over OAuth grants, service accounts, and AI-driven integrations that inherit access outside normal review cycles.

By the numbers:

• According to Obsidian Security's network data, the number of SaaS integrations and AI agents created have increased by 123% and 223% respectively.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 2025 supply chain attack compromised 59% of machines, ines in CI/CD runners rather than personal workstations.

👉 Read Obsidian Security's analysis of SaaS supply chain attacks and NHI exposure

Context

SaaS supply chain security is the problem of controlling trust between connected applications, tokens, and automated workflows that can act without human login events. In this article, that matters for NHI governance because OAuth grants, API keys, service accounts, and AI agents now create access paths that traditional perimeter controls do not reliably see.

The article frames a real operational shift: attackers increasingly exploit a partner, integration, or overlooked credential rather than the primary target. That pattern is now typical in modern SaaS estates, where inherited permissions and shadow integrations expand the blast radius beyond the team that originally approved access.

Key questions

Q: How should security teams govern SaaS integrations that inherit broad access?

A: Treat each integration as a non-human identity with its own lifecycle, owner, and scope. Review the effective permissions after inheritance, not just the initial approval. Then enforce rotation, reauthorization, and revocation rules so the integration cannot keep access after the business need changes.

Q: When does OAuth create more risk than it reduces in SaaS environments?

A: OAuth becomes high risk when scopes are broad, tokens are long-lived, and the organization cannot see how the credential is reused across connected apps. At that point, convenience outweighs control, and a stolen token can preserve trusted access without repeated authentication.

Q: What is the difference between shadow SaaS and approved SaaS integrations?

A: Approved integrations are reviewed, owned, and placed under policy control. Shadow SaaS appears when employees connect apps without oversight, often creating hidden access paths and untracked data movement. The distinction matters because unmanaged integrations can inherit permissions that security teams never intended to grant.

Q: Why do non-human identities complicate SaaS supply chain defense?

A: Non-human identities often bypass interactive login controls, accumulate persistent permissions, and operate continuously across systems. That makes them harder to inventory and harder to revoke quickly. A SaaS supply chain defense program must manage these identities as live access relationships, not static configuration items.

Technical breakdown

How SaaS trust chains turn OAuth grants into lateral movement

SaaS integrations often work by delegating access through OAuth scopes, refresh tokens, and service accounts that can act on behalf of a user or application. The technical weakness is not OAuth itself, but the combination of delegated trust, long token lifetimes, and poor visibility into where tokens are reused. Once a token or app registration is compromised, the attacker does not need to break authentication again to move across connected SaaS services. That is why SaaS supply chain incidents frequently look like legitimate API traffic until downstream abuse becomes visible.

Practical implication: Practitioners should map every delegated trust path and treat token reuse as an active control problem, not a one-time approval event.

Why over-permissioned service accounts and API keys create persistent exposure

Service accounts and API keys are NHI forms that often persist well beyond the task they were created for. In SaaS environments they are attractive because they bypass repeated user authentication, but that same durability makes them difficult to monitor and revoke when business ownership changes. When permissions are inherited, broad, or left unreviewed, a single compromise can grant access to data, admin functions, and adjacent integrations. This is the architectural reason supply chain breaches can spread quietly across multiple SaaS systems.

Practical implication: Teams should inventory standing NHI privileges in SaaS and tie every credential to an owner, purpose, and expiry condition.

Shadow SaaS and AI agents expand the unmanaged identity surface

Shadow SaaS appears when users connect applications without formal review, while AI agents extend the problem by chaining actions across tools with broad delegated access. The key technical issue is that these identities often sit outside normal joiner-mover-leaver processes and security telemetry, so they can inherit access that was never designed for autonomous use. As more workflows become programmatic, the boundary between human-approved access and machine-executed access becomes less clear. That weakens both governance and detection.

Practical implication: Security teams need discovery controls that identify unmanaged integrations and AI agents before they inherit production permissions.

Threat narrative

Attacker objective: The attacker wants durable, trusted access across multiple SaaS systems without triggering normal login or perimeter alerts.

1. Entry via a compromised vendor, integration, or leaked OAuth token that rides existing SaaS trust relationships.
2. Escalation through inherited permissions, stale refresh tokens, or over-permissioned service accounts that expose broader application access.
3. Impact through data exfiltration, policy manipulation, and cross-application movement across connected SaaS environments.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

SaaS supply chain risk is really NHI trust debt. The central issue is not how many apps are connected, but how much standing trust those connections inherit over time. OAuth grants, service accounts, and API keys accumulate authority faster than most governance programs can review it. Practitioners should treat every delegated connection as a controllable identity, not a convenience layer.

Ephemeral login controls do not solve persistent machine trust. Rotating human credentials or tightening MFA does little if long-lived tokens and service principals remain in place. The real governance gap is lifecycle control for non-human identities, including approval, scope review, rotation, revocation, and ownership reassignment. Teams that ignore that lifecycle end up with access that is technically valid but operationally unaccounted for.

SaaS visibility without effective permission analysis is incomplete. Discovery alone is not enough if security teams cannot tell which integrations inherited admin-level or cross-object permissions. That is where SaaS supply chain attacks become hard to distinguish from legitimate automation. Practitioners should build controls around effective access, not just app inventory.

AI agents make SaaS supply chain governance more urgent, not less. Agents are another class of non-human identity, but they add action chaining and broad context access to an already fragile trust model. That means the category is moving toward identity blast radius problems, where one compromised integration can fan out into many systems. Practitioners should assume agentic workflows inherit the same weaknesses as SaaS-to-SaaS links unless explicitly bounded.

OWASP NHI Top 10 thinking fits this problem better than legacy app-security models. Secret sprawl, overprivilege, and third-party trust are the recurring failure modes here, not just application vulnerabilities. A program that focuses only on endpoints or network controls will miss the identity layer where the breach actually propagates. Security teams should align SaaS governance to NHI-specific risk categories rather than general cloud hygiene.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For a broader control lens, see OWASP NHI Top 10 for the most relevant NHI and agentic application risks.

What this signals

Identity blast radius is the right operating concept for SaaS supply chain defense. Once one integration can reach multiple downstream systems, the practical question becomes how far a compromised token can travel before detection or revocation. That is why SaaS governance needs ownership, scope, and expiry controls, not just discovery workflows.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the broader lesson is that machine-access credentials are being created faster than teams can classify them. The same pattern applies in SaaS, where programmatic trust expands faster than review cycles can follow.

Teams should align SaaS integration governance with the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 so discovery, protection, detection, response, and recovery all cover non-human access paths.

For practitioners

• Inventory every delegated SaaS trust path Map OAuth apps, API keys, service accounts, and shadow integrations to the business process they enable. Include cross-tenant and third-party connections so you can see which non-human identities can reach sensitive data or admin functions.
• Enforce ownership and expiry for non-human identities Assign a named owner, approved scope, and expiry condition to each credential or integration. Where the platform allows it, replace standing access with just-in-time access and documented reauthorization checkpoints.
• Review effective permissions, not just approved apps Check what an integration can actually do after inheritance, nested roles, and default scopes are applied. This is the fastest way to find over-permissioned SaaS links before they become lateral movement paths.
• Detect token abuse with cross-app telemetry Correlate authentication events, token refresh patterns, and unusual API activity across SaaS boundaries. If you only watch the source app, you will miss the downstream use of a stolen token or service account.

Key takeaways

• SaaS supply chain attacks succeed because trusted integrations often carry more access than teams realise.
• The scale problem is structural, with integrations and AI agents growing faster than most governance programs can review them.
• Practitioners should move from app-centric oversight to lifecycle control for every non-human identity that can act across SaaS systems.

Key terms

• SaaS Supply Chain Attack: A SaaS supply chain attack is an intrusion path that uses trusted integrations, tokens, or third-party services to reach a target environment indirectly. The attacker relies on inherited trust between applications rather than breaking the main system first, which makes detection and containment harder.
• Non-Human Identity: A non-human identity is any machine- or software-operated credentialed entity, such as a service account, API key, token, certificate, or AI agent. These identities often hold persistent permissions and can act continuously, so their lifecycle must be governed like access, not like configuration.
• Shadow SaaS: Shadow SaaS is unsanctioned application use where employees connect third-party tools without formal security review. These connections can inherit corporate data and permissions, creating hidden access paths that bypass normal monitoring, approval, and revocation processes.
• Effective Permissions: Effective permissions are the actual actions an identity can perform after roles, scopes, inheritance, and defaults are combined. They matter more than the nominal approval because they reveal the real blast radius of an integration or credential inside a SaaS environment.

Deepen your knowledge

SaaS supply chain attacks and non-human identity lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to close the gap between integration sprawl and governance, it is a practical place to start.

This post draws on content published by Obsidian Security: The rise of SaaS supply chain attacks and why you are not safe from the next Salesloft-Drift attack. Read the original.