A user's permission listing shows no administrative access. They are not a member of the admin group. Nobody granted them an administrative role. By every direct check, they are an ordinary user, and an access review that reads role assignments would confirm exactly that.
They can still become an administrator, in a small number of steps, without anyone needing to grant them anything else, because a different permission they already hold, one that looks unrelated and was granted for an unrelated reason, lets them modify something that leads there. This is a shadow admin, and it exists in most identity and access systems of any real size, invisible to a review that only checks direct assignments.
Why the direct check is not enough
Permission systems in directories and cloud platforms are graphs, not lists. A user's effective access is not just what they were directly assigned, it is everything reachable by following every edge outward from that assignment: group memberships, delegated permissions, resource ownership, the ability to modify a policy that itself grants access, and any chain of these that eventually arrives somewhere privileged.
An access review that lists what a user was granted is checking one node in that graph. The actual question, what could this user ultimately do, requires walking the whole graph outward from that node, and most reviews, tooling, and mental models stop at the first hop because that is what the interface shows and what a person can hold in their head while reading a list.
The shapes this actually takes
A user with permission to add members to a group that is not itself administrative, but which is nested inside, or granted access by, a group that is. Adding themselves to the intermediate group, if they have that permission and the nesting is not obvious from either group's name, produces administrative access through two ordinary-looking steps neither of which individually looks like a privilege grant.
A user with permission to reset another user's password or modify their account, where that account happens to have administrative access. This is a common and often deliberately intended capability, help desk staff need to reset passwords, and it becomes a shadow admin path specifically when the scope of accounts it applies to is broader than intended, including administrative accounts that should have been explicitly excluded from that delegation.
A user with permission to modify a policy, role definition, or permission set, rather than being a member of the privileged group directly. Editing the definition of what a role grants is functionally equivalent to being granted that role, and it is a permission that is frequently delegated for entirely reasonable operational purposes without anyone tracing through what modifying that specific object ultimately controls.
Ownership of a resource that has administrative implications, in cloud platforms specifically, where being the owner of an object, a repository, a service, a piece of infrastructure, carries an implicit ability to modify its access controls, which can include granting the owner themselves broader access than the role that made them the owner was ever meant to imply.
Why this is not usually deliberate wrongdoing
The overwhelming majority of these paths exist because two entirely reasonable, individually correct permission grants happen to compose into something nobody intended. A help desk role that can reset passwords, and an onboarding process that put every account, including administrative ones, in the same account pool that role applies to. A delegation of group management to a team lead, and a group nesting structure that was built later by someone who had no reason to think about who already had permission to modify group membership.
Neither grant, examined on its own, looks like a privilege escalation path. The escalation exists entirely in the composition, which is exactly the property that makes it invisible to a review process built around examining individual grants rather than tracing the graph they collectively form.
What actually finds these
Tooling built specifically to compute effective, transitive access rather than direct assignments, which exists for major cloud platforms and for common directory services, and which answers a fundamentally different question than a standard access review does: not what was this user granted, but what can this user ultimately reach by following every available path outward from what they hold.
Reviewing delegated administrative capabilities, specifically who can modify group membership, role definitions, and policy objects, as its own category, separate from and in addition to reviewing who holds administrative roles directly. The ability to grant access is itself access, and treating it with less scrutiny than the access it grants is precisely the gap this whole category exploits.
Explicitly excluding privileged accounts, groups, and role definitions from broader delegations, so that a help desk capability to reset passwords, or a team lead's ability to manage group membership, is scoped to exclude anything administrative by construction, rather than depending on the delegation happening to be narrow enough in practice that nobody has yet found the gap.
Periodically tracing the actual path from a small number of specific, ordinary-looking accounts to see what they can ultimately reach, rather than relying exclusively on tooling to surface every path automatically. Picking a handful of accounts with permissions that look unremarkable and manually tracing what they can modify, and what modifying that leads to, finds paths that automated graph analysis sometimes misses because the analysis was scoped to a particular system rather than the full chain across systems a real attacker would actually use.
Check yours
Pick an account with an ordinary-looking, non-administrative permission, ideally one involving the ability to modify group membership, reset a password, or edit a policy or role definition, and trace outward from it by hand: what can this permission be used to change, and does that change lead anywhere privileged, directly or through another hop. This single manual exercise, done once, against a genuinely representative account rather than a hypothetical one, finds a meaningful share of the shadow admin paths that exist in most systems of any real size.
The concession
Delegating administrative-adjacent capabilities, password resets, group management, policy editing, is necessary for any organisation past a very small size, because centralising every one of these operations with a small administrative team does not scale, and building a system with zero delegated capability of this kind trades a real, immediate operational cost for a theoretical reduction in a risk that proper scoping can address more directly.
The realistic target is not eliminating delegation. It is scoping every delegated capability explicitly to exclude the paths that would make it equivalent to full administrative access, and reviewing that scoping periodically as the underlying group structure, role definitions, and account population inevitably change around it.
The implication
An access review that only checks direct role assignments is checking whether the front door is locked while a series of individually reasonable side doors, none suspicious on their own, compose into a path around it.
Trace the graph from a handful of ordinary accounts, specifically the ones with any capability to modify group membership, reset a password, or edit a permission definition. What you find is very likely not the result of anyone doing anything wrong. It is the predictable, quiet cost of permission systems that were built one reasonable grant at a time, by different people, none of whom were looking at the whole graph.
