Why it exists
Once access is composed from roles, policies, grants, glob patterns, and label selectors, “what can this identity do?” stops being answerable by reading the configuration. A member might reach a resource through a role, through a direct grant, or through a selector that matches their own team attribute — and the union of those is the only answer that matters. That gets harder in the direction that counts most: before a change. Adding a policy to a role affects everyone holding it, and removing a grant may quietly break an agent that depended on it. Access explorer lets you look before you move.Effective access
Pick a principal and you get everything it can currently do, the scope each capability applies at, and where each one came from — which role, policy, or direct grant produced it. Use it to:- Confirm a new member holds what you intended and nothing more.
- Understand why a principal can reach a resource — the provenance tells you which grant is doing it, so you know what to change.
- Check what an agent is able to do before you point it at production.
Access check
The other tab is a dry run of one decision: can this principal perform this capability on this specific resource, right now? It is the same check the engine runs — the same glob patterns, the same label selectors — so the answer is the answer rather than an approximation of it.Who can use it
Access explorer has its own permission. An administrator can grant access to the people who need to review authorization without granting permission to change roles, policies, or grants. Running an effective-access query or access check does not change the authorization configuration.Next steps
Roles & permissions
The model this screen evaluates.
Service accounts
Manage the non-human identities whose access you inspect.
Agent identity
Checking an agent rather than a person.
Audit log
Review changes to roles, policies, and grants.