Agentic AI is reshaping SaaS security and OAuth risk

At a glance

What this is: Obsidian Security argues that agentic AI is widening SaaS security risk by exploiting persistent OAuth connections and overly permissive integrations.

Why it matters: IAM, NHI, and SaaS security teams need to reassess how delegated access, application sprawl, and non-human actors are governed when autonomy enters the workflow.

By the numbers:

• Obsidian Security protects more than 200 organizations across North America, Europe, the Middle East, Southeast Asia, Australia, and New Zealand.

👉 Read Obsidian Security's analysis of agentic AI risk in SaaS security

Context

Agentic AI is changing SaaS security because the identity doing the work is no longer always a person. In practice, that means persistent OAuth connections, embedded copilots, and non-human actors can move through business applications with permissions that were granted for a very different operating model.

For IAM and NHI programmes, the core issue is delegated access that outlives its original purpose. When SaaS-to-SaaS integrations and AI-driven workflows accumulate over time, visibility into who or what is acting becomes harder, and control decisions increasingly depend on context the traditional access model was never designed to preserve.

Key questions

Q: How should security teams govern SaaS integrations that use persistent OAuth tokens?

A: They should treat persistent OAuth grants as identity objects with owners, purposes, and revocation paths. The practical test is whether each integration still matches the business use case it was created for. If the grant cannot be tied to a current need, it should be removed or re-scoped before it becomes an attack path.

Q: Why do AI agents increase risk in SaaS environments?

A: AI agents increase risk because they can operate through existing application permissions and continue using them as tasks change. That turns delegated access into a broader governance problem, especially when the permissions were never reviewed for non-human use. The result is a larger blast radius from the same underlying grant.

Q: What do teams get wrong about OAuth security in business apps?

A: Teams often focus on the token and miss the relationship behind it. A valid token may still be dangerous if the connected application, workflow, or AI agent no longer fits the intended scope. Governance has to include ownership, context, and lifecycle, not just authentication and expiry.

Q: Who is accountable when a non-human actor abuses delegated SaaS access?

A: Accountability should sit with the business owner of the integration, the platform team that approved the grant, and the security function that monitors its use. If no one owns the delegation lifecycle, then the organisation has created access that can persist without meaningful oversight.

Technical breakdown

Persistent OAuth connections and SaaS-to-SaaS delegation

OAuth is designed to let an application act on behalf of a user or service without sharing passwords, but that delegation can become durable once tokens and refresh grants remain active. In SaaS environments, the risk is not the protocol itself, but the accumulation of permissions across app-to-app links that are rarely reviewed with the same rigour as human access. When AI tools inherit these connections, they can operate inside business systems with a scope that feels routine but is functionally broad.

Practical implication: map every persistent SaaS integration to an owner, a purpose, and a revocation path, then review it as part of access governance.

How agentic AI changes non-human identity risk

Agentic AI matters because it can act as a runtime identity, not just a passive tool. Once an AI system can select actions inside a workflow and use existing integrations, it becomes part of the access chain that SaaS security must govern. That shifts the problem from simple secret protection to control over what the actor can reach, when it can do so, and how its behaviour is distinguished from legitimate automation or human use.

Practical implication: classify AI-enabled workflows separately from ordinary automation and tie their permissions to explicit business use cases.

OAuth token anomalies as an abuse signal

Token anomalies are often the earliest sign that delegated access is being abused. In a SaaS stack, suspicious behaviour may appear as unusual application usage, unexpected in-app activity, or access patterns that do not match the normal relationship between the user, the application, and the data being touched. Because tokens can persist beyond a single session, anomaly detection has to look for drift in behaviour rather than just failed logins or obvious credential theft.

Practical implication: detect on token use, app relationship changes, and workload context, not only on authentication events.

Threat narrative

Attacker objective: The attacker objective is to use delegated SaaS access to reach sensitive business data and operate inside trusted application workflows.

1. Entry occurs when AI-powered tools or attackers gain access through overly permissive OAuth tokens and overlooked SaaS-to-SaaS integrations.
2. Escalation happens when persistent delegated access lets the actor move through connected applications with a scope wider than intended.
3. Impact follows when the actor uses that access to reach sensitive SaaS data, trigger unwanted actions, or hide inside normal application relationships.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• 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

Agentic AI turns OAuth from delegated convenience into governance exposure. Persistent connections were designed for stable, human-defined workflows, where access could be reviewed against a known purpose and a known operator. That assumption weakens when the actor is non-human and can keep acting inside the same integration path across changing tasks and contexts. Practitioners need to treat delegation chains as active identity surfaces, not static plumbing.

Context, not token possession, is now the control boundary. The article’s most important signal is that Obsidian Security is framing SaaS risk as a relationship problem across SaaS, endpoint, network, and identity data. That is the right lens for a category where a token alone tells you too little about whether access is legitimate, excessive, or newly dangerous. The implication is that control models must understand application relationships, not just credential state.

Overly permissive OAuth is a standing privilege problem in SaaS clothing. The failure mode is not new, but agentic AI amplifies it because the same grants can now be used by non-human actors with independent runtime behaviour. OWASP-NHI and NIST-CSF both point toward governance that ties access to purpose, owner, and lifecycle. Practitioners should stop treating SaaS integrations as low-friction exceptions to identity policy.

Runtime identity monitoring becomes mandatory when autonomous actors enter enterprise apps. The presence of AI agents inside productivity and business systems means security teams need to distinguish normal app automation from access patterns that are self-directed, persistent, or unexpectedly broad. That distinction is now central to SaaS governance because a non-human actor can look legitimate while still exceeding the intent of the original authorization. Security teams should rework monitoring around actor behaviour, not just application inventory.

Identity blast radius is now the right measurement for SaaS and AI adoption. The question is no longer how many integrations exist, but how far a single integration can reach once copied, chained, or reused by an AI-enabled workflow. This is where lifecycle governance, access reviews, and integration ownership intersect. Practitioners should measure how quickly a token, app grant, or connector can expand from convenience to enterprise-wide exposure.

From our research:

• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• The broader lesson is that identity control fails fastest where ownership, review, and revocation are still treated as separate problems, so read Ultimate Guide to NHIs , Why NHI Security Matters Now for the governance baseline.

What this signals

Identity blast radius: SaaS programmes need a way to measure how far a single delegated grant can propagate once it is reused by copilots, agentic workflows, or adjacent applications. The useful metric is not integration count alone, but how many business systems one approval can eventually touch.

The shift here is toward lifecycle control for integrations rather than one-time approval. If ownership, scope, and revocation are not continuously maintained, persistent SaaS access becomes a quiet accumulation of privilege that security teams only notice after behaviour drifts.

With 44% of developers following security best practices for secrets management, the governance challenge is partly behavioural and partly structural, which is why identity, application, and workload context all need to be reviewed together.

For practitioners

• Inventory persistent SaaS delegations Build a complete register of OAuth grants, app-to-app links, and embedded copilots, then assign each one to a business owner and a renewal date. Focus on integrations that can reach mail, files, CRM, or ticketing systems because those grants create the widest practical blast radius.
• Separate AI-enabled workflows from standard automation Tag workflows that can initiate actions inside SaaS tools without direct human approval, and treat them as non-human identity pathways with explicit control boundaries. Use that distinction to decide whether the grant belongs in ordinary app administration or in identity governance.
• Review token behaviour and app relationships together Correlate token usage with workload context, in-app activity, and the expected relationship between the application and the data it touches. A token that looks valid can still be suspicious if it appears in a workload, geography, or application chain that does not match the approved use case.
• Reduce privilege before adding more AI integrations Remove unnecessary scopes from existing SaaS connections before onboarding additional copilots or agentic workflows. New AI capabilities inherit whatever privilege already exists, so the safest expansion path starts with shrinking the current delegation footprint.

Key takeaways

• Agentic AI exposes the weakness in persistent SaaS delegation, where access granted for one workflow can outlive its original purpose and expand the attack surface.
• The evidence points to a governance gap, not just a tooling gap, because token state alone does not reveal whether an application relationship is still safe.
• Security teams should manage SaaS integrations as identity objects with ownership, scope, and revocation, especially where non-human actors can reuse them at runtime.

Key terms

• Persistent OAuth grant: A persistent OAuth grant is a long-lived delegated permission that lets one application act inside another service without repeatedly asking for credentials. In governance terms, it is an identity relationship that can outlive the task it was created for and therefore needs ownership, review, and revocation controls.
• Non-human identity: A non-human identity is any machine-based actor that authenticates to systems, including service accounts, API keys, tokens, certificates, workloads, bots, and AI agents. The security problem is not the format of the credential, but whether the identity has lifecycle control, scope discipline, and accountable ownership.
• Identity blast radius: Identity blast radius is the amount of access, systems, and data that can be reached if one identity or delegated grant is abused. For SaaS and AI workflows, it measures how quickly a single connection can expand from a narrow integration into broad enterprise 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.

This post draws on content published by Obsidian Security: Leading SaaS security platform strengthens executive bench as the company scales toward growth funding. Read the original.