AI agents and SaaS integrations demand tighter identity governance

At a glance

What this is: NHI Mgmt Group's analysis, drawing on AppOmni's blog post: AI, SaaS sprawl, and third-party integrations are widening the attack surface, and visibility without identity governance is no longer sufficient.

Why it matters: IAM, NHI, and SaaS security teams need to govern AI agents, OAuth connections, and entitlements as one control problem because each can expand blast radius faster than legacy monitoring can react.

Context

RSAC 2026 reinforced a familiar governance gap: organisations can see more activity in SaaS, but still fail to control who or what is acting inside it. The issue is not observation alone, but whether identities, configurations, and third-party connections are governed as one system, especially when AI is added to the mix.

In practice, AI and SaaS risk now overlap through delegated access, automation, and hidden integration paths. That makes the problem a SaaS-to-SaaS and OAuth app governance issue as much as a monitoring issue, because the control boundary has moved from the application perimeter to the identity and consent layer.

Key questions

Q: What should teams do first when SaaS integrations are overprivileged?

A: Teams should first inventory the connected apps, tokens, and automation links, then revoke anything unused and reduce the remaining scopes to the minimum required. The quickest controls are removing stale OAuth grants, rotating API keys, and forcing reauthorisation for privileged integrations. That stops overprivileged SaaS access from persisting through hidden machine credentials.

Q: Why do AI agents create more identity risk than ordinary SaaS integrations?

A: AI agents can operate continuously, chain multiple tools, and act on delegated permissions with little human oversight. That makes their effective privilege broader than the original approval suggests. The risk is not only access, but the speed and persistence with which the agent can turn access into credential exposure or lateral movement.

Q: Why do OAuth tokens and service accounts increase SaaS supply chain risk?

A: They create persistent, non-human access paths that do not depend on repeated MFA or user interaction. Once granted, they can cross systems, retain broad privileges, and remain active long after the original business need changes, which expands the attack surface without a visible procurement event.

Q: When should security teams prioritise SaaS monitoring over cloud posture checks?

A: Security teams should prioritise SaaS monitoring over cloud posture checks when the main risk sits in application permissions, OAuth grants, user behaviour, or data sharing inside the SaaS platform itself. Cloud posture checks assess infrastructure configuration, while SaaS monitoring looks for risky logins, excessive sharing, malicious app consent, and abnormal token use.

Technical breakdown

Why SaaS visibility does not equal control

SaaS monitoring can show activity, but it often misses the governance state behind that activity. In SaaS environments, risk is distributed across OAuth grants, admin roles, service accounts, configuration drift, and tenant-to-tenant connections. A monitoring tool can surface events after the fact, but it cannot on its own decide whether a connected app should exist, whether a token scope is excessive, or whether a stale entitlement should still be valid. See the SaaS Security Guide.

Practical implication: Build controls that review consent, scopes, and entitlements continuously instead of relying on point-in-time audits.

How AI agents change the identity problem in SaaS

An AI agent is not just another workflow engine. It can select actions, invoke tools, and interact with SaaS systems through credentials or delegated permissions, which makes its runtime behaviour closer to an identity than a static application feature. That changes the risk model: the question becomes who authorised the agent, what it can reach, and how its access is constrained when it starts chaining tools or data sources. See the AI Coding Agents Security Guide.

Practical implication: Treat agent permissions as governed access paths with explicit scope, lifecycle ownership, and revocation criteria.

Why third-party integrations are now part of the attack surface

SaaS-to-SaaS connections extend trust beyond the first application. Once OAuth tokens, webhooks, API keys, or automation links are in place, an attacker who compromises one trusted integration can often pivot into connected services without traditional perimeter detection. That is why legacy cloud posture tooling often underestimates SaaS risk: the exposure sits in consented trust relationships rather than in infrastructure misconfiguration alone.

Practical implication: Inventory connected apps, map their trust chains, and revoke unused or overbroad integrations before they become lateral movement paths.

Threat narrative

Attacker objective: The objective is to turn trusted SaaS connectivity into a fast path for data access and persistence across multiple applications.

1. Entry occurs when attackers abuse SaaS-to-SaaS trust relationships, compromised OAuth tokens, or weakly governed integrations to enter the environment through a legitimate connection path.
2. Credential access follows when stolen tokens, reused credentials, or over-scoped access grants let the attacker operate inside the SaaS layer without triggering perimeter controls.
3. Escalation happens as the attacker moves through additional connected apps, expanding access across identities, data sets, and automation paths that were never intended to be chained together.
4. Impact is data theft, business disruption, or broader SaaS supply chain compromise because the trusted integration model gives the attacker multiple paths to operate after the initial foothold.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

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

AI agents turn SaaS access into governed identity, not just automation. Once an agent can act, choose tools, and reach sensitive data, the governance question becomes who owns its permissions and how those permissions are revoked. That makes AI agents part of identity governance rather than a separate security category. Practitioners should assess agent authority with the same discipline used for other privileged non-human access.

Continuous monitoring matters only when it is tied to consent and entitlement state. SaaS environments change too quickly for periodic review to keep pace with new apps, rotated tokens, and shifting roles. The control gap is not a lack of telemetry, but the absence of lifecycle governance over who can connect, what they can access, and whether that access still makes sense. Security teams should move from event visibility to access validation.

Third-party SaaS connections now form a supply-chain identity problem. A connected app can become a trusted extension of the tenant without being governed like one, which creates a hidden path for misuse. This is where SaaS-to-SaaS governance becomes operationally important: consent, scope, and offboarding have to be tracked as part of the security model. Practitioners should treat every external integration as a revocable trust relationship.

Context-aware automation is the next security requirement. AI can reduce noise, but only if it is grounded in the right data and bounded by policy. Without that foundation, automation accelerates alert volume instead of decision quality. Security teams should use AI to prioritise investigation and enforcement, not to replace the governance decisions that determine what is allowed in SaaS in the first place.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Context-aware detection will matter more than raw alerting. SaaS programmes are producing more signals, but without a policy layer those signals just increase analyst fatigue. The next control step is to decide which identity, consent, or integration events should automatically trigger revocation, not just review.

AI governance and SaaS governance are converging. As agents and automation become part of day-to-day operations, the same controls that govern consent, scope, and lifecycle now need to cover machine-driven actions too. The programmes that separate AI from identity will miss the fastest-growing exposure path.

Third-party exposure remains the weak point in SaaS security: according to the Ultimate Guide to NHIs, 92% of organisations expose NHIs to third parties, raising concerns about supply chain security. The practical implication is that every connected app, token, and webhook needs an owner, a scope limit, and a revocation path before it can be trusted in production.

For practitioners

• Govern AI agents as non-human identities Assign ownership, scope, and revocation rules to each agent that can act in SaaS, especially where it can call tools or access sensitive records. See the AI Coding Agents Security Guide.
• Enforce continuous review of SaaS entitlements Replace periodic access checks with continuous validation of roles, consent grants, and inactive accounts across core SaaS services.
• Inventory and constrain third-party connections Track OAuth apps, webhooks, API keys, and automation links as part of the security inventory, then remove any integration that no longer has a clear business owner.
• Prioritise context over alert volume Use correlation and enrichment to surface the highest-risk SaaS changes first, so analysts can focus on exposed identities, risky integrations, and abnormal delegation.
• Test revocation before a breach does Verify that token revocation, app disablement, and integration offboarding actually cut off access across connected SaaS services, not just in the source system.

Key takeaways

• AI adoption in SaaS is increasing the importance of governance over identities, integrations, and context, not just telemetry.
• The main control gap is the disconnect between what SaaS monitoring can observe and what it can actually authorise or revoke.
• Security teams should manage AI agents, OAuth connections, and stale entitlements as one access problem rather than three separate ones.

Related NHI Mgmt Group resources: SaaS-to-SaaS and OAuth App Governance Guide · AI Coding Agents Security Guide · CI/CD Pipeline Identity Security Guide · SaaS Security Guide

Key terms

• SaaS Security Posture Management (SSPM): SaaS Security Posture Management is the ongoing practice of finding and correcting security weaknesses across software-as-a-service applications. It monitors configuration, access, data sharing, authentication, and third-party integrations to reduce exposure. In technical terms, SSPM enforces policy across SaaS tenants, identities, permissions, and risky settings through continuous assessment and remediation.
• 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.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• AI Agents: AI agents are autonomous software entities that act within organisational environments and make runtime decisions within assigned boundaries. They can hold identities, authenticate to systems, and exercise permissions, which makes them comparable to other non-human identities that require inventory, governance, and continuous activity monitoring.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and workload identity in practical terms. It helps security teams connect identity control to the wider programmes they run across SaaS and cloud.