SaaS sprawl and shadow AI are exposing enterprise identity gaps

At a glance

What this is: This analysis argues that SaaS sprawl, shadow AI, and agent-driven integrations are outpacing legacy SaaS security visibility and control models.

Why it matters: It matters to IAM, PAM, and NHI teams because app sprawl now directly affects who and what can access sensitive data, and where hidden privileges sit.

By the numbers:

• On average, organizations now deploy over 1,000 SaaS apps, a number that has surged 26% in just two years.
• 80% of employees admit to using unauthorized SaaS or AI apps, which contribute to roughly 35% of data breaches.

👉 Read SentinelOne's analysis of SaaS sprawl, shadow AI, and identity risk

Context

SaaS sprawl creates an access governance problem before it becomes a tool problem. When business units can add applications and AI services faster than security can inventory them, identity, data, and privilege decisions move outside formal control planes. That leaves IAM, IGA, and PAM teams trying to govern access across systems they cannot fully see.

The article’s core concern is the intersection of shadow IT, shadow AI, and emerging agentic workflows. In that environment, the security question is no longer only whether a user has access, but whether a third-party integration, embedded AI app, or service account is now acting as a hidden non-human identity with real data reach. That is a typical failure mode when discovery lags adoption.

Key questions

Q: What breaks when SaaS sprawl is not governed as an identity problem?

A: When SaaS sprawl is not governed as an identity problem, organisations lose track of who can access what, through which apps, and by which delegated permissions. That breaks access review, makes offboarding incomplete, and leaves data exposure paths hidden in third-party integrations. Security teams then see alerts without context and cannot reliably revoke risky access.

Q: Why do shadow AI tools create access risk for IAM and PAM teams?

A: Shadow AI tools create access risk because they often authenticate with tokens, service accounts, or OAuth grants that sit outside normal review cycles. Once those permissions are granted, the tool can read or move data without a human in the loop. IAM and PAM teams should treat that delegated access as real privilege, not just application usage.

Q: How can security teams tell if SaaS access governance is keeping up?

A: Security teams can tell governance is keeping up when every material SaaS app has an owner, a documented data scope, and a reviewable access path. If new apps appear faster than discovery, if integrations are not catalogued, or if revocation depends on manual detective work, governance is falling behind the actual estate.

Q: Who is accountable when an unauthorized SaaS or AI app exposes data?

A: Accountability usually sits across security, identity, and the business function that approved or introduced the app. The practical test is whether the organisation can identify the owner, the data scope, and the revocation path before exposure occurs. Frameworks such as NIST CSF and NIST SP 800-53 both expect clear access governance and monitoring.

Technical breakdown

SaaS sprawl turns access governance into a discovery problem

Modern SaaS environments are hard to secure because the asset inventory is fluid. New applications appear through business-led procurement, trial sign-ups, and API connections, then start exchanging data before security teams have a record of them. Traditional SSPM tools usually depend on predefined app coverage and API integration work, which creates a gap when niche or AI-native services emerge weekly. The result is a fragmented view of identities, entitlements, and data movement across the stack.

Practical implication: security teams need continuous SaaS discovery tied to identity ownership, not periodic app lists.

Shadow AI and embedded agents behave like unmanaged non-human identities

A shadow AI tool is not just an unapproved application, it is often a runtime actor with delegated access to mail, documents, code, or records. That makes it operationally similar to a non-human identity when it can authenticate through tokens, OAuth grants, service accounts, or third-party integrations. The governance challenge is that these actors may not appear in identity reviews, yet they can read, transform, and forward sensitive data. If they are not mapped as identities with scope and lifecycle, their access is effectively invisible.

Practical implication: classify AI apps and integrations as identities when they hold tokens, grants, or persistent data access.

Graph-based context is the missing layer for SaaS risk decisions

A graph model helps security teams see relationships rather than isolated alerts. Instead of asking only which app is connected, the graph shows which user, integration, data object, and privilege chain connect across platforms. That matters because the riskiest exposure often sits in the relationship between systems, such as toxic SaaS-to-SaaS integrations or over-broad delegated permissions. This is where identity governance and SaaS security converge: the control failure is usually scope, not just application presence.

Practical implication: map delegated access paths and third-party app relationships before they become long-lived blind spots.

Threat narrative

Attacker objective: The attacker’s objective is to reach sensitive enterprise data through hidden SaaS and AI access paths that were never governed as part of the official identity estate.

1. Entry begins when employees adopt unauthorized SaaS or AI apps and connect them to corporate data without security approval.
2. Escalation occurs as third-party integrations, tokens, and delegated permissions accumulate across apps with little central oversight.
3. Impact follows when misconfigurations or rogue agent activity exposes sensitive data, expands lateral access, or enables breach paths that legacy tooling does not see.

NHI Mgmt Group analysis

SaaS sprawl has become an identity governance problem, not just an application inventory problem. Once business teams can onboard apps and AI tools outside IT oversight, the control question shifts from software approval to access lifecycle ownership. IAM and IGA models that depend on stable application registries no longer match the pace of adoption. Practitioners should treat discovery coverage as a prerequisite for governance, not a reporting feature.

Shadow AI should be treated as a non-human identity population whenever it authenticates, delegates, or persists access. If an AI tool can hold tokens, access documents, or act through third-party grants, it has crossed from usage into identity risk. That makes it part of the same governance problem as service accounts and API keys, even when the business describes it as a productivity tool. Practitioners should include these actors in identity inventory and review processes.

Graph-based visibility exposes the real failure mode: hidden trust relationships across SaaS and AI services. The risk is rarely a single app in isolation. It is the combination of over-broad delegated permissions, toxic integrations, and stale app-to-app trust that turns ordinary SaaS use into an access control issue. Practitioners should assess where privilege can move laterally between platforms without a human approval point.

There is a named concept here: SaaS identity sprawl. This is the condition where application growth, shadow AI adoption, and delegated integrations outpace the organisation’s ability to map who or what can access data. It creates governance debt because every unmanaged connection becomes another hidden access path. Practitioners should manage SaaS growth as a continuous identity risk, not as a periodic security review.

Security teams should expect AI-native SaaS to pressure existing SSPM assumptions. Coverage gaps, onboarding delays, and API-first integration models are increasingly visible in environments where new services appear weekly. That does not make legacy controls useless, but it does mean they are no longer sufficient on their own. Practitioners should re-evaluate whether their tooling can keep up with app velocity and delegated access change.

What this signals

SaaS identity sprawl is now a practical governance metric, not a theoretical concern. If an organisation cannot map every app, token, and delegated grant, its identity programme is already incomplete. That is where identity governance and SaaS security overlap, and where blind spots become breach paths.

The next control maturity step is not more alerts, but better ownership of access relationships. Teams should align discovery, review, and offboarding around the app-to-app trust chain so that hidden privileges do not survive longer than the business need that created them.

For identity-led programmes, the operational signal is simple: if you cannot explain which non-human actor can access which SaaS data set, the control boundary does not exist yet. That makes continuous mapping and lifecycle enforcement more valuable than periodic point-in-time review.

For practitioners

• Build a continuous SaaS discovery process Correlate application discovery with identity ownership, OAuth grants, and third-party integrations so new tools cannot remain invisible after procurement or self-service adoption.
• Classify shadow AI as governed access Require inventory and review of AI tools that hold tokens, API keys, or delegated permissions, and treat them as identities with scope, owner, and expiry.
• Review delegated app-to-app trust paths Identify SaaS-to-SaaS connections that can move data or permissions without a human checkpoint, then remove or narrow the grants that create lateral access.
• Tie SSPM coverage to identity lifecycle control Measure whether each high-risk app has an owner, a review cadence, and a removal path for unused grants, especially where the platform was added outside standard change control.

Key takeaways

• SaaS sprawl has shifted from an application management issue into an identity governance problem because access now expands faster than security inventories can track it.
• Shadow AI often behaves like an unmanaged non-human identity, especially when it holds tokens, delegated grants, or persistent data access across SaaS platforms.
• Continuous discovery, delegated-access review, and lifecycle ownership are the controls that turn SaaS visibility into enforceable governance.

Key terms

• SaaS Identity Sprawl: SaaS identity sprawl is the uncontrolled growth of applications, integrations, and delegated grants across a business environment. It matters because every new connection creates another identity and access relationship that security teams must inventory, review, and revoke when no longer needed.
• Shadow AI: Shadow AI is the use of AI tools, agents, or assistants outside approved governance and visibility. In practice, it often introduces unmanaged data flows and delegated permissions that behave like hidden non-human identities inside the enterprise.
• Delegated Access: Delegated access is permission granted to one service or application to act on behalf of a user, system, or other application. It is a high-risk control point because over-broad delegation can persist long after the original need has passed.
• Graph-Based Visibility: Graph-based visibility is a way of mapping relationships between users, apps, data, and permissions rather than examining each object in isolation. It helps security teams see how trust and access travel across SaaS and AI systems, which is often where the real risk sits.

What's in the full article

SentinelOne's full analysis covers the operational detail this post intentionally leaves for the source:

• How its graph-based SaaS mapping models users, data, apps, and third-party connections at runtime
• What its AppFactory approach means for onboarding new SaaS services in 3 to 5 days
• How the platform flags toxic SaaS-to-SaaS integrations, misconfigurations, and compromised accounts
• Why agentless API coverage changes the deployment burden for security teams

👉 SentinelOne's full post covers the graph-based detection model and SaaS app onboarding approach

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to govern access across dynamic estates. It helps identity and security teams translate discovery into lifecycle control and accountability.