SaaS and AI tools outside SSO expose unmanaged identity risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on 1Password's event briefing: SaaS apps and AI tools outside SSO create unmanaged identity risk because they can retain valid access paths, hidden credentials, and forgotten OAuth connections.

Why it matters: IAM, PAM, and NHI teams need a governance model that can discover, review, and revoke non-SSO access across both SaaS and AI tools before it becomes standing privilege.

By the numbers:

• 52% of employees have downloaded apps without IT approval, according to 1Password.

Context

Unmanaged SaaS and AI tools outside SSO create a governance gap because traditional IAM assumes access flows through the identity provider, where it can be logged, reviewed, and revoked centrally. When users create or approve access outside that path, the organisation often loses visibility into who owns the account, what permissions were granted, and whether the access should still exist.

This matters for identity programmes because non-SSO access behaves like shadow identity infrastructure. The control problem is not only discovery of the app or tool, but lifecycle governance over the credentials, OAuth grants, shared accounts, and delegated permissions that sit behind it.

Key questions

Q: What breaks when SaaS apps are used outside SSO and central IAM?

A: The main failure is lifecycle control. If an app is not tied to SSO or the identity provider, offboarding, recertification, and access logging may never reach it. That leaves active accounts, orphaned licenses, and audit gaps even when the business believes access was removed.

Q: Why do OAuth connections create governance risk even when logins are valid?

A: OAuth connections create governance risk because they grant durable delegated access that can remain active long after the initial approval. If the scope is forgotten or the connected app is compromised, the attacker can operate inside the approved permission set without triggering a fresh authentication event.

Q: How should teams govern AI tool access without slowing adoption?

A: Use the same identity lifecycle controls you already apply to critical enterprise systems, then automate provisioning, role updates, and revocation so governed access is faster than ad hoc approvals. The goal is not to create a special AI process, but to make approved access the path of least resistance.

Q: What should teams do when shadow SaaS is discovered in a business unit?

A: Contain the risk by identifying the user, the data stored, and the business purpose, then decide whether to approve, migrate, or block the service. If the application is kept, it needs ownership, review cadence, and offboarding rules. If it is blocked, data removal must be verified.

Background and context

Why non-SSO access creates unmanaged identity paths

When a SaaS app or AI tool sits outside SSO, authentication and authorisation no longer pass through the organisation’s main policy checkpoint. That means the identity team may never see the initial grant, the scope of the permission, or the account owner after the fact. In practice, this shifts control from centrally governed federation to locally created access paths, which can persist even when the business forgets they exist. The risk is not just app sprawl. It is identity sprawl with no reliable lifecycle state.

Practical implication: inventory non-SSO access paths separately from SSO coverage and treat them as governed identities, not just applications.

How OAuth connections become standing privilege

OAuth grants are often created once and then left in place, which makes them a credential-like access path rather than a one-time login event. If a third-party tool is later compromised, the attacker can act within the approved scope without triggering failed-logon alerts or obvious privilege escalation signals. That is why these exposures evade controls that focus on authentication anomalies instead of delegated authority. The governance failure is persistence, not just initial approval.

Practical implication: review OAuth scope, owner, and business need as a lifecycle control, not a one-time onboarding check.

Why AI tool governance needs account ownership and deprovisioning

AI tools introduce the same access governance problem as SaaS, but with more frequent account creation, more fragmented admin consoles, and more difficulty proving who is using what. When access is assigned one-by-one across multiple tools, the identity model becomes operationally brittle unless provisioning, role assignment, logging, and deprovisioning are all tied to the same workflow. Without that, AI tool access becomes a collection of isolated accounts rather than a managed identity estate.

Practical implication: design AI tool access so provisioning, review, and offboarding are governed together, not handled as separate administrative tasks.

NHI Mgmt Group analysis

Non-SSO access is now a parallel identity estate: Once SaaS and AI tools are provisioned outside SSO, they stop behaving like ordinary app usage and start behaving like governed identities with their own ownership, lifecycle, and privilege history. Traditional IAM coverage does not automatically extend into that estate, so visibility has to be built around access pathways, not application lists. Practitioners should treat unmanaged tools as part of the identity control plane, not as a separate IT cleanup issue.

OAuth creates durable delegated trust, not just convenience: The security assumption behind OAuth is that delegated access remains appropriate for as long as the connection is valid, but many enterprises never re-evaluate that assumption after the initial grant. That leaves a trust relationship alive after the business context has changed. The implication is that access reviews must extend to third-party grants and not stop at employee accounts.

Unmanaged stack governance: This article sharpens a useful concept for the field: the unmanaged stack is the collection of SaaS, AI, and delegated access paths that sit outside central identity enforcement but still influence enterprise trust. That stack is not a fringe problem because it now carries authenticated access, shared accounts, and lifecycle blind spots. Practitioners should govern it as a first-class identity surface.

AI tooling makes offboarding and ownership harder, not easier: AI account sprawl turns a familiar SaaS governance issue into a faster-moving lifecycle problem because access is often created ad hoc across multiple consoles. The challenge is not merely discovery of tools, but proving who owns each account, what role it serves, and when it should be removed. Identity programmes need to measure offboarding completeness, not just account count.

Security teams should stop treating SSO as the boundary of identity governance: The real boundary is where the organisation can no longer prove who created access, why it was granted, and when it should be revoked. That boundary is now inside SaaS integrations, AI accounts, browser extensions, and shared credentials. Practitioners should reframe governance around provable access state rather than assumed central control.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Unmanaged stack governance: Identity teams should expect more enterprise access to sit outside SSO as SaaS purchasing and AI adoption remain decentralised. The practical question is no longer whether these tools exist, but whether the organisation can still prove who owns the access, who reviews it, and how quickly it can be removed.

The strongest programme shift is to treat SaaS integrations, AI accounts, shared credentials, and delegated permissions as one governance surface. If those elements are reviewed separately, risk hides in the gaps between IT, security, and application owners.

For practitioners

• Map non-SSO access paths Inventory SaaS apps, AI tools, OAuth grants, and shared logins that exist outside the identity provider so you can see where governance is missing.
• Review delegated OAuth scopes Check each third-party connection for scope, business owner, and continued need, then remove grants that no longer match current use.
• Assign ownership for unmanaged accounts Move sensitive or shared credentials into IT-owned governance so responsibility for review, access changes, and revocation is explicit.
• Build offboarding into AI tool lifecycle Tie provisioning, role assignment, usage logging, and deprovisioning together so AI accounts are removed when the business need ends.
• Track auditability for compliance evidence Preserve access-change logs for non-SSO tools so reviewers can reconstruct who had access, when it changed, and why it was retained.

Key takeaways

• Unmanaged SaaS and AI tools outside SSO create identity risk because access can be valid, delegated, and still outside central governance.
• The governance issue is lifecycle control, since forgotten OAuth grants and shadow accounts can outlive the business need that created them.
• Practitioners should shift from SSO coverage alone to provable ownership, review, and revocation across non-SSO access paths.

Key terms

• Unmanaged Stack: The unmanaged stack is the collection of SaaS apps, OAuth grants, shared credentials, and AI tools that operate outside central identity controls. It creates governance gaps because access may be real, active, and risky even when it never appears in normal SSO review or lifecycle workflows.
• 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.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Account Governance: Account governance is the set of controls that define who can create, change, approve, and review account activity across its lifecycle. For iGaming and fraud operations, it includes ownership, approval boundaries, auditability, and exception handling for risky actions.

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 building or maturing an IAM programme, it is worth exploring.