How Do Security Teams Audit Non-Human Identity Access?

Your SOX auditor's request list arrives with a line that used to be a footnote: every non-human account that can reach the general ledger, who owns it, and when someone last confirmed it still needs that access. Your identity provider lists a few dozen service principals. The ERP's admin console lists integration users nobody in IT remembers creating, and the cloud account behind the nightly close job holds roles older than anyone on your team.

Each of those lists shows only what one console issued, and none of them says who owns an account or whether it still needs its access. Teams audit non-human identity access by turning scattered lists like these into one record the auditor can test, in five steps that build on each other. The teams that answer requests like this one without a scramble hand the continuous watching to identity agents and save people for the decisions only people can make. Here's how each step works, in the order you'd run it.

1. Scope the NHI audit with non-human identity discovery across every issuer

An NHI audit is only as complete as its list of issuers, the places where a person, a pipeline, or an agent can create machine access. It’s tempting to start from the identity provider, the home of workforce identity and access management, and that’s exactly why the population comes up short.

The NIST Cybersecurity Framework 2.0, published in February 2024, puts machines in the same outcome as people. Its PR.AA-01 subcategory reads "Identities and credentials for authorized users, services, and hardware are managed by the organization." Every service, integration, and agent that can reach an in-scope app belongs in your population, so non-human identity discovery starts from the issuers, including the directory, cloud, and SaaS homes that service account governance already has to cover.

Some of your machine credentials don't live in your environment at all. In April 2024, CISA urged customers of the data analytics company Sisense to "reset credentials and secrets potentially exposed to, or used to access, Sisense services," and to investigate and report any suspicious activity involving them. Rotating fast that week depended on already knowing which database credentials and API keys you'd configured inside the product. Each issuer below creates a different kind of access and raises a different audit question.

‍

The population is complete when every issuer is either connected or written down as out of scope with a reason. The two agent rows need extra work of their own, since every step in how to audit and certify AI agent access rights assumes you’ve already found the agents.

Once your issuers are connected, the audit reads from one list. Lumos's Non-Human Identity Inventory, in beta, lists service accounts, service principals, and workload roles from AWS, Entra ID, OpenAI, and Anthropic with their last activity and status. It also flags Anthropic keys that never expire or belong to a person. More than 300 app integrations add the local accounts that skip your identity provider.

Coding agents need a source of their own, since they act on a person's access and pick up new tools between reviews, the two problems at the center of AI agent access management. MCP Governance, in design partner beta, records each MCP server and tool call in supported coding agents with the person behind it, including servers added on a laptop that no vendor API can list.

Code42 has said its FedRAMP, SOC 2, and ISO 27001 certifications made access reviews especially important. After it moved them into Lumos, its IAM team stopped working in spreadsheets, chasing reviewers, fighting data integrity issues, and building auditor reports by hand. Machine populations add one more requirement. A sync that returns half the accounts looks exactly like a cleanup, so keep each integration's sync history with the population your auditor samples.

For one in-scope app, list every issuer in the table this week. Mark each one connected, manual, or out of scope with a reason.

2. Give every non-human identity an owner and a reason before anyone reviews it

Before anyone certifies a machine's access, someone has to answer for the machine, so the ownership pass comes first and an unowned identity is a finding on its own. A review routes each item to a person. An identity with no owner either lands in a generalist's queue, where it gets approved by default, or never gets routed at all.

In the customer environments we've analyzed, 95% or more of non-human identities have no assigned human owner. Without an owner, reviews can't run and lifecycle policies don't apply, which is why the ownership pass has to finish before the access review opens.

Every identity in scope gets two records before the review opens. The first is an owner, a named person with a backup, never a team alias. The second is a business justification that says what breaks if the access goes away. The owner attests to that reason now, and the app owner certifies the scope in step four, so the two questions stay separate.

Propose owners from creation records, repository and deployment ownership, the app each identity connects to, and recent activity, since each of the common non-human identity examples leaves a different trail. Then have a person confirm each proposal, because any single signal goes stale the day someone changes teams.

Set ownership once and every later step can read it. Each identity in Lumos's NHI inventory carries Owner and Business Justification fields, and Lumos's security agents, remediation, and access reviews all reuse that ownership, so a finding arrives with its owner attached. The Agent Ownership Finder in the Identity Agent Force catalogs every agent and NHI running in your business and assigns each a human owner, so new agents get an owner before they get to work.

An identity nobody claims by the deadline gets disabled reversibly and logged as a finding, and whoever reports the breakage becomes its owner. Before the deadline arrives, your non-human identity security strategy should name who has the authority to revoke identities nobody claims, so the deadline means something. 

Export every NHI with privileged or production access this week. Give each one a two-week deadline for an owner and a reason, and report the unowned count every Monday until it reaches zero.

3. Find unused and overprivileged non-human identities with usage and reach data

Unused and overprivileged NHIs show up only when you query usage and reach data across identities, credentials, and time. A review campaign shows a reviewer one identity and one entitlement at a time, so it can't answer the six questions below. Non-human identity access monitoring runs them as queries and keeps running them between reviews.

‍

The third question deserves its own warning. Compromise a build role that can pass an admin role to a function it deploys, and you hold admin, yet a row-by-row review approves both rows because each looks reasonable alone. Reach has to be computed across the graph of identities, roles, and trust relationships, since no single entitlement shows it.

When the auditor asks, the answer should take minutes. With Lumos agentic AI security, Albus answers questions in plain language, such as “Who has dormant admin access? For reach, Lumos's NHI Threat Hunter, in beta, scans the AWS IAM authorization graph, flags over-broad role-passing and role-assumption chains, and traces each privileged identity to the app or team that owns it. GitHub coverage is also in beta.

Answering audit questions from data already works for people's access. Roku connected Lumos to its log analytics tool for auditability, and its IT and security teams can now audit app usage, access roles, and entitlement anomalies across the company. Pointing the same approach at machine identities is how you answer the six questions above.

Write your six questions down and run them against one cloud account and one SaaS app this month. File every answer you can't produce as a finding.

4. Run non-human identity access reviews continuously, on change, and quarterly

Machine access changes every time someone deploys, so a quarterly campaign on its own audits a population that has already moved. A key minted on Tuesday and leaked on Thursday doesn't wait for the quarter to end.

The fix is to split the audit into clocks that match how fast each kind of change needs an answer. Treat the table below as a starting model to tune for your environment.

‍

Every NHI sits on all three clocks, and risk sets the thresholds within them, such as how old a key may get or how long an owner has to answer. Once a year, security and GRC leads re-sign the issuer list, the audit scope, and the rules that let access be certified without a person. AI agents add machine triggers to the on-change clock, such as a new MCP server or a new tool, and AI agent lifecycle management covers how to handle each one.

Splitting the work this way is how teams audit non-human identity access without drowning in reviews, because most of the watching never reaches a reviewer. A quarterly review that surfaces something the continuous clock should have caught is a finding in its own right.

The quarterly clock is where you audit and certify non-human identity access, and it's where people's time is scarcest. In Lumos, the Access Review Agent runs reviews end to end, certifies safe access on its own, and brings people only the items that need a human call. App owners review human and machine access side by side in one campaign and can revoke access or rotate credentials straight from the review, and Albus captures the evidence behind each recommendation.

When Sun Country Airlines went public, SOX made access reviews a required control for every in-scope app, including on-premises apps no cloud identity provider syncs. Lumos compiles those reviews through integrations with Okta, Active Directory, Azure, and the target apps. "Managed service accounts and privileged access are now fully certified," the case study reports, and the airline completed its next required SOX review without delays.

Machine access belongs in the same attestation as people's, and the attestation moves faster when the continuous clock has already done the sorting. Track one number alongside the rest of your NHI governance metrics: the share of findings closed before the quarterly review opened.

Name an owner and a calendar for each clock this quarter. Turn on the continuous checks for privileged NHIs first, because that's where a missed week costs the most.

5. Confirm every revocation and credential rotation landed at the source

A finding is closed when the app or cloud that issued the access confirms the change took effect, and every step between the decision and that confirmation needs a record. A ticket marked done only records what someone meant to do.

The Cyber Safety Review Board's review of the summer 2023 intrusion into Microsoft Exchange Online shows how long that gap can last. The board found that the consumer signing key the attackers used had been issued in 2016 and was meant to be retired in March 2021, but its removal was delayed. Microsoft had been rotating those keys by hand, stopped in 2021 after the manual process was linked to a major cloud outage, and had no automated alerts to flag aging keys before the breach. A retirement decision isn't evidence until the live credential confirms it, and that confirmation is where an audit becomes non-human identity breach prevention.

NHI fixes fail quietly in predictable ways. A rotation breaks a nightly job and gets rolled back, a removal fails because the integration can't write to the app, a manual step sits in someone's queue, or a revoked credential leaves a live token or refresh token behind.

Two checks catch all four. Re-pull the entitlement or the credential's status from the issuer after the change, then look for any activity after the change time.

Every fix should arrive with its own record, and a failure should show up as work. Lumos's Remediation Workflows, turned on through your CSM, attach an agent-built fix to each finding for a person to review and launch, with manual steps for apps Lumos can't write to. Removals from Lumos access reviews run through the same deprovisioning workflows used everywhere else, so a failed removal becomes an error task. With the ITSM integration on, auditors get a ticket and a workflow record for each removal.

Access built to expire is the easiest finding to close, because it closes itself. Netskope cut standing access by 80% with usage-driven least privilege and just-in-time grants that expire on their own and log full evidence. That program covered standing access broadly, and short-lived machine credentials follow the same pattern, with the expiry log as the evidence that non-human identity management audit readiness depends on for each machine identity in scope.

Pull ten NHI findings your team closed last quarter and check each one at its issuer. Count how many held.

Make non-human identity access governance a continuous audit

Your auditor's request list will keep asking which machine accounts can reach the general ledger, who owns them, and when someone last confirmed they need that access. Those answers hold up only when the watching runs continuously and your people spend their time on decisions. AI agents are joining that request list, and AI agent identity governance has to produce the same evidence for them.

This month, list your issuers, show the population was complete, and put an owner and a reason on every privileged NHI. This quarter, run the six questions, staff the three clocks, and check last quarter's fixes at the source. Run this way, audit season becomes a readout. A quarterly audit gives you a snapshot, and a continuous one gives you a record.

Lumos puts non-human identities from your cloud, identity provider, and AI platforms in one inventory with owners and reasons. Albus and the Identity Agent Force answer audit questions, hunt risky access paths, and run reviews that put human and machine access side by side. Workflows record every removal, and MCP Governance enforces your AI agent access policies for the agents acting on your people's access. Book a demo to see what an audit of your own machine access turns up.

‍