How to Inventory Non-Human Identities

Quick answer
An inventory needs four fields per identity: what it is, who owns it, what it can reach, and when it was last used.
Start with authoritative sources — cloud IAM, identity providers, databases, CI secret stores, and SaaS admin consoles — because they already hold the data.
Then cover what the systems do not know: credentials in code, in .env files, in repository history, and in deployment manifests.
Do not aim for a perfect list before acting; a first pass that finds the unused admin credentials is more valuable than a complete catalogue with no decisions.
Keep the inventory generated, not typed. A spreadsheet of credentials is stale the day it is finished.

What should an NHI inventory contain?

At minimum: an identifier, the type of credential, the owner, the scope, where it is stored, when it was issued, when it expires, and when it was last used. Add the consumer — the repository, workload, or deployment — because that is what makes revocation safe.

The fields serve specific actions. Owner enables review, last use enables staleness detection, scope enables privilege reduction, and consumer enables revocation without an outage. A list of key names without those fields is an index, not an inventory.

Which sources should you pull from first?

Cloud IAM is usually the largest: users, roles, service accounts, access keys, and their last-used data. Then the identity provider for OAuth clients and app registrations, the database for login roles, the CI platform for repository and environment secrets, and the SaaS admin consoles for API tokens and integrations.

Most of these expose an API. A short script that lists identities with last-used timestamps is more reliable than asking teams to report them. Where an API is unavailable, export the admin console’s CSV and note the export date so the gap is visible.

# AWS: find IAM users with keys and their last use.
aws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | while read -r u; do
  aws iam list-access-keys --user-name "$u" \n    --query 'AccessKeyMetadata[].{Key:AccessKeyId,Status:Status}' --output json
done

# Then check each key's last-used date and service.
aws iam get-access-key-last-used --access-key-id AKIA...

How do you find credentials the platforms do not know about?

Scan repositories for provider token patterns and high-entropy strings, including history and CI configuration. Scan deployment manifests for env blocks and secret references, and container images for files that look like .env or credential JSON. The goal is not to eliminate findings but to map them to an owner.

Then reconcile. A credential found in code that does not appear in any provider list is either already revoked or belongs to an account outside your scope; both are worth knowing. A provider credential that no code references is a candidate for the stale list.

How do you keep it current?

Generate it on a schedule from the same APIs, and diff against the last run. New identities without owners and credentials unused for ninety days are the two queries that produce most of the value. Publish the diff to the owning team rather than to a central dashboard nobody reads.

The inventory is also a design tool: if a team cannot explain why an identity exists, that is the finding. Removing identities is the point, so track removals as a metric alongside discoveries, or the list only grows.

Where this bites vibecoders
AI-assisted projects accumulate credentials from every integration attempt, and nobody records them because the integration is the task. Exporting the provider’s credential list once, joining it to repositories by name, and marking the unmatched ones for review takes an afternoon and usually finds more risk than a week of code review.

Where AI coding assistants get this wrong

Building the inventory by asking teams to fill in a spreadsheet.
Listing credential names without owner, scope, or last use.
Ignoring credentials created by integrations that were later removed.
Scanning only the working tree and missing credentials in history.
Treating discovery as the outcome instead of revocation.
Assuming the cloud list covers SaaS tokens and database users.

Checklist

Export cloud IAM identities with last-used data.
Add identity-provider clients, database roles, and CI secrets.
Scan repositories and manifests for credentials outside those systems.
Assign an owner and consumer to every identity.
Query for unused credentials and missing owners weekly.
Track removals, not just discoveries.

FAQ

How long does a first inventory take?

Days, not months, if you start from APIs and accept an incomplete first pass. The first list is usually dominated by one or two systems, and the gaps are in SaaS and code. A useful inventory exists after the first export; a complete one never does, because systems change.

Should the inventory include human accounts?

It can, and many teams use one identity inventory for both, but the questions differ. Human accounts need joiners, movers, leavers, and MFA; non-human identities need owners, scope, rotation, and expiry. Keeping the NHI view separate makes the review questions clearer.

What is the most useful field?

Last used. It converts an abstract list into an actionable one, because an identity with no recent use and write access is a candidate for immediate disablement. Owner is the second, because without it there is nobody to ask and nothing gets decided.

How do I handle identities in third-party systems?

Use the vendor’s admin API or audit log where it exists, and record the export date where it does not. Many SaaS platforms show token last-used and creator, which is enough for a review. The gap is usually visibility, not data — someone has to be assigned to look.