TL;DR: Legacy security stacks struggle to see risks that now live inside SaaS, where OAuth tokens, service accounts, and AI agents can move access between applications without passing through the controls traditional tools were built to monitor, according to Obsidian Security. The practical shift is toward relationship-aware SaaS governance, because visibility into identities and entitlements matters more than perimeter inspection.
At a glance
What this is: This analysis says modern SaaS risk now sits inside applications, where OAuth tokens, service accounts and AI agents can move access without passing through traditional network, endpoint or SSO controls.
Why it matters: It matters because IAM, PAM and NHI programmes that only govern login and perimeter control will miss the entitlement paths that actually drive SaaS exposure.
Context
The security gap here is structural: traditional control stacks assume access is visible at login, on the network, or on an endpoint. In SaaS, the identity object that matters is often a token, service account or agent that acts inside the application after authentication has already been granted.
Obsidian Security frames the problem as a mismatch between where modern business workflows run and where legacy controls can see. That makes SaaS governance an identity problem as much as a data or network problem, because the risky behaviour lives in app-to-app relationships, not just in user sessions.
The article’s central claim is that relationship-aware visibility is now the deciding factor for SaaS security programmes. For practitioners, the question is not whether controls exist, but whether they can explain who or what has access, how that access propagates, and where it can be abused.
Key questions
Q: What breaks when OAuth tokens are compromised in connected SaaS environments?
A: When OAuth tokens are compromised, attackers can inherit delegated access without defeating passwords or MFA. In connected SaaS environments, that access can spread into multiple applications, cached data sets, and embedded records. The failure is not only token theft, but the assumption that one app boundary contains the blast radius. That assumption rarely holds once integrations are chained.
Q: Why do OAuth integrations and service accounts increase SaaS blast radius?
A: They can carry access across multiple applications without forcing a new human authentication step, so one compromised or over-scoped relationship can be reused repeatedly. The risk is amplification, not just initial compromise. Once a token or service account is trusted by connected apps, the attacker inherits the trust fabric that already exists between those apps.
Q: How do security teams know whether SaaS integration monitoring is actually working?
A: Monitoring is working when it surfaces abnormal authentication, unusual API queries, large exports, and suspicious session patterns quickly enough to support containment. Teams should test whether alerts fire on token abuse, bulk extraction, and admin impersonation, then verify that logs are normalized and reviewed in real time rather than left inside the SaaS platform.
Q: What should organisations do when an AI agent can chain SaaS permissions?
A: Treat the agent as an access actor with inherited entitlements, not as a benign automation layer. Define which applications it can touch, which scopes it may activate, and where cross-tenant access must be blocked. The goal is to stop chained privilege from turning one workflow into a broad execution path.
Technical breakdown
Why SaaS identities bypass perimeter controls
Traditional controls such as CASB, SASE and EDR are built to observe traffic, devices and federated logins. SaaS integrations often authenticate directly with OAuth tokens, service accounts or API-based trust, which means the access path never needs to traverse the control point those tools watch. That creates a visibility gap, not because the tools fail at their original job, but because the trust decision happens inside the application boundary. The practical result is that access can be valid, policy-compliant and still operationally invisible to the controls most teams already own.
Practical implication: map every non-interactive access path in SaaS and verify whether it bypasses your existing network, endpoint and SSO control points.
How OAuth tokens and service accounts create hidden privilege paths
OAuth tokens and service accounts are not just authentication artefacts, they are relationship carriers. A token can inherit broad delegated scopes, while a service account can retain permissions long after the user or integration that created it has changed. In SaaS environments, that makes privilege hard to reason about from event logs alone, because the risky object is the entitlement relationship between applications, not a single sign-in. This is why a relational or graph model matters: it exposes chained access, dormant rights and privilege creep that event-centric tools flatten into disconnected records.
Practical implication: inventory delegated scopes, service account permissions and app-to-app trust relationships as first-class governance objects.
Why AI agents increase SaaS blast radius
An AI agent becomes a governance problem when it can chain access across tenants or applications using credentials and permissions already present in the environment. The risk is not that the model is intelligent, but that it can combine access paths faster than human review cycles can follow. When an agent inherits permissions from multiple SaaS systems, a single approval or token can become a multi-application execution path. That turns access governance into a graph traversal problem, where blast radius depends on the number of connected entitlements the agent can activate.
Practical implication: treat agent permissions as an access graph and constrain which SaaS entitlements an agent can inherit or chain.
Threat narrative
Attacker objective: The attacker aims to turn one trusted SaaS integration into broad downstream access across many connected environments.
- Entry occurs through a third-party SaaS integration or OAuth token that is already trusted by the target environment.
- Privilege is extended inside the application when the token or service account carries broader scopes than the initiating workflow requires.
- Lateral movement follows when the compromised access path is reused across connected SaaS applications and tenants.
- Impact is the expansion of blast radius across downstream environments, exposing data and administrative access at scale.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
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
Legacy SaaS controls are now blind to the identity objects that matter most. CASB, EDR and SIEM were built around network, endpoint and event visibility, so they cannot reliably explain token-mediated or service-account-mediated access inside SaaS. That is not a tuning problem. It is a control-plane mismatch that leaves entitlement relationships under-governed.
Relationship-aware governance is the new centre of gravity for SaaS security. The article is right to shift attention from sessions to connections, because risk now propagates through OAuth scopes, delegated permissions and cross-application trust. The decisive question is no longer whether an identity authenticated successfully, but what access relationships that identity can activate after authentication.
Identity blast radius is the right concept for SaaS risk. Once access is expressed as a graph of connected apps, the governance problem becomes containment across linked permissions rather than perimeter denial. That matters for NHI, human IAM and autonomous workflows alike, because all three can inherit excess privilege through the same SaaS trust fabric.
AI agents expose the assumption that access is reviewed after it is granted. Access review processes were designed for access that persists long enough to be recertified. That assumption fails when an AI agent can chain SaaS permissions across systems in a single workflow, because the relevant privilege state may be created, used and discarded before a review cycle ever sees it. The implication is that entitlement governance must move closer to issuance and delegation events.
SaaS supply chain risk is now an identity security problem, not just an integration problem. A third-party app, an OAuth grant or a service account can become the bridge between one compromise and hundreds of downstream tenants. Practitioners should read this as a signal that SaaS security programmes need explicit governance for delegated trust, not just configuration hygiene.
From our research library:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
- Read next: Service Account Security Guide
What this signals
Identity blast radius: SaaS governance now has to model how access propagates through connected applications, because a single token or service account can expose multiple downstream environments. That shifts priority from perimeter inspection to entitlement mapping and makes app-to-app trust a core control object.
Access review cadences alone are not enough when access can be created and consumed inside one SaaS workflow. The programme question is whether delegated scopes, service accounts and AI agents are governed at issuance time, before chained access can spread across tenants.
For practitioners
- Map all SaaS-to-SaaS trust paths Identify every OAuth grant, service account and automation integration that can move access between applications without a user login.
- Review delegated scopes and dormant rights Inventory scopes that exceed the workflow they support and flag service accounts with permissions that remain active after the owning use case has changed.
- Classify AI agents as governed access actors Treat agent credentials, inherited permissions and cross-tenant app access as part of the access model, not as separate automation metadata.
- Detect blast-radius expansion in SaaS Trace how one compromised token or integration can reach downstream tenants, then prioritise controls around the highest fan-out paths.
- Close visibility gaps between IAM and in-app access Correlate identity provider records with in-app entitlements so that direct app-to-app access is governed alongside federated login paths.
Key takeaways
- SaaS security gaps emerge when OAuth tokens, service accounts and AI agents move privilege inside applications beyond the reach of traditional perimeter tools.
- The article points to downstream blast radius as the real risk, with one compromised integration able to affect hundreds of connected environments.
- Practitioners need entitlement graphs, delegated scope review and in-app visibility if they want governance that matches where SaaS risk now lives.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party SaaS integrations and OAuth grants are the article's core exposure path. |
| NHI-05 — Overprivileged NHI | The article centres on excessive scopes and dormant service account rights inside SaaS. | |
| NHI-09 — NHI Reuse | Reusable tokens and service accounts let one compromised relationship spread across connected apps. | |
| Recommendation — Inventory third-party SaaS identities and revoke any integration that cannot be explained by business need. Review SaaS service accounts and OAuth scopes for privilege beyond the workflow they support. Eliminate shared or reused SaaS credentials that can propagate access across multiple applications. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing entitlements that live inside SaaS applications. |
| Recommendation — Map SaaS entitlements to PR.AA-05 and verify that app-level access matches approved authorization. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The breach pattern described uses token access to move laterally through connected SaaS environments. |
| Recommendation — Map OAuth token abuse and downstream app hopping to TA0006 and TA0008 in detection and hunting. | ||
Key terms
- OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
- Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
- Delegated Scope: Delegated scope is the set of actions and resources a receiving agent is allowed to use on behalf of the originating actor. Effective scope should be narrower than the agent's raw capability and must be checked at every handoff, not just at session start.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
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.
Published by the NHIMG editorial team on May 28, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org