> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access explorer

> Ask what an identity can actually do, and test one action against one resource, before you grant or revoke anything.

Access explorer lets you reason about access without trial and error. Its two tabs answer two
different questions: **Effective access** reports everything a principal can do, with the
provenance of each capability, and **Access check** dry-runs a single "can this principal do this
on that?" decision using the same check the engine runs. This page covers both, and why using it is
itself a governed action. Find it under **Settings → Access explorer**.

## 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.

<Tip>
  This is the fastest way to debug a label selector. A grant scoped to `team = $principal.team` fails
  closed when the identity has no `team` attribute, and a check on one concrete resource shows you
  that immediately.
</Tip>

## 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](/security-and-governance/controls/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

<CardGroup cols={2}>
  <Card title="Roles & permissions" href="/security-and-governance/identity-and-access/roles-permissions">
    The model this screen evaluates.
  </Card>

  <Card title="Service accounts" href="/security-and-governance/identity-and-access/service-accounts">
    Manage the non-human identities whose access you inspect.
  </Card>

  <Card title="Agent identity" href="/security-and-governance/identity-and-access/agent-identity">
    Checking an agent rather than a person.
  </Card>

  <Card title="Audit log" href="/security-and-governance/controls/audit-log">
    Where an access check is recorded.
  </Card>
</CardGroup>


## Related topics

- [Accounts & members](/security-and-governance/identity-and-access/accounts-members.md)
- [Agent identity](/security-and-governance/identity-and-access/agent-identity.md)
- [Roles & permissions](/security-and-governance/identity-and-access/roles-permissions.md)
- [How it works](/security-and-governance/how-it-works.md)
- [AWS Cost Analyzer](/manage-your-agents/build/catalog/aws-cost-analyzer.md)