SaaS supply chain attacks are exposing NHI governance gaps

At a glance

What this is: This is an analysis of how SaaS supply chain attacks exploit trusted SaaS integrations, with the key finding that inherited access across OAuth, API keys and service accounts is the control gap.

Why it matters: It matters because IAM, NHI and PAM teams need to govern delegated SaaS trust relationships continuously, not just secure the applications they own directly.

By the numbers:

• The number of SaaS integrations and AI agents created have increased by 123% and 223% respectively, according to Obsidian Security.

Context

SaaS supply chain risk begins when one application is trusted to act for another through OAuth, API keys, service accounts or automated workflows. That trust can extend beyond the security controls the organisation thinks it has in place, especially when permissions are inherited and rarely re-evaluated.

Obsidian Security frames the problem as a governance gap, not a perimeter problem. The article argues that modern SaaS estates create a web of delegated access paths that attackers can ride from one compromised integration into many downstream environments.

The same pattern now extends to AI-to-SaaS integrations, where autonomous behaviour can amplify broad permissions and cross-application reach. For identity teams, the key question is no longer whether a single app is secure, but whether every non-human identity and inherited trust relationship is still justified.

Key questions

Q: What breaks when a third-party SaaS integration is compromised in a CRM environment?

A: A compromised integration can bypass normal user controls and give an attacker direct access to data stored in the connected tenant. In a CRM, that may expose account records, case notes, contact details, or other sensitive business information even when the core platform itself is not breached. Security teams should treat connected apps as part of the attack surface and review their privileges, monitoring, and revocation process.

Q: Why do SaaS supply-chain attacks create a larger blast radius than direct account compromise?

A: A compromised integration can inherit trusted access and reach many downstream tenants without re-authenticating each one. That makes the breach scale through approved relationships instead of through repeated credential theft. The result is faster spread, broader exposure, and a containment problem that is much harder than a single-account incident.

Q: How can security teams tell whether delegated SaaS access is over-extended?

A: Look for integrations that can reach more data, more functions or more systems than their business purpose requires. Warning signs include inherited admin roles, broad OAuth scopes, service accounts with persistent access and tokens that are reused across multiple apps. If the effective access is wider than the approved use case, the integration is over-extended.

Q: Who should own the risk when a SaaS integration is compromised?

A: Ownership should sit with the team that approved the integration and the business function that depends on it, not just with security operations. They must be able to answer who can revoke the token, how scope is reviewed, and when access expires. Without explicit ownership, connected-app risk becomes everyone’s problem and nobody’s responsibility.

Technical breakdown

How OAuth and API keys create trusted cross-app execution paths

OAuth tokens and API keys are designed to let systems act without repeated human login, which makes them useful and dangerous in equal measure. In SaaS supply chains, they function as delegated credentials that can outlive the original user action, especially when scopes are broad, refresh tokens remain valid, or keys are embedded in code and automation. Once a token is stolen or abused, the attacker does not need to defeat the target app’s front door. They can operate inside the trust boundary that the integration already established.

Practical implication: inventory delegated credentials by scope, lifetime and connected systems, not by application count alone.

Why service accounts and over-permissioned SaaS apps increase blast radius

Service accounts and app principals often run continuously, inherit default roles, and accumulate access over time. In SaaS environments that means a compromised identity can persist as a trusted backdoor, moving from mailboxes to files to admin APIs without triggering the controls built for human authentication. Over-permissioned apps make this worse because effective access is usually broader than the original business need, and that excess access survives long after the integration was installed.

Practical implication: review effective permissions for each non-human identity and remove inherited access that is no longer required.

Why traditional perimeter tools miss SaaS-to-SaaS lateral movement

Legacy tools were built to observe networks and endpoints, not cloud-to-cloud delegation chains. SaaS supply chain attacks therefore bypass the places where traditional monitoring is strongest and move through API calls, OAuth grants and cross-application workflows that often lack full telemetry. That blind spot matters because lateral movement in SaaS is not a host-to-host problem. It is an identity and authorization problem, where one trusted integration can be used to reach many adjacent services without breaking into each one separately.

Practical implication: place detection on identity behaviour and integration activity, not only on network or endpoint events.

Threat narrative

Attacker objective: The attacker wants to turn one compromised integration into persistent, trusted access across multiple SaaS environments and their downstream data and workflows.

1. Entry begins when attackers compromise a third-party vendor, integration, or credential rather than the primary target’s front door.
2. Credential access occurs through stolen OAuth tokens, exposed API keys, or long-lived service account permissions that already bridge SaaS applications.
3. Escalation happens as the trusted integration is used to reach additional SaaS systems, expand permissions, and move into downstream environments.
4. Impact is cross-organisation exposure, with data exfiltration, configuration abuse, and broad SaaS compromise spreading through inherited trust relationships.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Inherited trust is the core governance failure in SaaS supply chain attacks. The article shows that the security problem is not isolated credential theft, but the way OAuth grants, service accounts and API keys extend trust across systems without continuous re-justification. That makes the supply chain itself the control plane, which is exactly where identity governance is weakest. Practitioners should treat every delegated SaaS relationship as an active governance object, not a static configuration.

Non-human identities now carry more practical risk than many human access paths. Service accounts, refresh tokens and API keys can all operate outside normal login patterns, which means they evade human-centric assumptions about prompts, sessions and review cycles. When a credential can mint new access, act continuously or inherit broad privileges, the effective identity is the integration, not the user. Practitioners need lifecycle ownership that follows the machine identity across installation, expansion and offboarding.

Shadow SaaS turns business convenience into governance debt. Unsanctioned applications and hidden integrations are not simply a visibility problem, they are an authorisation problem because they inherit access to corporate data without equivalent oversight. That creates a control gap where the organisation cannot accurately state who or what can act on its behalf. Practitioners should assume every unapproved integration widens blast radius until it is enumerated and governed.

Continuous control over delegated access is now the baseline expectation. The article reinforces that legacy perimeter thinking fails because SaaS trust is distributed, dynamic and difficult to observe after the grant is made. The named concept here is inherited trust debt: access that remains in place long after its original business justification has expired. Practitioners should measure how much of their SaaS estate is governed by standing trust rather than explicit, reviewable need.

From our research library:

• DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Inherited trust debt: SaaS supply chain risk grows when delegated access survives the business need that created it. Teams should focus on the lifespan of OAuth grants, API keys and service accounts, because standing trust is the mechanism attackers reuse.

The programme question is no longer whether an integration exists, but whether its effective permissions are still defensible. That shifts SaaS governance from discovery alone to continuous lifecycle control across every non-human identity that can act on the organisation’s behalf.

For practitioners

• Map delegated SaaS trust relationships Build an inventory of OAuth grants, API keys, service accounts and automated workflows, then link each one to the apps, vendors and data it can reach.
• Review effective permissions, not just app approvals Check inherited roles and default scopes for each integration to find access that exceeds the stated business function.
• Create lifecycle ownership for non-human identities Assign an owner for installation, scope changes, renewal, revocation and offboarding so each credential has a named governance path.
• Detect abnormal cross-app identity behaviour Look for token use, API calls and workflow actions that do not match the normal delegation pattern for a given integration.
• Remove hidden and shadow integrations Find unsanctioned SaaS connections created outside IT approval and either govern them explicitly or revoke them before they widen exposure.

Key takeaways

• SaaS supply chain attacks work because trusted integrations can be abused without breaking each target system individually.
• The article points to rapid growth in SaaS integrations and AI agents, which expands the number of delegated access paths that must be governed.
• Security teams need continuous visibility into inherited permissions, lifecycle ownership and cross-app behaviour if they want to reduce blast radius.

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.
• Inherited Trust: Access or authority an agent effectively receives from a surrounding workflow, upstream agent, or human process rather than from its own direct permissions. This can make the agent appear properly scoped while its real operational reach is broader than the entitlement record suggests.
• Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.
• Effective Permissions: Effective permissions are the access an identity can actually use after role inheritance, scope, and policy are applied. In Azure AI environments, they often matter more than the assigned role name because inherited rights can widen access to data, logs, and secret stores.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.