API security and SaaS supply chain risk: what teams miss

At a glance

What this is: API security is the practice of protecting SaaS integrations and other programmatic links from credential abuse, with the central finding that hidden machine-to-machine trust often escapes traditional human-centric controls.

Why it matters: For IAM and NHI practitioners, this matters because stolen API credentials can move laterally through SaaS environments without tripping the controls built for interactive user sign-in.

By the numbers:

• SaaS-to-SaaS data moves 10x faster than human-to-SaaS interactions.
• 700 companies were affected when the Salesloft-Drift integration, ntegration cascade expanded blast radius across connected environments.

👉 Read Obsidian Security's analysis of API security in SaaS supply chains

Context

API security is the control problem created when software talks to software with credentials that look legitimate even when they are stolen. In SaaS environments, that problem sits directly inside the NHI governance gap because service accounts, OAuth tokens, API keys, and webhooks often operate outside the visibility of standard IAM review.

The practical issue is not just exposure, but inherited trust. Once a third-party integration is authorized, it can retain broad access long after business need changes, while static inventories and point-in-time reviews fail to reveal abuse. That is now typical in modern SaaS estates, not an edge case.

The article frames this as a hidden layer between applications, and that framing is accurate. The real challenge for practitioners is that the control surface is behavioral as much as it is administrative, which means detection has to follow usage patterns, not just permission lists.

Key questions

Q: How should security teams govern API credentials in SaaS environments?

A: Treat API credentials as non-human identities with owners, purpose, scope, and expiry. The practical baseline is least privilege, short-lived access where possible, regular recertification, and behavioral monitoring for misuse. Inventory is necessary, but governance only works when teams can prove who authorized access, why it exists, and whether the integration still needs it.

Q: Why do static API inventories fail to detect compromise?

A: Static inventories record existence, not legitimacy. A stolen token or API key often looks identical to normal traffic at the protocol level, so the control gap is behavioral. Teams need baselines for request frequency, destination, volume, and timing to distinguish a valid credential in use from a valid credential under attack.

Q: What is the difference between API security and traditional IAM controls?

A: Traditional IAM focuses on human authentication events such as login, MFA, and session management. API security focuses on bearer credentials and programmatic trust between systems, which can bypass those human controls entirely. That is why API governance must include lifecycle management, scope reduction, and abuse detection, not just sign-in policy.

Q: When does API access become an NHI governance risk?

A: API access becomes an NHI governance risk whenever a machine credential can act with broad or persistent privileges outside active human supervision. The risk is highest when the credential is long-lived, shared, undocumented, or inherited through a third-party integration. At that point, the question is not just access control, but lifecycle and blast-radius control.

Technical breakdown

Why OAuth tokens and API keys behave like standing privileges

In SaaS integrations, bearer-style credentials grant access to whoever possesses them, with no additional challenge at request time. That makes an API key or OAuth token function like standing privilege for a machine identity. If the token is long-lived, inherited broadly, or reused across environments, compromise becomes durable rather than momentary. The key technical issue is that authentication and authorization are decoupled from human sign-in events, so SSO and MFA do not meaningfully constrain the token once issued.

Practical implication: Treat every long-lived integration credential as a privileged identity and reduce its lifetime and scope aggressively.

Why static API inventories miss credential abuse

An inventory tells you that an integration exists, but not whether it is behaving normally. That distinction matters because a stolen credential usually looks authentic at the protocol layer. Security teams need identity context, business purpose, and behavioral baselines to decide whether a request is legitimate. Without that context, SIEM and network tooling mostly see volume, IP address, and payload size, which are weak signals when attackers operate inside valid permissions.

Practical implication: Augment inventory with behavioral baselines that flag deviations in request timing, scope, and destination.

How SaaS integration chains expand blast radius

SaaS-to-SaaS links create inherited permissions, and those permissions can cascade across connected platforms. When one upstream integration is compromised, downstream systems may trust its access path without re-evaluating the original authorization. That is why a single stolen OAuth token can become a supply chain event rather than a single-account incident. The architectural weakness is not just weak authentication. It is trust reuse across multiple administrative domains with limited recertification.

Practical implication: Map every integration chain and recertify access whenever the upstream app, owner, or business purpose changes.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• 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

API security is now an NHI governance problem, not just an application security problem. The article is right to center credentials and behavior, because SaaS integrations are non-human identities with durable access paths. Once teams accept that framing, the relevant questions shift from simple asset inventory to lifecycle control, scope review, and abnormal-use detection. Practitioners should govern APIs as identities with purpose, owners, and expiry.

Hidden trust is the real attack surface in SaaS supply chains. Human users are usually constrained by sign-in controls, but bearer credentials bypass that interaction layer entirely. That makes delegated access, not the application login page, the point where risk accumulates. Security teams need to re-evaluate whether approval workflows, recertification, and offboarding actually follow the integration after it is created.

Behavioral monitoring is the only reliable control when credentials are already valid. Static policy can tell you what should be allowed, but it cannot tell you whether an authorized API call is being abused by an attacker. That is why anomaly detection around volume, destination, timing, and scope is becoming a core NHI control pattern. Practitioners should assume possession is insufficient evidence of legitimacy.

Ephemeral access helps, but it does not solve trust reuse. Short-lived tokens reduce exposure windows, yet inherited permissions and overbroad scopes can still create large blast radius when integrations are authorized too freely. The field should stop treating rotation as a complete answer and start pairing it with scope minimization, chain mapping, and continuous recertification. Practitioners should design for least privilege across the full integration graph.

API sprawl is becoming indistinguishable from NHI sprawl. Every new SaaS connection adds an identity, a privilege set, and a failure mode. That makes API governance a lifecycle discipline, not a one-time configuration task. Teams that do not manage integrations as living identities will continue to discover them only after abuse has begun.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Our research also found that the average estimated time to remediate a leaked secret is 27 days, even though 75% of organisations express strong confidence in their secrets management capabilities.
• For a broader NHI lens on why hidden credentials keep escaping governance, see The 52 NHI breaches Report and map that pattern to your integration graph.

What this signals

Secrets fragmentation is the precursor to API governance failure. When organisations operate across multiple secrets managers, ownership, rotation cadence, and revocation policy drift apart. That fragmentation makes it harder to see whether an integration credential is active, stale, or orphaned, which is exactly the state attackers exploit. For teams building a control programme, the first signal is not scale, but fragmentation across credential stores and ownership boundaries.

With 44% of developers reported to follow security best practices for secrets management, the operational gap is as much human as it is technical, according to our research. That means API security programmes have to address developer workflow, not just SOC detection. The practical focus should be approval hygiene, rotation enforcement, and permission review embedded into the delivery process.

Identity blast radius: the useful question is not whether a token exists, but how far it can move if abused. That lens changes incident readiness, because response teams need to know which integrations inherit admin-level access and which downstream systems trust them automatically. Practitioners should build response playbooks around blast radius, not around isolated credential events.

For practitioners

• Build a complete integration inventory Enumerate every SaaS-to-SaaS connection, then tie each one to an owner, business purpose, privilege scope, and review date. Do not stop at the named application list, because undocumented and user-created integrations are often where exposure begins.
• Shorten credential lifetime and revoke stale access Replace long-lived API keys where possible, enforce expiry on bearer tokens, and remove credentials when projects end or integrations are decommissioned. Pair this with offboarding checks so abandoned machine access does not survive personnel or workflow changes.
• Monitor behavior instead of just presence Baseline normal API request patterns for each integration, then alert on unusual export volumes, timing shifts, source IP changes, and access to resources outside the usual scope. Static inventory is necessary, but it is not sufficient to detect valid credentials under attack.
• Recertify delegated permissions on a fixed cadence Review OAuth scopes and admin-level grants at a scheduled interval, especially after business changes or platform migrations. Focus on toxic combinations of broad access and low or no usage, because those are the easiest paths for lateral movement.
• Map integration chains for blast-radius control Trace upstream and downstream dependencies for every high-value SaaS app so one compromised credential does not become a hidden supply chain event. Use the map during incident response to identify where trust was inherited rather than explicitly re-approved.

Key takeaways

• API security is a non-human identity problem because valid credentials can be abused without touching human sign-in controls.
• The main risk is not just exposed keys, but inherited trust, broad scopes, and stale integrations that keep working long after their purpose fades.
• Practitioners need behavioral detection, recertification, and blast-radius mapping to govern SaaS integrations as living identities.

Key terms

• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring a separate proof step at request time. In SaaS integrations, that makes the token itself the trust boundary, which is why theft, replay, and overlong validity windows are so dangerous for machine identities.
• 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

API security, secrets lifecycle control, and machine identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with SaaS integrations and bearer credentials, this is a practical place to start.

This post draws on content published by Obsidian Security: What is API Security? Protecting the Hidden Layer Between SaaS Apps. Read the original.