Join our Newsletter — 33% off our NHI Course

What do organisations get wrong about managing access across SaaS tools and AI applications?

The most common mistake is managing assets without managing the identities behind them. Teams track subscriptions but miss who has access, whether that access is still appropriate, and what happens when roles change or employees leave. That gap leaves orphaned accounts, stale privileges, and unnecessary spend that can persist long after the original need has ended.

Managing access means managing the identity layer behind each app

The failure in most SaaS and AI environments is treating access as a software inventory problem instead of an authority problem. A subscription list may tell you which tools exist, but it does not show who can act, which approvals created that access, or whether those permissions still match the person, role, or workflow.

That distinction matters because access in SaaS and AI often accumulates through SSO, OAuth grants, service connections, shared admin roles, and delegated tool access. When those pathways are not governed as identities, organisations lose visibility into entitlement sprawl, orphaned access, and dormant but still-valid trust relationships.

The practical consequence is that access review has to start with the actor and the permission path, not the application name. A team can know every SaaS subscription and still miss the real security question: which identities can reach which data, perform which actions, and continue doing so after a job change or offboarding event.

Why SaaS sprawl and AI usage break old access assumptions

SaaS and AI application ecosystems are built for fast delegation. Users connect apps, grant consent, import data, and add assistants or automations that operate on their behalf. That convenience creates a gap between the original business approval and the current access reality, especially when access is inherited through integrations rather than assigned directly.

AI applications add another layer because the valuable question is not only whether a user can log in, but whether a connected tool, agent, or workflow can retrieve data, trigger side effects, or pass actions into other systems. Without explicit ownership of those pathways, access drift becomes invisible until a review, incident, or billing cleanup exposes it.

Good access design therefore needs to account for account lifecycle, delegated authorization, and the difference between interactive use and background use. In practice, that means permissions must be tracked at the level where they are enforced, not merely at the level where the application is purchased.

What should be governed to avoid stale access and hidden exposure

Organisations need a view of who owns each access path, how it is granted, and what evidence exists for its continued necessity. The most important objects are not just user accounts, but linked identities, API tokens, consented app connections, privileged roles, and any automation that can continue acting after the original user has moved on.

That is where many programmes fail. They review application ownership but not entitlement ownership; they rotate some credentials but do not revoke old grants; they offboard employees from email and HR systems but leave SaaS consents, connected tools, or shared admin access intact. The result is residual authority that is difficult to detect and easy to underestimate.

Strong programmes treat access governance as a lifecycle control: issue, approve, observe, recertify, and remove. For SaaS and AI, the recurring question is whether the access path still has a living business owner and a current business purpose. If either answer is unclear, the access is already a candidate for removal or reauthorization.

Risk and Threat Considerations

Unmanaged SaaS and AI access creates a compound risk: stale permissions can outlive the business need, and compromised connected accounts can expose far more than the visible user session. The same delegated access that improves productivity can also preserve attacker persistence, widen blast radius, and hide lateral movement through trusted integrations.

Failure mechanism: Excessive or orphaned access survives role changes, offboarding, and tool sprawl because organisations manage software inventory more consistently than they manage entitlement lifecycle and delegated trust.

Impact: Attackers and insiders can exploit dormant grants, shared roles, or forgotten API connections to reach data and actions that the business believes have already been removed, increasing breach scope and compliance exposure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-01 — Improper Offboarding Stale SaaS access after leavers and movers is the core failure mode here.
NHI-05 — Overprivileged NHI SaaS and AI integrations often accumulate excessive delegated authority.
NHI-07 — Long-Lived Secrets Persistent tokens and API keys extend access beyond the intended business lifecycle.
Recommendation — Revoke app grants, tokens, and delegated access when the owning identity changes or leaves. Limit each connected account or token to the minimum permissions needed for its function. Rotate or replace long-lived credentials with short-lived, tightly scoped access paths.
NIST SP 800-53 Rev 5 AC-2 — Account Management The question is fundamentally about governing who still has access and whether it remains appropriate.
IA-5 — Authenticator Management SaaS and AI access often persists through tokens, keys, and other authenticators.
AC-6 — Least Privilege Excessive permissions across SaaS and AI tools are a direct source of residual exposure.
Recommendation — Maintain complete account and entitlement records and disable access promptly when it is no longer required. Track, rotate, and revoke authenticators across the full lifecycle of each access path. Reduce each access path to the minimum privileges needed for the current task or role.
CIS Controls v8 CIS-5 — Account Management Account inventory and cleanup are central to controlling SaaS sprawl and stale access.
CIS-6 — Access Control Management The issue is not just software ownership, but whether access remains appropriate over time.
Recommendation — Inventory accounts and remove dormant or unauthorized access paths on a recurring schedule. Enforce access approvals, review entitlements, and revoke unnecessary permissions quickly.
ISO/IEC 27001:2022 A.5.15 — Access control Access governance across SaaS tools and AI apps directly maps to access control policy and enforcement.
Recommendation — Define and enforce access rules for every application and delegated connection.
CSA Cloud Controls Matrix IAM — Identity and Access Management Cloud-delivered SaaS and AI access depends on identity, entitlement, and lifecycle governance.
Recommendation — Govern identities, entitlements, and delegated access paths as a single control surface.

Practitioner Guidance

What to prioritise: Start with the highest-risk access paths, privileged SaaS roles, connected AI tools, shared admin accounts, and any token or consent that can reach production data or trigger downstream actions. If the access cannot be tied to a current owner and a current business purpose, treat it as an exception, not a normal state.

What to verify: Confirm that joiner, mover, and leaver processes revoke or reapprove not just the primary login, but every delegated grant, app connection, and machine-to-machine path associated with that person or workflow. The key test is whether offboarding actually removes the authority to act, not just the ability to sign in.

Practitioner takeaway: The best control is not a bigger app list, it is a reliable entitlement map that shows who can still act, through which trust path, and who is accountable for removing it when that need ends.