Non-human identities and ownership
Service accounts, API tokens, applications, agents and devices usually outnumber the people in an estate, and tend to belong to nobody in particular. That is a governance problem rather than a lament, so this page is how it is modelled: what counts as a non-human identity, where an owner comes from when nobody set one, and what the platform refuses to conclude when it cannot observe enough to be right.
What counts as a non-human identity
Five identity types are non-human: service account, system account, application, AI agent and IoT device. The set is defined once and shared by every consumer, because a signal about "machines" and a signal about "people" cannot be allowed to disagree on which is which.
The distinction earns its keep by changing behaviour, not by tidying a taxonomy:
- Dormancy thresholds differ. A grant held by a person is a dormancy candidate after 90 days by default; a non-human identity gets 180. A service account that runs quarterly is doing its job, not rotting.
- Non-humans are excluded from human peer-group baselines, in both directions — a batch account with two hundred grants would otherwise inflate the median its colleagues are measured against.
- The ownership cascade is shorter than a person's. A machine has no line manager, so the manager step that rescues a human identity does not exist for it.
- Attestation cadence follows the type. A yearly ownership attestation ships seeded and enabled for every non-human identity; AI agents sit above it on a tighter ladder driven by their declared autonomy.
Where they come from, honestly. There is no scanner that finds every class of
machine identity. An NHI exists here because a connected source said so: a
directory or HR record carrying the type, a connector object declaring the subtype
it produces, agent discovery on Microsoft Entra, AWS, Google Cloud or GitHub (Governing AI agents), or a deliberate creation through the
UI or the identity-push API. An account that merely looks like a service account
is classified as an account — purpose_class = service — a statement about the
account, not the minting of a governed machine identity. Anything in a system
nobody has connected is, correctly, invisible.
Lifecycle driver: why the identity exists
The lifecycle driver is an asserted reason for existence, not a tier inferred from the identity type. It resolves in this order:
- an explicit assertion on the NHI;
- an inherited account-type default;
- a visible conflict between applicable defaults;
- a non-binding suggestion;
- unknown.
Only an asserted or inherited driver may suppress a driver-specific finding. Suggestions are useful for review but are not evidence, and the migration did not backfill guesses into stored facts. A runtime-driven NHI can therefore avoid a human-style dormancy conclusion only when that driver is actually asserted or inherited.
For an AI agent, lifecycle driver and autonomy tier coexist: the first says why the identity persists; the second records declared human oversight over the agent's acts.
A retired (terminated) non-human identity is history, not estate: the NHI list and dashboard leave it out unless you ask for it, and it is not an orphan, so it gets no owner suggestion or claim and does not lower the coverage percentage. A kill-switched agent is suspended rather than terminated and stays visible.
Rotation and last use
Rotation and last use on the NHI list, tiles and risk score come from one
derivation. Rotation is the newest observed of the account's recorded password
rotation and the creation date at the source of each credential that has not been
revoked, and an identity also reads stale when a credential that still works is
older than the rotation SLA. Last use is the source-reported date. An empty last use
reads "never used" only for credentials RapidValue issued itself or where the source
answers the usage question (AWS access keys do); otherwise it reads "not reported".
For Active Directory service accounts, pwdLastSet is the rotation and
lastLogonTimestamp the last use. AD replicates that value coarsely, so the date is
shown with a lag of about 14 days: it means "used on or after", not "last sign-in".
A credential that still works and was created at the source more than 90 days ago also raises an Advisor finding, rotation overdue, using the same age test as the list. There is no finding without a creation date reported by the source, and none for an identity whose asserted or inherited lifecycle driver is runtime-driven.
The chain view
Each non-human identity has a Chain tab on its detail page (an AI agent's page also shows it as a strip of six chips under the header). It reads, in order, who owns the identity, the person it is declared to act for, the credentials it can authenticate with, the tools it reaches through RapidValue, what RapidValue recorded it doing, and the applications where it holds access. Every link says where it came from (an assigned owner, the ownership rules, an Entra sponsor, a declaration) and whether it is verified, declared or unknown, with the reason when it is unknown (no owner, a source that was not read, a feature not built). A link also says how fresh it is and what that is judged on, such as the last credential inventory read or the last account sync.
The tab is read-only and leaves no audit trace. It is shown to anyone who may read NHIs, and to an owner for the identities they own, even without that permission; someone else gets nothing. The same chain, as of the end of the window, is a section of the AI-agent governance evidence pack, which can be produced for the whole tenant or for one agent. A per-agent pack narrows the agent sections and says so in its signed manifest; the audit trail, attestation history and runtime decisions in it stay tenant-wide.
One store, one writer
Ownership of a non-human identity is recorded in exactly one place: the canonical
ownership table, as an nhi entity with a business owner and, optionally, a
technical one. Every surface that answers "who owns this?" — the resolution
cascade, certification's owner routing, the coverage rollup, the ownership
workbench, the NHI estate page and its coverage figure, the identity risk score,
evidence, the compliance control — reads that one table.
That sounds obvious. It was not always true, and the failure mode is why the design is now this rigid. The NHI workbench once kept its own membership records — a machine belonged to a management group, and that membership was the ownership, invisible to the canonical table. So an owner assigned from the orphan inbox was invisible to every resolver-backed consumer, and an owner imported from an agent's sponsor was invisible to the NHI page's own coverage figure. Two stores do not produce two opinions occasionally; they produce two opinions permanently, and each is convincing on the surface that owns it.
The management-group layer still exists, because it does real work the generic workbench does not — claims, delegations, escalation, task routing. It is a workflow layer, not a second store: its assertions land canonically, through the same write path any other owned object uses. A group's membership rules (a naming pattern, an account on a given system, a kind of non-human identity) are edited on the group's page; a rule that could match nothing or everything is refused.
Writes are graded, and the grading is the point:
- An explicit human decision — an assignment, a transfer, an accepted claim — lands unconditionally. Someone just said who is accountable.
- A heuristic or knock-on effect — a naming-pattern rule, a group's own owner being edited, a sponsor imported from a directory — may only fill a hole or update a value it wrote itself. A canonical owner set by an administrator elsewhere is never overwritten; it is kept, logged and counted.
The inverse holds too. Removing an identity from a management group retires the canonical row only if that row still points at that group, so an owner someone re-pointed in the workbench survives the workflow-layer unassign. And a sponsor that cannot be resolved to a real person produces no owner row at all — the agent surfaces as unowned and enters the claim flow, rather than acquiring a placeholder that reads like an answer.
Where an owner comes from when nobody set one
Resolution walks an ordered cascade and stops at the first step that yields somebody. For a non-human identity the default order is: an explicit owner row; then an approval bucket the identity falls into by membership or rule; then the owner of a context it belongs to — its cost centre, department, function, location or company, in that priority; and finally the terminal bucket.
Two properties make the cascade honest rather than merely convenient.
The terminal step is a gap, not an answer. A cascade that always produces somebody is lying: it converts "nobody has accepted accountability for this machine" into a name, and that name will be the same operations queue for thousands of identities. The terminal bucket routes work somewhere so nothing falls on the floor, but an identity that reaches it counts as uncovered everywhere coverage is reported.
A broken owner falls through. If an explicit owner row points at an identity that no longer exists — after a re-sync, a reorganisation, a deletion — the step is treated as "no owner here" and the walk continues. Treating it instead as a match with an empty result stops the cascade dead and hands the caller an identity that cannot be assigned work.
The same cascade serves all three places it could have drifted: the detail pane, the owners table, and the batched coverage rollup. The batch path preloads its inputs once and then walks the identical per-entity code, so list, rollup and detail agree by construction rather than by review.
Coverage and the orphan inbox
"Unowned" has exactly one definition: the cascade ran and ended at the terminal bucket. Coverage is its complement. One predicate serves the coverage dashboard, the orphan inbox, the first-week quick scan and the compliance control, so the percentage and the length of the inbox cannot disagree.
Note what that excludes: coverage is counted neither from explicit owner rows nor from management-group membership. An identity owned through a context, or owned directly by a person because an agent's sponsor was imported, is covered even though the workflow layer never saw it.
For identities that are genuinely unowned, the inbox proposes candidates, ranked: a match against a group's naming-pattern rule, a match on the system the identity lives in, the owner of that system, and — only if nothing else matched — a tenant-wide fallback group. Each carries a confidence figure, and that figure is a fixed ranking constant, not a measured probability. It says a naming-pattern match is a better guess than a system-owner fallback. It does not say the guess is right 85% of the time, and nothing measures whether it is. A naming convention is evidence that somebody once had a convention, not that a particular person accepts accountability today.
So a suggestion is not an assignment. It becomes a claim sent to the proposed owner with a grace window — 14 days by default — which they accept, redirect, escalate or reject; an unanswered claim expires rather than silently becoming true. Passing a claim on or escalating it means picking a person (a search over active people, with an optional note), and that person gets a new claim to answer. Bulk-sending claims is gated on a confidence floor, and bulk auto-assignment is set higher still. The human step is the product, not the friction.
The claim can also start with a person. Every employee can open Claim an account under Request, find a non-human identity by typing at least three characters of its name (ten results at most, so the page cannot be used to browse the estate) and say it is theirs. An NHI's page asks the same question of the person looking at it. Nothing changes on the claim itself: an IAM administrator or the identity's current owner approves or rejects it from the inbox, and only that approval writes the owner. Until then the claimant can follow or withdraw their own claims on the same page.
What asks for an owner before it will finish
Ownership is not a field that can be filled in later — not in the processes that put objects through review. Three of them ask for it first and refuse without it: role mining will not formalise a proposal, entitlement onboarding will not submit, application onboarding will not submit. The refusal is server-side — the request is rejected with the reason — so it holds for the API and for any client, not only for the wizard that happens to grey out its button. It is a gate on those processes, not on the catalog: an object created directly or imported by a sync can still be ownerless, and that is exactly the population the coverage figure above and the orphan inbox exist for. Entitlement onboarding resolves its reviewer chain through the same cascade, and when that cascade ends on its default IAM-team step, the request is accepted with the IAM team as the derived owner instead of being refused (no explicit owner is written, and a tenant that removed that step keeps the hard refusal); application onboarding's default approver is the owner of the directory that fronts the application — ownership decides who is asked, though not by way of the owner you just named. An application's own owner also sees and decides the onboarding requests for that application, and only those; being an owner gives no right to start or edit an onboarding request.
The same store answers the question backwards. The Insight view ranks owners by how many objects resolve to them, so a person carrying a third of every entitlement is visible while they still work here rather than discovered in their last week; and when an owner enters the leaver process while still holding objects, the Advisor raises one finding per leaver listing what they hold, proposes their manager as successor, and its apply action reassigns through the ordinary handover path — the same one an administrator uses by hand. Nothing is reassigned silently. The finding says who is leaving and what will orphan; a person decides where it goes.
For non-human identities the question comes before the owner leaves. When the person who owns a service account or AI agent (directly, or as the official owner of the group that owns it) has an end date, an ownership certification "who takes over?" starts for each of those identities a set number of days ahead: 14 by default, between 0 and 90, under the non-human identity ownership settings, where 0 turns it off. It goes to the group's delegate, else the leaver's manager, else the IAM administrators; never to the leaver. It closes by itself when the end date moves or is cancelled, the identity is handed over or it is retired. Approving it confirms the successor; the move itself still goes through the ordinary handover.
Dormancy needs capability and evidence
A grant's last-used timestamp is empty for two completely different reasons. Either the connected system reports activity, the platform has looked, and this grant has not been touched — a real finding. Or the platform cannot see activity on that system at all, in which case the empty value means "we do not track this", and reading it as dormancy is a fabrication.
A system therefore counts as usage-tracked only when both hold:
- Capability — the connector's engine can actually retrieve usage events. This is a property of the code, probed per engine, not a checkbox somebody could tick optimistically. Today that means Microsoft Entra, Google Workspace and Active Directory (OpenLDAP does not report a last logon); every other connected system has unknown dormancy by construction, and says so.
- Evidence — an ingest cycle for that specific connector has completed at least once. Capability is a claim about what could be observed; this is the record that somebody looked. Fetching zero events is a valid completed cycle — "we polled, nothing new" — and counts. A failed cycle does not, and a later failure never erases evidence already earned.
If a tenant has no system meeting both conditions, dormancy is unknown for every grant and nothing is flagged. That is not a degraded mode; it is the correct answer. It exists because the alternative shipped once: a tenant with no usage ingest saw its entire grant population — 8,841 of them — reported as dormant, which is a confident, comprehensive, worthless finding.
Both consumers of that rule — the advisor's dormancy detector and the identity risk score's dormancy components — share one implementation, because they previously held byte-identical copies kept in step by a comment asking the next person to remember. A tenant seeing dormant grants in one place and not the other has no way to tell which is wrong.
Within tracked systems, a second and much narrower control decides how to read an empty timestamp: by default it means "never used since we started watching", which on a system that is being watched is the strongest dormancy signal there is. It can be suppressed per tenant. The two never overlap — one concerns systems we cannot observe, the other grants we have observed and never seen used.
Acting on a dormant finding revokes the grant on the target system but keeps the row, so the record that the access once existed survives for audit.
Known edges, published rather than discovered
- A legacy owner column is still written. Assigning an owner from the NHI estate page writes the canonical ownership row and, for now, an older per-identity column as well. Every read — estate page, coverage figure and risk score — uses the canonical row, so they agree. Removing the column is outstanding work.
- Usage observation is narrow. Three connectors can report it (Entra, Google Workspace and Active Directory). Dormancy anywhere else is unknown, and reported as unknown — never as zero.
- No discovery of every NHI class. Machine identities in unconnected systems, or in connected systems exposing no record for them, are not governed. No inference step claims otherwise.
- NHIs have no manager fallback. For a person the cascade can usually fall back to a line manager; for a machine there is nothing equivalent, so an identity with no explicit, bucket or context owner is a genuine gap. Inventing an owner would be worse than counting it. The seeded attestation reviews go to the owner first; only when nobody owns the identity do they fall back to a manager on record, if one is recorded, and they label that person as a fallback, not as the owner.
- Attestation reviews the record, not the reality. The seeded yearly attestation asks whether an identity is still needed and still owned. It confirms someone is still willing to answer for it; it does not verify what the identity is doing.
Further reading: