SaaS security gaps in OAuth tokens and AI agents demand new controls

At a glance

What this is: This is an analysis of why traditional security tools leave SaaS identity and integration risk exposed, with OAuth tokens, service accounts, and AI agents as the main gaps.

Why it matters: IAM and NHI teams need a SaaS-native view of relationships, because access now propagates through applications, not just through users logging in from managed devices.

By the numbers:

• The recent Salesloft-Drift breach affected 700+ companies through a single compromised vendor integration.

👉 Read Obsidian Security's analysis of legacy security gaps in SaaS, OAuth tokens, and AI agents

Context

SaaS security is the problem of governing access, data, and integrations inside cloud applications rather than only at the perimeter. In this case, the primary gap is that identities now act through OAuth tokens, service accounts, and automations that traditional IAM, SASE, EDR, and SIEM controls cannot fully observe.

That matters for NHI governance because many high-risk access paths are non-human and often invisible to perimeter-first tooling. Obsidian Security uses the Salesloft-Drift supply chain breach as a concrete example of how a single compromised integration can expand blast radius across hundreds of downstream environments, which is typical of the SaaS-native risk pattern described here.

Key questions

Q: How should security teams govern OAuth tokens in SaaS environments?

A: Security teams should inventory OAuth grants, restrict scopes to the minimum necessary, and revoke unused integrations quickly. Tokens should be treated as delegated identity credentials, not just application settings. Governance works best when token review is tied to access lifecycle controls, entitlement review, and alerting on unusual cross-app activity.

Q: Why do SaaS service accounts create different risks than normal user accounts?

A: Service accounts often run continuously, hold persistent credentials, and carry broad permissions across systems. That makes them harder to govern with human-centric processes such as login monitoring or periodic user access reviews. They need identity ownership, lifecycle control, and entitlement review because their misuse can persist long after a human leaves the workflow.

Q: What is the difference between SaaS security and traditional IAM monitoring?

A: Traditional IAM monitoring focuses on authentication and federation, while SaaS security focuses on what happens after access is granted inside the application layer. In practice, IAM tells you who signed in, but SaaS security tells you how tokens, permissions, and automations interact across apps. Both are needed, but they solve different parts of the access problem.

Q: When should organisations treat AI agents as privileged identities?

A: Organisations should treat AI agents as privileged identities whenever they can act independently, chain tool use, or inherit permissions across systems. If an agent can move data, call APIs, or trigger workflows without direct human oversight, it belongs in the same governance lane as other non-human identities and needs scope limits, logging, and revocation paths.

Technical breakdown

Why OAuth tokens bypass perimeter controls

OAuth tokens authorize app-to-app access directly, which means they can move data and act on behalf of a user without traversing SSO, MFA, or the traffic path that SASE and CASB products inspect. Once a token is granted, the real security question is not only who signed in, but what scopes were issued and whether those scopes still match business need. Because tokens can persist beyond the login session, they create an access path that is decoupled from the endpoint and the network.

Practical implication: inventory OAuth grants by scope, not just by app name, and revoke anything that exceeds the intended access pattern.

How service accounts and AI agents change SaaS identity risk

Service accounts and AI agents function as identities with execution authority, but they often operate outside human-centric access review processes. Service accounts commonly have persistent credentials and broad entitlements, while AI agents may chain actions across multiple SaaS tenants using inherited permissions. Traditional SIEM correlation can show that something happened, but it usually cannot model the entitlement relationships that explain how the access path existed in the first place.

Practical implication: treat service accounts and AI agents as first-class identities and review their entitlements with the same rigor applied to privileged human users.

Why relational visibility matters more than event logs

A relational model links users, tokens, permissions, resources, and activity into one graph, so defenders can see who has access, how they got it, and where that access can propagate. That is different from event-only tooling, which is useful for detection but weak at reconstructing cross-application privilege chains. In SaaS, the security problem is often the connection between systems, not the compromise of a single box.

Practical implication: build entitlement and dependency maps for your SaaS estate so you can identify privilege creep before it becomes an incident.

Threat narrative

Attacker objective: The objective is to turn delegated SaaS access into large-scale downstream data access without needing to break into each target environment individually.

1. Entry occurs when attackers compromise a third-party SaaS integration and obtain OAuth tokens that can act across connected applications.
2. Escalation follows when those tokens expose overprivileged access paths, service accounts, or admin-level entitlements across downstream tenants.
3. Impact is broad data exposure and cross-tenant blast radius, as seen when a single integration can reach hundreds of organisations.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• 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

Legacy perimeter controls no longer match the way SaaS identities operate. Access now moves through tokens, service accounts, and integrations that can sit entirely outside device and network enforcement. That creates a governance gap, not just a tooling gap, because the control plane and the risk plane have diverged. Practitioners should assume that any SaaS program without relational visibility is already behind the threat model.

Ephemeral access reduces exposure only when the downstream identity model is also governed. Short-lived sessions do not eliminate risk if OAuth scopes, service account entitlements, and AI agent permissions remain persistent or overbroad. The field should stop treating token duration as the main issue and focus on authority, propagation, and revocation. The practical conclusion is that least privilege must be measured at the app relationship layer, not just at login.

Identity blast radius is the right named concept for modern SaaS risk. The issue is not whether a single account is compromised, but how far its delegated access can travel across apps, tenants, and automations. That blast radius is often invisible to tools built around endpoints or network chokepoints. Security teams should prioritize controls that bound propagation, not just controls that detect misuse after the fact.

SaaS security is becoming a non-human identity governance problem. Service accounts, API keys, OAuth tokens, and AI agents now form a shared access fabric that must be governed as one identity surface. That shifts the programme from app-by-app review toward entitlement graphing, continuous access review, and fast revocation. Teams that still separate SaaS security from NHI governance are leaving the most dynamic identities outside policy.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security.
• For related context, review the Guide to the Secret Sprawl Challenge for the credential exposure patterns that often accompany SaaS integration sprawl.

What this signals

Identity blast radius: SaaS programmes now need to measure how far delegated access can travel after an OAuth grant, because that propagation path is where breach scope expands. With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the broader lesson is that integration surfaces are becoming credential surfaces, and governance has to follow that shift.

The operational priority is to connect SaaS entitlements, secrets handling, and AI agent permissions into one review cycle. Teams that split these domains will keep detecting individual events while missing the relational path that turns a single compromise into cross-tenant exposure. Linking reviews to NIST AI Risk Management Framework governance controls can help make that programme structure defensible.

As SaaS estates accumulate more delegated access, continuous revocation becomes a resilience control rather than a cleanup task. That is where OWASP Agentic AI Top 10 guidance and SaaS-native entitlement mapping start to overlap in practice, especially when agents and integrations can move faster than human review cycles can keep up.

For practitioners

• Map all delegated SaaS access paths Catalogue OAuth integrations, service accounts, API keys, and automated workflows by the permissions they actually hold, not by the applications they touch.
• Review scopes and entitlements for overreach Compare granted scopes against business need and remove dormant or excessive permissions before they widen the blast radius of a compromise.
• Add revocation to the access lifecycle Tie token rotation, app deauthorisation, and account offboarding into the same workflow so delegated access can be removed quickly when risk changes.
• Build a SaaS entitlement graph Create a relational view that connects identities, permissions, resources, and activity so reviewers can see how access propagates across tenants and integrations.

Key takeaways

• Modern SaaS risk is driven by delegated identities inside applications, not just by users at the perimeter.
• The Salesloft-Drift case shows how a single compromised integration can widen the blast radius across hundreds of organisations.
• Practitioners should govern OAuth scopes, service accounts, and AI agents as one identity surface with fast revocation paths.

Key terms

• OAuth Token: A token is a delegated credential that lets one application act on behalf of a user or service without collecting the original password. In SaaS, OAuth tokens can carry broad scopes and survive beyond a single login session, which makes revocation and scope review central to NHI governance.
• Service Account: A service account is a non-human identity used by software, automation, or workloads to authenticate and perform tasks. These accounts often run continuously and can accumulate broad permissions, so they need ownership, lifecycle control, and periodic entitlement review like any other privileged identity.
• Identity Blast Radius: Identity blast radius is the amount of access and downstream exposure that can be reached if one identity, token, or integration is compromised. In SaaS environments, it is shaped by scopes, relationships, and propagation paths, not just by whether a login was protected by MFA.

Deepen your knowledge

SaaS security gaps in OAuth tokens, service accounts, and AI agents are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme for delegated access across SaaS, it is worth exploring.

This post draws on content published by Obsidian Security: Legacy Security vs. Obsidian: Why SaaS Security Demands a New Approach. Read the original.