Identity & Access

Datastores tell you what sensitive data you hold. Identity & Access tells you who can reach it, and that is usually where an incident actually starts. The page answers three questions in descending order of urgency: which identities are dangerous, which specific grants need a human review, and what exactly would an attacker reach if they took over this one principal.

The scoring behind it is explained in Identity & access risk. This page is about the screen.

Everything here comes from IAM discovery, which is a separate sweep from datastore discovery. If the page is empty, discovery has not run yet.

Getting identities into the page

Run IAM Discovery in the page header picks a cloud account and dispatches the sweep. It runs once per account and takes a couple of minutes. You can also get IAM discovery from Run discovery now on Cloud Accounts, from the account’s discovery schedule, or by ticking Include identity analysis on a full assessment.

While it runs, a tracker banner sits above the content and polls every few seconds. It reports one of four outcomes: still running, complete, completed with errors, or failed. A clean success auto-dismisses after a few seconds; anything with errors stays up until you close it, because a partial sweep means the page below is incomplete. The banner survives a page reload, so you can navigate away and come back.

The whole page depends on one IAM policy statement

Identity discovery needs the ArgusIdentityRead statement on the agent’s role. Without it, this page, the access graph, blast radius, credential hygiene, and every IAM recommendation are all empty, and nothing surfaces to tell you why. See IAM permissions.

The KPI strip

Six counters across the top. Every one is a filter: click it and the table below narrows to exactly that population, so the strip doubles as your worklist entry point.

Counter	What it selects	Why it matters
Total Identities	Everything (clears filters)	Your baseline
Over-Provisioned	Granted far more than they use	The single most useful cleanup queue
Stale Access	No recent activity	Dormant credentials that still work
Sensitive Data Access	Can reach datastores holding sensitive findings	Where a compromise actually hurts
High-Risk Services	Service identities at critical or high risk	Non-human principals nobody owns or rotates
Cross-Account	External principals	Access from outside the account boundary

High-Risk Services is worth a standing look. Service accounts have no MFA to add and no person to ask, so they accumulate permissions and outlive their purpose more quietly than user accounts do.

Access Risk Heat Map

A grid of identity type (Users, Services, Roles, Groups) against resource type (S3, RDS, DynamoDB, Redshift, Other). Each cell shows the number of access grants and is coloured by the worst risk level in it, not the average, so a single critical grant cannot hide inside a large green cell. Hovering gives the grant count and the average risk for that intersection.

Clicking a cell filters the table to that exact combination. The intended read is: scan for the darkest cell, click it, work the list.

Cross-account access has no row of its own here. External is an attribute an identity carries, not a type it is, so you reach it through the Cross-Account KPI or the Flags filter instead.

Access Governance

A panel beside the heat map that counts grants needing review, for example “18 of 240 grants need review”. Below it, one card per concern, ordered by review priority:

Concern	What it means
Dormant privileged	High-power access that nobody is using. The sharpest concern on the list, and the only one highlighted in red
Wildcard actions	Policies granting *-style action sets rather than named actions
Admin access	Effectively administrative reach
Cross-account	Reachable from outside this account
Write access	Mutating rather than read-only
Dormant	Unused, without the privileged qualifier

Each card previews the affected identities and opens a drill-down listing the individual grants: the resource, the policy that granted it, the actions, and the access level. Clicking a grant hands you to that identity’s detail drawer without leaving the page.

Dormant privileged is where to start. Unused admin access is the cheapest thing in security to remove, because by definition nothing depends on it.

The identity table

Sorted by risk score, worst first, and paginated on the server, so filters and sorting apply to your whole estate rather than to one loaded page.

Column	Notes
Name
Type	User, Service, Group, or Role
Risk Level	Band badge, with the score and a direction marker when it has moved since the last sync
Flags	Scan-derived attributes (below), plus a count of changes since the last sync
Status	Lifecycle state: Active, Hidden, or Not Found
Account
Principal ARN	With a copy button, for pasting into a ticket or the CLI
Last Activity	Relative time, or Never

Flags are not Status

Two separate axes, and mixing them up leads to the wrong action:

• Flags describe what the scan found about the identity: Admin Access, Over-Provisioned, Stale, No MFA, External, Sensitive Data. These are findings you act on.
• Status is a platform lifecycle state: Active, Hidden, or Not Found. Not Found dominates Hidden, so an identity deleted in AWS reads Not Found even if you had also hidden it.

Both hidden and not-found rows render dimmed, and not-found rows cannot be selected, because every bulk action against a deleted principal would be a no-op.

Filters cover Type, Risk Level, Flags, and Status, plus Cloud Account when you have more than one connected.

Row and bulk actions

Open in AWS Console jumps to that exact principal. Hide identity and Unhide identity are the only state-changing actions, available on rows and in bulk over a selection.

What hiding an identity does

The same posture decision as hiding a datastore, applied to a principal. A hidden identity is:

• excluded from the KPI counters, the heat map, and the default list,
• has its active alerts suppressed,
• and stops being re-scored until you unhide it.

A reason is required. Use it for a known-good service role or infrastructure identity, or for an accepted risk. Unhiding reverses all three: it returns to the list and KPIs, resumes scoring, and its suppressed alerts reactivate.

Hidden identities stop being scored

This is stronger than hiding a datastore, which still gets scanned. A hidden identity is frozen at its last score, so if its permissions get worse while hidden, nothing tells you. Hide deliberately, and revisit what you have hidden.

The identity detail drawer

Clicking a row opens the drawer. The header carries the risk badge and a link out to the AWS Console; the footer holds Hide or Unhide. Peripheral actions live in the header, consequential ones in the footer, matching the datastore drawer.

Overview - type, risk score and band with its movement since last sync, account, lifecycle status, owner, last activity, last synced, the full ARN with a copy button, and the flag set.

Risk Factors - the specific reasons this identity scores what it does, in plain language. Where Argus has a fix for a factor, the row becomes a link badged Fix available that takes you to the matching recommendation. That one-to-one mapping between a risk factor and its fix is the fastest path from “this is bad” to “this is done”. Credential-hygiene signals (multiple active keys, an unused active key, a stale password, no MFA) are folded in here rather than listed separately.

Blast Radius - what this identity reaches if it is compromised, which is the section to read before deciding how urgent it is. Three counts: Reachable datastores, how many are Sensitive, and the total sensitive Findings behind them. Then the maximum access level it holds against sensitive data (admin, write, read), the exposed data categories, and the itemised list of reachable datastores with sensitive ones first, each linking to its own drawer.

An over-privileged identity that reaches nothing sensitive is housekeeping. An identity with write access to three sensitive stores is an incident waiting to happen. The counts here are what separate the two.

Permission Utilization (what’s used) - granted versus actually used, as a percentage with a bar, plus the used and unused service lists. This is the evidence behind the over-provisioned flag: it is what makes “you could remove these” a defensible statement rather than an opinion. It needs AWS Access Advisor data, so it is empty until IAM discovery has populated usage.

Access Grants - what’s permitted - the parsed grants: resource type, the policy that granted it, allow or deny, the resource, and the actions. Long lists are capped in the display and tell you the true total. Read this next to Permission Utilization: one is what the identity may do, the other is what it has done.

Recent Activity - last-used snapshots from the IAM credential report and Access Advisor. Read the label carefully: this is the most recent timestamp per signal, not a full event history. For real event forensics you still want CloudTrail.

Changes Since Last Sync - what moved since the previous discovery. Opens by default when there is anything in it, because a permission change you did not expect is worth seeing immediately.

Related Alerts, Memberships, Recommendations, and Provider Metadata round it out, each linking through to the fuller view.

Coming from somewhere else

The page accepts two deep links. ?selected=<id> opens an identity’s drawer directly, which is what global search and the recommendation drawers use. ?datastore_id=<id> filters the list to the identities that can reach one datastore, which is the “who can get to this bucket” question asked from the other direction. See Datastores.