MITIGATION · m-nhi-lifecycle
NHI lifecycle management — provision, rotate, audit, decommission
A Non-Human Identity (NHI) is the service account, machine principal, or formal agent identity under which an agentic system authenticates and acts. When an NHI is provisioned with broad scope, never rotated, and has no named owner, a stolen or leaked credential gives an attacker persistent access for as long as that credential remains valid. NHI lifecycle management treats each agent identity as a first-class governance object: provision narrowly with a declared scope and owner, rotate on a short schedule using platform-native short-lived credentials, audit every authentication and rotation event, re-attest that the identity is still needed, and decommission by deletion when the agent is retired.
At a glance
TL;DR
- Every agent service account and formal agent identity is provisioned narrowly, with a named owner team, a declared scope, and a planned decommission date recorded in the NHI registry.
- Credentials rotate on a short TTL using platform-native short-lived tokens (STS, Vault dynamic secrets, federated workload tokens); any static long-lived secret is treated as a finding, not a default.
- Every authentication, rotation, and authorisation event is logged under the NHI's stable identifier, so the audit trail persists even if the credential is compromised or replaced.
- When the agent is retired, the identity is deleted, not parked, and a scheduled reconciliation job catches any orphans that accumulate between quarterly re-attestation cycles.
How it behaves
What it is
A Non-Human Identity is the credential under which an agentic system authenticates to other services: a service account, a machine principal, or a formal agent identity such as a Microsoft Entra Agent ID. Unlike a human user who logs in once and logs out, an NHI typically operates continuously, often across trust boundaries, and its credential persists until something actively expires or revokes it.
That persistence is the problem. An NHI provisioned with broad scope, no named owner, and no rotation schedule is a long-lived credential that grants elevated access to anyone who finds it. At enterprise scale the exposure compounds: surveyed organisations run roughly 17 machine identities per human identity, and agentic AI is adding more. Agent NHIs are also qualitatively different from traditional service accounts because their scope is often deliberately broad: an expense-processing agent reads HR data and writes to payment systems; a code agent reads source repositories and writes to CI/CD pipelines. A single stolen credential therefore carries more authority and reaches further than a conventional service-account compromise.
NHI lifecycle management addresses this by treating each agent identity as a governed object with a defined beginning and end. The control covers five phases:
- Provision narrowly. Issue the NHI with the minimum scope required for its declared function, assign a named owner team, and record a planned decommission date in the NHI registry.
- Rotate on schedule. Use platform-native short-lived credentials (STS tokens, Vault dynamic secrets, federated workload tokens) so each credential has a short, bounded TTL. Treat any static long-lived secret as a finding.
- Audit every event. Log every authentication, rotation, and authorisation event against the NHI's stable identifier, so the audit trail persists even if the credential itself is compromised or replaced.
- Re-attest regularly. On a quarterly cadence, verify that each NHI is still in active use, still correctly scoped, and still has a living owner team.
- Decommission by deletion. When an agent is retired, delete the identity; do not park or disable it. A scheduled reconciliation job catches any orphans that accumulate between audit cycles.
Detection signals
- Credential age distribution across production NHIs. A long tail of credentials older than the declared rotation schedule indicates stale identities and an elevated exposure window.
- Authentication attempts from decommissioned NHI identifiers. Any successful or attempted authentication from a deleted or retired identity is a signal of stale-credential abuse.
Threats it covers
-
WHY IT HELPS Privilege Compromise depends on an agent identity retaining elevated access beyond its intended scope or lifetime. Narrow provisioning sets a defined scope ceiling at issuance; aggressive rotation shortens the window within which a compromised credential can be exercised; re-attestation removes scope that accumulated over time. Together they reduce both the authority a stolen credential carries and the duration it remains usable.
-
WHY IT HELPS Persistent Agent Identity Takeover requires that a stolen formal agent identity remain valid and authoritative long enough to be weaponised across sessions or pipelines. Aggressive rotation invalidates the credential before that window closes; prompt decommissioning ensures that an identity associated with a retired agent cannot be reused. The combination converts a potentially indefinite takeover into a bounded, time-limited exposure.
-
WHY IT HELPS Accidental credential exposure leaves a service-account secret valid and exploitable for as long as it remains unchanged. Aggressive rotation invalidates an accidentally exposed credential before an attacker can act on it; narrow provisioning limits the blast radius of any window where the credential is still valid.
Principle coverage
Defence-in-Depth stage: Prevent — and it advances:
- Zero Trust Zero Trust assumes no identity is inherently trusted. NHI lifecycle management enforces that for agent identities by ensuring every credential has a bounded TTL, a declared scope, and a named owner, so no agent principal holds standing access beyond what has been explicitly provisioned and recently re-attested.
- Least Privilege Least privilege requires that an identity hold only the authority its current function warrants. NHI lifecycle management enforces that through narrow provisioning at issuance and quarterly re-attestation that removes scope accumulated over time, so the agent never retains permissions that outlived the function that justified them.
- Agent-as-principal Identity Agent identity requires that every agent principal be uniquely identifiable, cryptographically distinct, and governed through its full operational life. NHI lifecycle management provides that governance end-to-end: provisioning assigns a stable identifier with declared scope; rotation keeps credentials short-lived; re-attestation confirms continued need; decommissioning by deletion ensures the identity cannot persist beyond its authorised lifetime.
Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.
Implementation options
Five verified implementation options spanning secrets-engine dynamic credentials, certificate-based workload authentication, cloud-native keyless federation, and purpose-built agent identity governance. Most deployments compose at least two: one for credential issuance and one for lifecycle governance and visibility.
HashiCorp Vault Vault generates unique, short-lived credentials on demand for each service or agent role, with a configurable lease TTL and automatic revocation at lease expiry.
Why choose it: Best when agent workloads span multiple clouds or on-premises systems and you need a single secrets plane. Dynamic secrets mean every agent instance gets unique credentials rather than a shared static secret; Vault's internal revocation system removes credentials within a predictable window after lease expiry. Static-role rotation is the fallback for systems that cannot accept per-request credential churn.
More details:
AWS IAM Roles Anywhere Exchanges X.509 certificates issued by a trusted CA for short-lived STS tokens, letting agent workloads running outside AWS access AWS services without long-term access keys.
Why choose it: Best for agent workloads that run outside AWS (on-premises, other clouds, CI/CD runners) but need AWS API access. The PKI lifecycle, certificate issuance, renewal, revocation, becomes the NHI lifecycle signal. Trust anchors are regional and account-scoped, so you control exactly which CA can produce credentials that are accepted. Eliminates the class of hard-coded AWS_ACCESS_KEY_ID incidents for off-cloud agents.
More details:
GCP Workload Identity Federation Lets external identities (AWS, Azure, GitHub Actions, Kubernetes service accounts, OIDC providers) exchange their native credentials for a short-lived Google OAuth 2.0 access token via the Security Token Service, eliminating service account JSON keys.
Why choose it: Best for GCP-native agent workloads or multi-cloud agents that need access to GCP resources. Token exchange is automatic and short-lived; there are no long-lived key files to rotate or leak. Workload identity pools group external identities by environment (dev, staging, prod), and attribute conditions filter which identities can authenticate, giving you both provisioning control and a continuous enforcement boundary.
More details:
Microsoft Entra Agent ID Extends Entra ID with agent identity blueprints, enforced human sponsorship, lifecycle management from provisioning through deactivation, and integration with Conditional Access, Identity Protection, and ID Governance access reviews.
Why choose it: Best when agent identities operate in the Microsoft 365 or Azure ecosystem, or when you need to govern third-party agents (AWS Bedrock, n8n) alongside Microsoft-native ones via workload identity federation. The agent identity blueprint model means decommissioning one blueprint can cascade to all child agent instances. Access reviews for service principals add the re-attestation layer. Requires Entra ID P1 for Conditional Access; P2 or Governance for access reviews; Workload ID Premium for service principal reviews.
More details:
Self-build NHI registry A lightweight internal service that maintains an inventory of all NHIs (owner, scope, rotation schedule, decommission date), triggers rotation via the relevant cloud SDK on schedule, and flags or blocks credentials that have aged past their declared TTL or whose owner team no longer exists.
Why choose it: Best when agent workloads span identity providers that none of the managed options cover natively, or when you need a single source of truth for NHI ownership that feeds your ticketing and on-call systems. The registry is the authoritative source for decommission discipline: reconcile production credentials against registry entries on a nightly cron; anything in production with no registry entry is an orphan and gets revoked. The technical implementation is low complexity; the organisational work of getting every team to register their NHIs is the hard part.
More details:
Trade-offs
- Rotation latency is low: platform-native credential issuance (STS, Vault lease, GCP STS exchange) is sub-second and asynchronous to the agent's action path.
- The dominant adoption cost is engineering time during the first rotation sweep: discovering and migrating hard-coded credential references in CI pipelines and environment files typically takes three to four times the initial estimate.
- Short TTLs can cause outages when downstream SaaS systems have slow credential-propagation latency measured in hours or days. Document those constraints and compensate with tighter monitoring rather than forcing an incompatible rotation cadence.
- Decommission discipline degrades silently without a recurring, budgeted audit: production NHI counts grow monotonically unless deletion is an explicit operational commitment.
When NOT to use
- Do not apply aggressive short-TTL rotation to NHIs that interact with third-party services whose credential-propagation latency is measured in hours or days; overly short TTLs will cause production outages.
- Do not over-engineer rotation for read-only or low-privilege NHIs where the blast radius of a stolen credential is negligible; minimum-viable rotation (annual or on compromise signal) is proportionate.
- Avoid adding a bespoke lifecycle layer when the cloud platform already enforces short-lived credentials natively (AWS EC2 instance profiles, GCP attached service accounts); parallel layers create confusion without additional security benefit.
Limitations
- Lifecycle controls bound the exposure window of a stolen credential; they do not prevent the theft. Pair with anomaly detection to catch stolen-credential abuse within the window.
- Rotation breaks systems that hard-code credentials. The first rotation cycle is operationally disruptive; subsequent cycles are routine only if hard-coded references were fixed before rotation was enabled.
- The control is blind to in-application permissions granted outside the platform IAM layer (database row-level security, SaaS internal roles). Those layers need independent re-attestation.
- No industry-standard scorecard exists for NHI lifecycle maturity; each deployment must define its own baseline schema for declared scope and rotation cadence.
Maturity tier reasoning
- Tier 2 fits because the primitives (Vault dynamic secrets, AWS Roles Anywhere, GCP Workload Identity Federation, Entra Agent ID) are all production-available and documented.
- What keeps the agentic application at Tier 2 is the discipline gap: most production deployments inherit messy NHI hygiene from the surrounding enterprise, and operational playbooks for agent-specific identity lifecycle are still maturing.
- Expect progression toward Tier 1 as Entra Agent ID blueprint governance and the OWASP NHI Top 10 v2 establish more prescriptive agent-lifecycle norms.
Last verified against upstream docs: 2026-05-30.