Access report
Review who in your organization can reach what — by member or by resource — read-only, with the route each grant takes.
The Access report answers the question an access review starts with: who can reach what? It asks it in both directions — pick a person and see everything they can reach, or pick a vault, project or secret namespace and see everyone, and every machine identity, that can reach it.
It changes nothing. Everything you open on it is recorded in your audit log, because looking up what a person can reach is itself a security-relevant act.
Find it under Security & compliance → Access report.
Who can open it#
Anyone whose role includes report-read access (business:report:read): Organization Administrator and
Auditor by default, and any custom role your organization grants it to.
It deliberately does not need the power to manage members. An auditor can review everything here without being able to change a single person, which is why it is separate from the member directory. See Roles & permissions.
If you can also read the audit trail, the page header links to Security posture — the sibling question of how healthy those people are, rather than what they can open. Without audit-read access the link is not shown.
By member#
The By member tab lists everyone in the organization.
Search members looks up a name or email across the whole organization, not just the page on screen. Results are paged.
| Column | Shows |
|---|---|
| Member | Name and email. Select it, or View access, to open the drawer |
| Role | The member's organization role |
| Status | Active, Suspended or Removed |
A Suspended member still holds every grant they had. That is exactly the kind of thing a review is looking for, so the status is stated beside the grants and not only by colour.
One member's access#
The drawer opens with the member's status and role, then Everything this member can reach through the organization, as of now.
- Teams and Projects — how many they belong to, and how many projects they can reach.
- Secret namespaces — how many DevOps namespaces they can reach.
- Signed-in sessions — how many sessions they have open right now.
- vault(s) they can open — each vault by name with the access level it grants, and an Owner badge where they own it. Vault access is granted per vault, not by a role, and neither permissions nor vault access implies the other. Permissions decide what someone may administer; they are on the member's Roles & permissions tab in the directory.
- service account(s) holding N live key(s) created by this member — machine identities this person made. A machine's credential is not deleted because its creator left, so review them separately.
- vault(s) whose keys they have seen — vaults where removing this member would leave the owner to rotate the key, which the server cannot do.
- What this organization does not reach — what the list leaves out on purpose. A list of grants that omitted this would read as though the organization owns everything the person can open.
When the drawer shows this warning, it lists why — for example the member is the only custodian of a company vault. Removing them would be refused until someone else takes that over. During a review, this is a finding in itself.
By resource#
The By resource tab turns the question round. Choose Vaults, Projects or Secret namespaces. Each row shows the resource's name (a namespace also shows its prefix, a project its slug, because a namespace called db means nothing without its project), and Reachable by — the number of principals, people and machines together.
It shows a count, not the list, on purpose. Assembling every route for every resource in one response would be a full reachability matrix; the count is the figure you scan for the one that looks wrong. Select the name or Who can reach it to see the rest.
Who can reach one resource#
The drawer has two lists, because they are read for different reasons: the first is an offboarding question, the second a credential-rotation question.
People — each person, with the route their access takes and a badge for the level:
| Route shown | Meaning |
|---|---|
| Owner | They own it |
| Direct grant | It was given to them personally |
| via team “name” | They reach it through that team |
| via project “name” | They reach it through that project |
| Custodian | They hold a key to an organization vault as a custodian |
| policy “name” | A secrets policy gives them access |
The route is the column the report exists for: reach through a team is invisible on the resource's own screen. Where your organization lets project roles manage machines, a row can also read Also manages machines: followed by what that role can do. That person can create credentials here, and the report says so rather than under-stating it.
Machine identities — service accounts and their keys that can reach the resource, each with the policy that lets it. A machine reaches a namespace through a policy path pattern, not a grant on the namespace, which is why machine identities appear here and nowhere else — not on the namespace's own screen.
Running an access review#
- Open Security & compliance → Access report. Start on By member when the trigger is a person (a leaver, a role change) and on By resource when it is a resource (a sensitive vault or a production namespace).
- For a person, find them with Search members and open View access. Read the teams, projects, namespaces and vaults against what their job needs.
- Look first at anyone Suspended who still holds grants, and at any This member holds access nobody else can take over warning.
- For a resource, open Who can reach it. Check the Reachable by count is what you expect, then read each route: a Direct grant to someone who should be on a team is usually the one to fix.
- Review Machine identities separately. A service account that outlives the person who made it keeps authenticating.
- Make changes where the access is managed — the member directory, the team, the project or the vault — then reopen the drawer. It always shows the state as of now.
Related#
- Security posture — credential health and policy compliance for the same people
- Audit logs — every open on this page is recorded
- Roles & permissions — who may read this report, and why that is separate from managing members
- Trace explorer — what a person actually did, rather than what they could do