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.Using it is a governed read
Examining another identity’s effective access is a sensitive read, so it requires its own capability and is recorded in the audit log like any other governed action. Knowing exactly what a privileged identity can reach is useful to an administrator and useful to an attacker, which is why the platform treats the two the same way and writes it down.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
Where an access check is recorded.