Shadow access in cloud apps: the governance gap IAM misses

At a glance

What this is: This article explains how shadow access forms inside approved SaaS and cloud systems when permissions bypass formal identity governance.

Why it matters: It matters because IAM, IGA, PAM, and lifecycle programmes can miss app-native entitlements, leaving excess privilege, weak accountability, and audit gaps across NHI and human access.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read SecurEnds' analysis of shadow access in cloud and SaaS environments

Context

Shadow access is what happens when permissions are granted inside approved cloud or SaaS applications without flowing through formal IAM or IGA governance. The application is sanctioned, but the entitlement is invisible to central controls, so least privilege erodes quietly across human and non-human access.

That matters because app-native permissions, API tokens, service accounts, and emergency access often live outside the evidence trail that auditors and security teams rely on. The same governance gap that hides shadow access also explains why entitlement visibility and lifecycle control remain difficult to sustain at scale.

Key questions

Q: How should security teams detect shadow access in SaaS and cloud apps?

A: Start by discovering app-level roles, direct assignments, API tokens, nested groups, and emergency privileges, then compare them with central IAM and IGA records. The key is to find permissions created inside the application, because those are the ones most likely to bypass approval, certification, and lifecycle cleanup.

Q: Why does shadow access create a bigger risk than simple overprovisioning?

A: Overprovisioning can still be visible in central identity tools, but shadow access often sits outside them. That means reviewers do not see the true entitlement set, so excess privilege, toxic combinations, and lingering access survive longer and are harder to prove or remove.

Q: What do organisations get wrong about temporary access in SaaS platforms?

A: They treat temporary access as self-expiring when it usually depends on someone remembering to revoke it. Without an owner, expiry date, and post-use review, project rights, break-glass access, and token-based permissions become standing access that outlives the original business need.

Q: How do identity teams govern direct role changes made inside applications?

A: They need to reconcile in-app changes back into the identity source of record and require those changes to appear in certification, audit, and remediation workflows. If app-native assignments remain outside governance, the organisation is managing only the directory, not the real access model.

Technical breakdown

How shadow access bypasses IAM and IGA workflows

Shadow access emerges when entitlement changes happen in the application layer instead of the identity plane. A SaaS admin can assign roles, connect integrations, or approve add-ons directly in-console, while IAM and IGA continue to reflect only directory state. That split creates a control-plane mismatch: the user looks ordinary in identity tooling, but carries privileges that were never requested, approved, or reviewed centrally. The result is not just missing documentation. It is a live access path that governance does not know exists.

Practical implication: extend discovery and certification to app-native entitlements, not just directory groups.

Why SaaS roles and nested permissions hide excess privilege

SaaS platforms often bundle capabilities into broad roles, inherited permissions, or nested groups that look harmless by name but expand significantly underneath. Shadow access grows when teams assign these roles for speed and never normalize what the role actually allows across systems. A reviewer sees a label such as admin or contributor, but not the cumulative effect of multiple roles, inheritance chains, or direct assignments. That is how toxic combinations form without a single dramatic change event.

Practical implication: normalize entitlement meaning across applications before approving or recertifying access.

Why API tokens and emergency access become durable risk

Tokens and break-glass permissions are frequently created as temporary exceptions, then left to persist because no expiry, owner, or post-use review exists. Unlike interactive user accounts, these credentials do not surface through human login patterns, so standard reviews miss them. The control failure is governance continuity: access was granted for a moment, but the lifecycle never ended. In practice, temporary access becomes standing access, and the organisation loses the ability to explain why the privilege still exists.

Practical implication: tie every token and emergency credential to an owner, expiry, and cleanup workflow.

Threat narrative

Attacker objective: The objective is to preserve hidden, high-value access paths that can be abused or forgotten without triggering central governance controls.

1. Entry occurs when permissions are assigned directly inside SaaS consoles or through connected integrations outside centralized IAM and IGA review.
2. Escalation follows when broad roles, nested entitlements, or lingering tokens create access combinations that exceed the original business need.
3. Impact arrives as untracked privilege expands the blast radius of compromised accounts and makes audits, investigations, and separation-of-duties checks unreliable.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow access is a governance failure, not an IT nuisance. The article describes sanctioned systems accumulating unsanctioned permissions, which means the break is inside the identity process itself, not outside it. IAM tools that only see directory state cannot explain app-native roles, API tokens, or local admin grants. The practical conclusion is that access governance must follow where the entitlement is actually created.

App-native entitlement drift is the real control gap here. Direct role assignment inside SaaS platforms, especially when combined with nested permissions and broad default roles, creates access that exists outside the approval record. That means the organisation can be compliant in the directory and still be exposed in the application. Practitioners should treat the entitlement catalog inside each app as a governed system of record, not a side channel.

Shadow access turns lifecycle management into a blind spot when ownership is missing. The article’s examples of tokens, service accounts, temporary project access, and emergency privileges all fail the same way: nobody is accountable for removal. This is where human, NHI, and PAM governance converge. Access that is granted quickly but never retired becomes a standing control failure, and that is what teams must eliminate.

Shadow access creates identity blast radius by collapsing separation of duties. Overlapping roles across SaaS apps can make approve, modify, and audit actions coexist in the same account, even when no one intended that outcome. That is why entitlement review cannot stop at single-system permissions. The practitioner implication is to examine cross-app combinations, not isolated role names.

Identity review fatigue: recurring access reviews fail when reviewers cannot see app-level entitlements, token ownership, or inherited permissions. The article shows why periodic review alone is too weak if the data feeding it is incomplete. That failure mode is especially dangerous for NHI governance, where tokens and service accounts rarely appear in human-centric review workflows. Teams should treat visibility quality as the first control, not the last.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
• For a deeper control baseline, review OWASP Non-Human Identity Top 10 alongside app-level entitlement discovery.

What this signals

App-native access will keep outrunning directory-centric governance until teams treat SaaS entitlements as first-class identity objects. The practical signal is simple: if reviewers cannot see the entitlement where it is created, they cannot govern it where it matters. With 97% of NHIs carrying excessive privileges, the same overreach is likely to surface in unmanaged SaaS permissions unless entitlement discovery is broadened.

Shadow access also exposes a lifecycle problem, not just a visibility problem. Temporary grants, service accounts, and break-glass credentials need ownership and retirement paths, otherwise they become permanent exceptions. That is why teams should align access review, offboarding, and PAM workflows across both human and non-human identities.

Identity review fatigue: when app-level permissions are missing from the review pack, certifications become performative rather than corrective. The next phase for mature programmes is to connect entitlement data, lifecycle triggers, and audit evidence into one continuous governance loop.

For practitioners

• Extend certification to app-native entitlements Include SaaS roles, inherited permissions, API tokens, and service accounts in access reviews so the review scope matches where privileges are actually granted.
• Eliminate unowned temporary access Require every project role, emergency grant, and token to have an owner, an expiry, and a documented cleanup path before it is approved.
• Normalize role meaning across platforms Build a translation layer for role names and bundled permissions so reviewers can compare what admin or contributor means in each SaaS application.
• Audit manual exceptions back into governance Detect direct console changes and reconcile them into IGA records so app-level permissions do not drift away from the identity source of record.

Key takeaways

• Shadow access is dangerous because it hides inside approved systems, where centralized IAM often cannot see the entitlement.
• The article shows that direct role grants, broad SaaS defaults, and forgotten tokens create durable privilege that outlives the work that justified it.
• The control answer is not more periodic review alone, but app-level discovery, ownership, expiry, and reconciliation back into governance workflows.

Key terms

• Shadow Access: Shadow access is permission that exists inside an approved application but outside formal identity governance. The application is sanctioned, yet the entitlement bypasses centralized request, approval, certification, or offboarding controls, creating access that works but is poorly governed.
• App-native Entitlement: An app-native entitlement is a role, permission, token, or integration grant created directly inside the application rather than through the central identity plane. These entitlements are often the hardest to govern because they live where work happens, not where identity teams usually look.
• Toxic Permission Combination: A toxic permission combination is a set of individually acceptable permissions that becomes risky when combined, such as approve, modify, and audit in the same account. The danger comes from cumulative capability, not a single obviously privileged role.
• Identity Source of Record: An identity source of record is the system that should define and reconcile the organisation’s view of access. For shadow access, the challenge is that the source of record often excludes in-app grants, so the real entitlement state diverges from governance data.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by SecurEnds: shadow access in cloud and SaaS environments. Read the original.