SaaS sprawl and shadow AI are exposing enterprise identity gaps

At a glance

What this is: This is an analysis of SaaS sprawl and shadow AI, arguing that unchecked app growth is creating identity and data governance gaps across enterprise SaaS environments.

Why it matters: It matters because identity teams now need visibility into human, non-human, and AI-mediated access paths across SaaS, not just formal application onboarding and provisioning.

By the numbers:

• Enterprises now average more than 1,000 SaaS apps, up 26% in two years.
• 80% of employees admit to using unauthorized SaaS or AI apps.
• Unauthorized SaaS or AI apps contribute to about 35% of data breaches.

Context

SaaS sprawl describes the steady expansion of cloud applications beyond what security teams can track with legacy inventories, while shadow AI adds another unmanaged layer through unsanctioned assistants, copilots, and embedded automation. When those services connect to enterprise data and identities, standard app governance breaks down because access paths, third-party integrations, and privilege relationships are no longer visible in one control plane.

The identity issue is not just who logged in, but which human users, service accounts, and AI-mediated workflows can move data between tools without consistent approval or monitoring. That makes this a governance problem as much as a security operations problem. For most organisations, the starting position is now typical rather than exceptional: app growth and visibility loss are becoming the norm.

Key questions

Q: Why do SaaS sprawl and identity governance fail in the same place?

A: They both depend on discovery happening before control. If applications are only found at purchase or SSO integration, finance cannot manage spend early and security cannot govern access early. The shared failure is late visibility, which turns both disciplines into cleanup functions instead of preventive ones.

Q: Why do unapproved SaaS and AI apps create identity risk?

A: They create risk because access can be granted once and then continue operating outside normal identity controls. Once an app has an OAuth token or similar delegated permission, the organisation may lose sight of who approved it, what scope it has, and when it should be revoked.

Q: How should security teams govern shadow AI in SaaS environments?

A: Security teams should inventory AI-enabled features, classify the data those features can touch, and enforce approved-use rules at the application and identity layers. The practical goal is not to block every model interaction. It is to ensure that prompts, file uploads, and connected data sources stay within defined risk boundaries.

Q: How can organisations tell whether SaaS access governance is actually working?

A: They should look for three signals: low numbers of orphaned accounts, consistent entitlement recertification, and rapid revocation when users change roles or leave. If access remains valid across apps after a lifecycle event, governance is not working even if dashboards look complete.

Technical breakdown

Why SaaS sprawl breaks identity visibility

SaaS sprawl fragments identity governance because each application creates its own access model, integration surface, and audit trail. In practice, security teams lose a single view of entitlements across SSO, native app roles, service accounts, and delegated third-party access. Traditional SSPM tools often struggle because they depend on prebuilt connectors and slower onboarding cycles, while the application estate changes faster than the control catalogue. The result is a growing mismatch between where identities can act and where security teams can actually observe them.

Practical implication: map identity and access paths across all SaaS apps, not just the sanctioned core set.

How shadow AI becomes an access-control problem

Shadow AI is not only a data leakage issue. Once employees use unsanctioned AI apps, browser extensions, or embedded agents, they may hand those tools access to content, files, and downstream SaaS actions without formal review. That creates hidden delegated trust relationships that behave like non-human identities, even when the tool was not designed as one. The security failure is not simply that an app exists, but that it can inherit access and move data outside approved governance boundaries.

Practical implication: treat unsanctioned AI tools as identity-bearing access paths and include them in access reviews.

Why graph-based SaaS mapping matters for SaaS-to-SaaS risk

Graph-based SaaS discovery models show how users, applications, and integrations connect, which is critical when risky relationships are indirect rather than obvious. A flat inventory can tell you that an app exists, but not that it has permission to pull data from another app through an integration token or delegated OAuth grant. In this environment, the meaningful security question is not just what is installed, but what data and privilege pathways exist between systems. That is where misconfiguration and over-permissioned integrations become operationally dangerous.

Practical implication: build control checks around cross-app integrations, delegated tokens, and SaaS-to-SaaS permissions.

Threat narrative

Attacker objective: The objective is to exploit hidden trust relationships inside SaaS and AI workflows to reach sensitive data or downstream business systems.

1. Entry occurs when employees introduce unsanctioned SaaS or AI tools into the environment without central review or inventory.
2. Credential and access abuse follow when those tools receive delegated permissions, integration tokens, or identity-linked access to enterprise data.
3. Escalation happens through SaaS-to-SaaS connections and misconfigurations that let a low-visibility app move laterally across workflows.
4. Impact is data exposure, unauthorized access, and breach contribution across a fragmented application estate.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• MongoBleed breach: MongoBleed exposed secrets across 87K MongoDB servers.

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

SaaS sprawl has become an identity governance problem, not just an inventory problem. Once enterprises cross the threshold into hundreds or thousands of SaaS services, the main control failure is no longer procurement sprawl but access opacity. Security teams cannot govern what they cannot enumerate, and that leaves entitlement review, third-party oversight, and offboarding incomplete. The practitioner conclusion is that SaaS governance now belongs in identity operating models, not only in application lists.

Shadow AI creates a hidden non-human access layer inside SaaS estates. The article’s core warning is that unsanctioned AI apps and agents inherit trust through the same integrations and permissions used by legitimate tools. That means identity governance has to distinguish sanctioned automation from unmanaged AI-mediated access, or the programme will miss the real control boundary. The practitioner conclusion is to classify these tools as access-bearing entities and govern them accordingly.

Graph visibility is the right mental model for modern SaaS control. The challenge is no longer isolated app permissions, but relationships among users, integrations, data paths, and delegated authorisation. A graph view makes cross-app trust visible in a way static inventories do not, which is why this topic sits at the intersection of SaaS security, IAM, and NHI governance. The practitioner conclusion is to prioritise relationship mapping over app counting.

_Unsafe delegation, not just unsanctioned software, is the named failure mode. The governance assumption that every app boundary is visible and reviewable no longer holds once users can connect tools and AI services without formal lifecycle control. This is the same class of failure that appears in overprivileged service accounts and untracked third-party access: trust was extended faster than governance could follow. The practitioner conclusion is to treat delegated access as a lifecycle event, not a one-time approval.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

SaaS sprawl has become a visibility test for identity programmes. If teams cannot tie app discovery to entitlement review and integration ownership, the estate is already larger than the governance model. The practical response is to move from periodic audits to continuous relationship mapping across SaaS, AI tools, and delegated access.

Shadow AI expands the control boundary beyond sanctioned applications. Once employees can connect unsanctioned tools to company data, the programme has to govern access pathways rather than just approved software lists. That is why lifecycle control over integrations and permissions matters more than app counts alone.

For practitioners

• Inventory SaaS and AI access paths continuously Track sanctioned and unsanctioned applications, integrations, and assistant-style tools together so identity, data, and delegation paths are visible in one programme.
• Review delegated access as an identity control Include OAuth grants, API tokens, and third-party app links in access governance, because these pathways create durable privilege even when the app itself looks benign.
• Classify shadow AI as a governance exception Require owners, business purpose, and expiry for any AI tool that can read, transform, or move enterprise data, even if it sits inside a familiar SaaS workflow.
• Prioritise cross-app misconfiguration checks Focus review on SaaS-to-SaaS connections, over-broad permissions, and stale integrations that can move data laterally across cloud applications.
• Tie offboarding to integration revocation Remove application access, tokens, and delegated permissions together when a user, team, or vendor relationship ends, rather than leaving dormant trust behind.

Key takeaways

• The core risk is not simply more software, but more hidden identity and data pathways than legacy controls can track.
• Visibility into app relationships, delegated permissions, and third-party integrations is now a prerequisite for SaaS governance.
• Teams that treat shadow AI as an identity and access issue will close more risk than teams focused only on approved application inventories.

Key terms

• SaaS Sprawl: SaaS sprawl is the uncontrolled spread of software-as-a-service applications across teams and business units. It creates fragmented ownership, duplicated functionality, and weak visibility into who can access what. For IAM and NHI teams, the main risk is not only cost but persistent entitlements that outlive business need.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• SaaS-to-SaaS Integration: A SaaS-to-SaaS integration is a machine-to-machine connection that lets one cloud application access another through delegated credentials. In NHI governance terms, it creates a persistent identity, a permission scope, and a lifecycle obligation that must be reviewed like any other access relationship.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, AI agent identity, and secrets management through the industry's only accredited NHI security programme. It helps practitioners connect identity controls to the broader access and governance problems that modern environments create.