It sounds like simple question any team should have an immediate answer to.

However, this question is underspecified in ways that most organizations never bother to articulate, and the result is that access reviews produce answers that range from incomplete to meaningless. Not because the teams doing them are necessarily incompetent, but because the industry lacks a shared understanding for what “access” actually means in practice.

The problem with “access”

Suppose you’re asked: who can edit DNS records in Cloud DNS on Google Cloud Platform?

Your first instinct might be to check who has the dns.changes.create permission on the DNS zone. You look at any predefined and custom IAM roles containing that permission, IAM bindings for that resource, find the employees with matching roles, and hand over a list.

Except that list is incomplete in ways you (or your auditor) haven’t scoped.

Maybe a user doesn’t have the permission directly, but they’re in a group that does. Maybe the binding isn’t on the zone itself, but on the project that contains it, or the folder above that project, or the organization above that folder. Maybe the user has no binding anywhere, but they can impersonate a service account that does. Maybe they can impersonate a service account that can impersonate another service account that has access through a group membership inherited from a folder three levels up. Maybe the user has no current access at all, but they possess the power to grant it to themselves at any time: a permission that only wakes up when they decide to edit an IAM policy or role somewhere else.

All of these are real and all of them answer “who has access” differently. However, most access reviews stop looking at the first or second layer.

The root issue is that we’re conflating fundamentally different things under a single word. To have a useful conversation about access, I believe it’s necessary to distinguish between three broad categories: effective access, assumable access, and escalatable access.

The examples throughout this article use Google Cloud Platform because that’s where I work the most daily, but nothing here is GCP-specific. AWS has an arguably more complex IAM system, with largely the same patterns involving IAM roles, SCPs, resource policies, and cross-account role assumption. Azure has management group inheritance, managed identities, and service principal impersonation. Hence, the underlying problem is structural: any system with hierarchical resource organization, group-based policy resolution, and delegated identity mechanisms will produce the same complexity.

Effective access

Effective access is the set of permissions a principal can exercise right now, without performing any intermediate action. The principal navigates to the resource, performs the operation, and it works. No impersonation, no credential exchange, no role modification needed.

This is what most people picture when they hear “access,” but even this category is more complex than it first appears. The principal might hold the permission through any of several mechanisms:

The simplest is a direct binding: the user is bound to a role containing the permission on the resource itself. Then there’s group-mediated access: the user is a member of a group (or a complex nested chain of groups) that holds the binding. On top of this, there’s hierarchy inheritance: the binding exists on an ancestor resource, such as a project, folder, or organization, and propagates down.

These mechanisms are orthogonal and composable: a user might be a member of a group that is a member of another group that has a role binding on a folder, and that binding propagates to a project, which contains the resource. The result is an access path of length four or five, but the access is still effective, meaning the user can exercise the permission immediately, right now, without doing anything first.

The length of the access path matters, but not for whether the access exists. It matters for auditability. A direct binding on a resource is visible, easy to review and more likely to be intentional, while a nested group membership inherited through three layers of resource hierarchy is harder to discover, and more likely to be accidental or ungoverned. Access path length can be a useful proxy to determine how likely the access is unintentional.

Assumable access

Assumable access is when a principal does not have effective access to a resource, but can obtain it by assuming a different identity. The defining operation here is identity impersonation: the principal temporarily becomes another principal and inherits that principal’s effective access in whole or in part.

The most obvious example in GCP is service account impersonation. A user with the iam.serviceAccounts.getAccessToken permission on a service account can mint tokens as that service account. If the service account has effective access to the resource, the user can reach it through impersonation. And just like effective access, the service account’s path to the resource itself might be mediated through groups, inheritance, or both.

This creates two independent path dimensions. The assumable path is the chain of identity assumptions: how does the user reach the target identity? The effective path is the chain from that identity to the resource. The composition of both results in the total access path.

Service account impersonation can also chain. A user impersonates service account A, which can impersonate service account B, which has the role binding. Each hop adds a layer of indirection and, more often than not, a layer of unintentionality.

But impersonation through the IAM API isn’t the only way to assume an identity. Consider a user who can SSH into a VM, or deploy code to a Cloud Run service, or trigger a Cloud Build pipeline. Each of these workloads runs with an attached service account. If the user can execute arbitrary code in a workload’s context, they effectively have access to its credentials. This is identity assumption through compute access rather than through the IAM impersonation API, but the end result is the same: the user acts as the service account.

These paths are harder to enumerate because they cross the boundary between IAM analysis and infrastructure or application analysis. IAM tooling can tell you who can impersonate a service account. Understanding that a user can push code to a Cloud Run service which runs as that service account requires understanding the deployment pipeline, repository permissions, and CI/CD configuration. The access path exists, but because it lives in a different system it’s easy to overlook it.

Where federated identities fit

Identity federation adds another dimension to assumable access. In workload identity federation, an external identity, such as a GitHub Actions runner, an AWS role, or a CI/CD pipeline in another platform, can exchange its native credentials for short-lived GCP credentials. The federation configuration defines which external identities map to which GCP principals.

This means the question of “who has access” can extend outside your cloud boundary entirely. If a GitHub Actions workflow for a specific repository has federated access to a GCP service account, then anyone who can create or modify workflows in that repository effectively has assumable access to whatever that service account can reach. The user’s credential never touches GCP directly: they push a commit to a repository, a workflow runs, it federates into a GCP identity, and that principal has effective access to your resources.

Federated identity is particularly challenging for access reviews because the trust boundary is defined in configuration of the workload identity pool and in an external system’s permission model. You won’t find these paths by examining role bindings just in the resource’s platform alone. You need to trace the federation configuration, understand the external identity provider’s authorization model, and map backward from “who can assume this external identity” all the way to “which principals are able to grant or influence access along that path.”

The AI agent identity problem

This is about to get even more complicated. Cloud providers are introducing first-class identity types for AI agents, and these create entirely new assumable access paths.

Google Cloud’s Vertex AI Agent Engine now supports agent identity as an IAM principal type. Agents get their own principal identifiers in the format principal://TRUST_DOMAIN/NAMESPACE/AGENT_NAME, and you can bind IAM roles to these identities just like you would for users or service accounts. From an access review perspective, this means agents are principals that can hold effective access to resources.

Where they differ from traditional service accounts is in their constraints. Agent identities cannot be directly impersonated by another principal through the IAM API. There are also no downloadable keys to create, rotate, or leak. The credentials are cryptographically bound to the agent's runtime environment on Vertex AI through certificate-bound tokens and mTLS, which means stolen credentials are not replayable outside that context. In practice, they are more restricted service accounts: scoped to a specific workload, tied to its lifecycle, and stripped of the portability that makes service accounts both useful and dangerous. This matters for access analysis because the assumable access path to an agent's permissions doesn't run through impersonation or credential theft. It only runs through the ability to invoke the agent itself, which is a fundamentally different trust boundary.

The assumable access question then becomes: who can invoke the agent? If a user can send requests to an agent, and that agent has IAM permissions to perform actions on resources, the user has indirect access to those resources through the agent. The agent is an intermediary identity, similar in structure to a service account, but with a critical difference: the agent’s behavior is driven by a language model that interprets natural language instructions, not by deterministic code. The blast radius of “access through the agent” is harder to scope because it depends not just on what permissions the agent holds, but on what the agent can be instructed to do.

Agent identity also composes with everything else. An agent might use a service account for some operations, federate into external services for others, and hold direct IAM bindings on GCP resources. Mapping the full access surface of “user can talk to agent” requires tracing through all of these paths.

We are early in understanding what governance looks like for agent identities. But one thing is already clear: any access taxonomy that doesn’t account for non-human, non-deterministic intermediaries is very likely to age poorly.

Escalatable access

The third category is fundamentally different from the first two. Effective access and assumable access describe paths that exist. Escalatable access describes the ability to create paths that don’t exist yet.

A user with resourcemanager.projects.setIamPolicy on a project can add any role binding they want to that project. They might not have dns.changes.create right now, but they can grant it to themselves at any time. For example, a user who can impersonate a service account that has setIamPolicy on a folder can modify IAM bindings on that folder and everything below it. More subtly, a user might be able to modify their own roles: impersonate a service account that has the ability to edit the role definition or IAM policy that applies to the user’s own principal.

This is where I’d argue that access review becomes vulnerability analysis. The access path doesn’t exist yet. The user has to construct it. But if they can construct it, the access is effectively attainable from a security perspective.

Tools like PMapper exist specifically for this kind of analysis. They model IAM as a directed graph and traverse it to find escalation paths: edges that don’t represent current access, but the ability to create it. This is computationally expensive and, in the worst case, the graph of potential escalation paths grows combinatorially.

For most access review purposes, escalatable access is where you draw the line and say “this is a different exercise.” Certifying effective access is a governance activity. Reviewing assumable access is a more sophisticated governance activity. Finding and closing escalatable access paths is a security engineering problem. The vocabulary matters because it lets you be explicit about which problem you’re solving and where the boundary is.

The one exception is privileged access management. PAM and JIT access systems are, by design, sanctioned escalation: a user requests elevated permissions, approval is granted (by a human or a policy), and temporary bindings are created. This is escalatable access that’s been formalized into a workflow with controls around it. When an auditor asks about access, whether PAM grants count depends entirely on whether they’re asking about “access right now” or “access that could exist.”

In conclusion

Without shared vocabulary, every access review is a negotiation. The auditor asks “who has access,” the security team counters with “what do you mean by access,” and both parties waste time arriving at an ad hoc definition that won’t be consistent with the next review or third-party’s interpretation.

With a taxonomy, you can scope the question precisely. “Show me all principals with effective access to production DNS zones” is tractable and well-defined. “Show me all principals with assumable access, including compute-mediated impersonation” is harder but still scoped. “Show me all escalation paths to DNS write access” is a different project entirely.

This vocabulary also gives you a framework for evaluating tooling. Most cloud IAM analysis tools, including the built-in policy analyzers, primarily cover effective access. Some are specifically designed for escalatable access. Almost none handle compute-mediated assumable access or federated identity paths. Knowing which category you’re trying to cover tells you which tools are fit for purpose and where you have gaps.

More importantly, it lets you be honest about what you don’t know. Most organizations think they govern effective access reasonably well, some might even partially cover assumable access through service account reviews, but very few touch escalatable access. That is defensible, as long as it is known, understood, and stated explicitly. Issues arise when partial coverage is treated as a complete picture of access.

You ask what someone is working on. They tell you mostly things you already knew. You then ask if there are blockers. They say no, or mention one, and it gets noted somewhere and the meeting moves on. This happens every morning, or three times a week, or whatever cadence the team has settled on. Everyone is present, but almost no one is really listening.

The problem isn’t the frequency or the length. It’s the structure. It puts the team on the hook for producing information that, in many cases, everyone in the room already has, or that no one in the room actually needs at that moment.

The worst version of this is when someone has to repeatedly announce that nothing has happened on a six-month project that was never going to move this week. That’s not information. That’s management theater at best and a slow tax on morale at worst. But the ritual demands it, so someone performs it.

The setup

I’ve been running my security team’s check-ins differently for the past year or so, and I want to describe the part that I think matters most.

We meet on Mondays, Wednesdays, and Fridays. Wednesdays and Fridays are short syncs, usually under fifteen minutes. Monday is the main meeting and runs for about an hour.

The gap between meetings is intentional: enough time for things to actually move, not so long that anything slips through.

The Monday structure is straightforward: I open with announcements, urgent or unplanned work, kudos where they’re due, and what’s top of mind for me on both the security and business side. Then each person goes through what they’re working on, what they need help with, what they’re stuck on.

None of that is unusual. The part that’s different happens roughly every two weeks, at the end of one of those Monday meetings, after everyone has had their turn.

I go through every project on our pipeline and I state my understanding of its current status. Not as a question. As a statement. I say what I think is happening, what I think the blockers are, what I think the next steps are. The team corrects me where I’m wrong. Mostly, I’m right.

We also run a monthly retrospective focused on team health and process improvements, but it’s separate from this mechanism.

Shifting the burden

The reason it works, I think, comes down to who carries the tracking burden.

In a traditional standup, that burden sits with the team. They’re responsible for surfacing progress, flagging issues, and producing updates on demand. The manager is the receiver. The implicit contract is: I ask, you report, and I follow up if something seems off.

This model inverts the contract. I absorb whatever surfaces naturally in normal conversation or check-ins over the course of two weeks. I don’t prompt for project-level status. I don’t ask “where are we on X?” in sync meetings, ever. Long-running work that hasn’t moved doesn’t need to be announced as unmoved. It surfaces when there’s something worth saying about it.

Then, at the biweekly recap, I carry the synthesis myself. I’m the one who has to demonstrate that I’ve been paying attention. If my understanding is wrong or outdated, that’s on me to correct, not on someone else to have proactively flagged.

The effect on the team is real, even if it’s subtle. Nobody has to say “no progress this week” on a project they haven’t touched, because I’m the one stating the status. The pressure to produce the update disappears. What remains is just the conversation. The team can instead focus exclusively on producing high-value signals.

There’s a flattening effect too. When the manager is the one producing the update rather than extracting it, the dynamic stops feeling like a reporting line and starts feeling more like a team that shares context.

The catch

There’s a prerequisite worth being honest about: this only works if the manager is actually engaged. The biweekly recap isn’t a technique for reducing your own involvement. It’s a forcing function for maintaining it. You have to be absorbing what people say in normal conversation accurately enough to reconstruct the state of the entire project pipeline every two weeks. If you’re not doing that, the recap falls apart immediately and you’ve just created a new awkward meeting format.

I would argue that engagement is the job anyway. Knowing the current state of your team’s work, understanding why things are moving or not, and being able to communicate that clearly to stakeholders is not a bonus feature of good management. It’s the baseline. This mechanic just makes it visible and creates a regular moment where you have to prove it to yourself and your team.

The upstream benefit

One more thing worth naming: it helps me upstream as much as it helps the team. I’m regularly synthesizing project status in a form that’s ready to communicate to stakeholders. The biweekly recap isn’t just a check-in tool. It’s also how I keep my own model current and accurate enough to answer questions quickly when someone above me asks.

I’m not claiming this is novel or scientifically validated. My sample size is one and every team is different. Other people have almost certainly arrived at versions of this and built better systems around it. But it has worked well enough that the mechanism is worth describing: Don’t ask. Absorb. Carry. Read it back. Let your team correct you.

The correction is the update. The absence of interrogation is the point.