API security and SaaS supply chain risk: what teams miss

At a glance

What this is: This is an analysis of why API security is now central to SaaS supply chain security, with the key finding that compromised credentials and hidden integrations bypass human-centric controls.

Why it matters: It matters because IAM, PAM, and NHI programmes that stop at SSO, MFA, and inventory will miss machine-to-machine abuse unless they govern OAuth tokens, API keys, and integration behaviour.

By the numbers:

• SaaS-to-SaaS data moves 10x faster than human-to-SaaS interactions, according to Obsidian Security.

Context

API security is the practice of controlling the programmatic trust between SaaS applications, not just the login path for human users. In this article's model, the governance gap is that OAuth tokens, API keys, and other non-human identities operate outside the SSO and MFA controls built for people, yet they often hold broader access.

The core problem is that integrations create a hidden layer of access that looks legitimate once issued. When the subject is SaaS supply chain risk, the control question shifts from who signed in to which machine identity can move data, inherit privilege, and persist beyond the business need that created it.

That makes API security an identity governance problem as much as a monitoring problem. Static inventories can tell teams what exists, but they do not tell them whether a valid credential is being abused, overprivileged, or reused across environments.

Key questions

Q: What breaks when API security is managed like human SSO security?

A: SaaS integrations keep working outside the login flow, so SSO and MFA only protect the human front door. Machine identities use OAuth tokens, API keys, and webhooks that can remain valid after compromise, allowing attackers to act with trusted access. The broken assumption is that authentication events tell you whether the current caller is legitimate.

Q: Why do compromised API keys create such a broad security impact in hybrid work environments?

A: A compromised API key can authenticate as a trusted non-human identity, so the attacker inherits whatever actions that key can perform. In hybrid environments, those keys often bridge third-party tools and internal systems, which can turn one exposure into password resets, workstation access, or lateral movement. The risk grows when keys have broad scope, weak monitoring, and long-lived validity.

Q: What are the signs that third-party app or API activity is being abused?

A: Warning signs include unusual access patterns, unexpected data retrieval, abnormal cache behaviour, unexplained directory exposure, and activity from third-party applications outside normal business timing. For APIs, watch for secret use that does not match approved workflows, repeated calls from unfamiliar sources, or access attempts tied to data that should not be reachable. These indicators usually point to misconfiguration or compromise.

Q: When should organisations prioritise API behavioural monitoring over static inventory?

A: When integrations are numerous, privileges are inherited, and long-lived credentials already exist, behavioural monitoring should come first because inventory cannot show misuse. Inventory is still useful for discovery, but it does not reveal active abuse or anomalous use of valid credentials. The priority is to detect what is happening, not just what is connected.

Technical breakdown

Why bearer tokens behave like master keys in SaaS

Most SaaS integrations rely on bearer-style OAuth tokens or API keys, which means possession is enough to use them. There is no second authentication challenge at request time, so the credential itself becomes the trust boundary. That design is efficient for automation but dangerous when the token is copied, leaked, or reused, because the system cannot distinguish the authorised integration from an attacker using the same secret. In identity terms, the non-human identity is authenticated once and then runs with whatever privilege was delegated until revoked or expired.

Practical implication: Treat every API key and bearer token as a credential with explicit lifecycle controls, not as a static configuration value.

Why static inventories miss compromised API activity

Inventory answers a presence question, not a behaviour question. A dashboard can show that an integration exists, but it cannot tell whether that integration is making unusual exports, reaching new datasets, or operating from an unexpected network context. That gap matters because valid credentials used by an attacker often look normal to tools that only check authentication success. Effective API security therefore depends on behavioural baselining, identity context, and request patterns, not simply on listing every connected app.

Practical implication: Add behavioural detection to integration review so you can spot misuse of legitimate credentials, not just unknown apps.

How integration chains expand blast radius across SaaS

SaaS supply chains extend trust through chained authorisations. When one application is granted OAuth access to another, it inherits whatever scope the granting user or admin approved, and that permission can cascade into downstream environments. Overprivileged scopes, stale approvals, and reused credentials can turn one compromised integration into a multi-tenant exposure path. The risk is amplified in cloud-connected business workflows because the attacker does not need to break the application itself, only the trust relationship that connects it to other systems.

Practical implication: Map third-party access chains and recertify inherited permissions as a distinct control surface, not as part of general application inventory.

Threat narrative

Attacker objective: The attacker wants to abuse trusted SaaS integrations to reach customer environments, extract data, and expand the blast radius without triggering human access controls.

1. Entry occurs when an attacker obtains a valid OAuth token, API key, or other machine credential from a leaked integration, repository, log, or downstream compromise. The credential is accepted as legitimate because bearer-style access does not require an additional login event.
2. Escalation happens when that credential carries broader scopes than the integration actually needs, allowing the attacker to read, export, or modify data beyond the intended business function. Overprivileged access turns one compromise into a wider trust abuse.
3. Impact follows when the attacker uses the trusted integration path to move laterally across SaaS environments and extract data at machine speed. The result is customer-environment exposure that bypasses the controls designed for human users.

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

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

API security is now SaaS supply chain security in practice. The article shows that the exposed layer is not the login screen but the machine-to-machine trust fabric underneath it. SSO and MFA still matter for humans, but they do not govern OAuth tokens, API keys, or inherited integration scopes. The implication is that identity programmes must treat connected SaaS relationships as part of the access model, not as a separate technical detail.

Static integration inventories create false confidence. Knowing that an API exists does not tell you whether it is overprivileged, dormant, or being abused with valid credentials. That is a governance failure because the control decision moves from discovery to behaviour, and most traditional tools stop at discovery. The practical conclusion is that API security has to be measured by usage context, not by the count of connected apps.

Hidden integrations create an identity blast radius that most programmes still under-estimate. When one trusted app can inherit permissions from a user or admin, the resulting scope is larger than the original authorisation event suggests. That is why third-party access recertification and entitlement review need to include SaaS-to-SaaS pathways, not just user accounts. The field should treat inherited integration privilege as a first-class governance object.

Long-lived machine credentials are a lifecycle problem before they are a detection problem. API keys that never expire, refresh tokens that outlive the business purpose, and integration approvals that are never revisited all extend the attack window. That is not merely weak hygiene; it is a structural mismatch between ephemeral business use and persistent credential validity. Practitioners should read this as a lifecycle governance issue across NHI, not only as a SOC alerting issue.

Behavioural monitoring is the named concept that closes the gap. The article's strongest signal is that compromise becomes visible in unusual request patterns, not in possession alone. That means the security discipline has to shift toward behavioural baselining for machine identities, especially where access is delegated through SaaS integrations. Teams that do not make that shift will keep seeing valid credentials as trustworthy after they have been abused.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• Read next: API Key Management Guide

What this signals

Hidden integration trust needs lifecycle governance, not just discovery. The programme risk is that teams count connected apps but never reassess whether those connections still deserve the scopes they hold. That is why recertification, offboarding, and credential expiry need to cover SaaS integrations as explicitly as they cover human access.

Behavioural monitoring becomes the deciding control when machine credentials are valid by design. A stolen API key can look indistinguishable from the authorised integration unless teams baseline request shape, source, and destination patterns. Compromise is therefore a usage problem, not a possession problem, and that changes where detection has to sit.

Identity blast radius is the right concept for SaaS supply chain exposure. A single third-party app can inherit enough access to move laterally into multiple customer environments, which means governance must track downstream trust chains instead of isolated apps. The security question is no longer just who connected, but what that connection can reach.

For practitioners

• Discover all SaaS integrations and machine identities Build and maintain a complete inventory of OAuth apps, API keys, webhooks, and service accounts across core SaaS platforms, including shadow integrations created outside formal review.
• Recertify inherited integration privileges Review scopes, admin-level grants, and dormant third-party access on a defined cadence so inherited permissions do not outlive the business need that approved them.
• Detect behavioural anomalies in API activity Baseline request volume, data export patterns, source IPs, and access timing for each integration, then alert on deviations that indicate valid credentials are being abused.
• Rotate and expire API credentials aggressively Replace long-lived API keys with short-lived tokens where possible, and revoke credentials immediately when an integration is decommissioned or no longer used.
• Map SaaS-to-SaaS trust chains Trace which integrations inherit permissions from admins or privileged users, then classify those chains as part of the enterprise access surface for governance and response.

Key takeaways

• API security is the control layer that governs SaaS-to-SaaS trust, and human-centric controls do not cover it.
• Valid credentials are the problem because attackers can abuse bearer tokens and API keys without changing the authentication event.
• Behavioural monitoring, entitlement review, and credential lifecycle controls are the practical defences that reduce blast radius.

Key terms

• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
• SaaS Supply Chain: A SaaS supply chain is the network of third-party applications, integrations, and delegated permissions that connect cloud services to each other. It creates operational efficiency, but it also creates inherited trust paths where a compromise in one system can quickly affect many others.
• Behavioral Monitoring: Behavioral monitoring is the practice of detecting misuse by comparing current activity to established patterns of normal use. For NHI governance, it is essential because valid API credentials can look authentic even when they are stolen and being used for exfiltration or lateral movement.
• Inherited Permissions: Inherited permissions are access rights passed from the authorizing user or application to a connected integration. They become risky when the granted scope is broader than the integration needs, because the downstream app can retain high privilege long after the original business need has changed.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.