NHI & AI Agent Lifecycle Management Guide

For NHIs and agents: Every identity, whether a service account or an agent, is created through an approved route with an owner, a purpose and an end date.

Joiner, mover and leaver processes are usually weak for NHIs. Static NHIs are created through many different provisioning routes, and the credentials are often handed directly to the person who asked for them, which leads to humans using NHIs inappropriately. The 2026 standard is simple: no NHI without an owner, a purpose and an expiry date, and no credential that a person ever sees.

• ProvisioningCreate NHIs through code and pipelines (infrastructure-as-code), recording owner, purpose and expiry at creation. Where a static secret cannot be avoided, feed it directly into a secrets vault, with no human intervention or visibility.
• Workload identity firstBefore issuing any secret, ask whether the workload can use an identity its platform issues at run time instead: a cloud managed identity, workload identity federation or SPIFFE. Dynamic NHIs are secure by design because they are issued just in time and there is nothing to hand over.
• DecommissioningHave a clear offboarding process for static secrets. When an account is no longer used, or people leave or move role, they may still know the passwords, keys or tokens, which can then be misused internally or in cloud and SaaS environments. Tie decommissioning to the application or service lifecycle as well: when a service is retired, its identities, keys and OAuth grants go with it.
• RecertificationRegularly confirm that each static NHI is still valid and needed (see Posture Management). Anything past its expiry date or without an owner is disabled first and deleted after a grace period.

OWASP NHI Top 10 (2025): NHI1 Improper Offboarding · NHI9 NHI Reuse

For NHIs and agents: You cannot govern what you cannot see: one inventory for service accounts, keys, tokens, OAuth grants and agents.

This is the most important place to start an NHI programme: it shows the size of the problem and drives remediation. It is also one of the hardest, because NHIs rarely sit in one identity system. You will deal with multiple identity providers, directory services and local accounts across hybrid cloud, SaaS and on-prem. And it is never finished: new NHIs appear every day, so discovery has to run continuously, not as a one-off project.

• Directory vs local accountsNHIs in a directory service such as Active Directory are far easier to inventory than accounts defined locally on an operating system or database, which usually need custom feeds that take significant time and effort to build.
• Cloud, SaaS and third partiesPull NHIs continuously from cloud IAM, identity providers and SaaS admin APIs, including OAuth app grants, SaaS-to-SaaS integrations and personal access tokens. Third-party connections are now a major NHI breach route: in August 2025, OAuth tokens stolen from the Salesloft Drift integration were used to export data from customers' Salesforce instances.
• ScanningScan source code repositories, SharePoint, Confluence and file systems for plain-text credentials. Anything exposed there can be found by external and internal threat actors. Extend scanning to chat (Slack, Teams), tickets, container images and CI/CD logs: GitGuardian counted 28.65 million new hard-coded secrets on public GitHub in 2025 alone.
• ContextScanners tell you a credential was found, but rarely which account it belongs to or where it is used. Building that context is the real work. Build the inventory as a map (identity, credential, workload, owner, permissions) so every finding has an owner and a fix.

OWASP NHI Top 10 (2025): NHI2 Secret Leakage · NHI3 Vulnerable Third-Party NHI

For NHIs and agents: Owner, privilege and blast radius decide what to fix first, for NHIs and agents alike.

Classify every NHI by its key attributes. With this metadata you can rank risk by level of privilege and blast radius, and fix the riskiest identities first.

• OwnershipClear ownership drives accountability for risk reduction. Do not underestimate the effort: we have seen global programmes take several years to claim ownership. I would map each NHI to an application or service (which has owners) rather than to a person, so ownership survives team changes.
• Level of privilegeKnow whether an NHI has admin, write or read access. This can be hard, as it often means understanding each platform's entitlement model.
• Blast radiusAn account that reaches hundreds or thousands of assets carries far more risk than one that reaches a single asset. Include what it can reach indirectly, through trust relationships and assumed roles.
• Account usageKnowing whether an account is used enables quick wins: removing inactive and legacy accounts. Usage data is easy to get on some platforms, hard on others, and missing on some. Usage also shows which permissions are actually exercised, the basis for right-sizing in Posture Management.
• ExposureTag NHIs that touch production, regulated data or the internet, and credentials held by third parties. These come first.

OWASP NHI Top 10 (2025): NHI5 Overprivileged NHI · NHI3 Vulnerable Third-Party NHI

For NHIs and agents: Least privilege is continuous: right-size access from what each identity actually uses.

Posture management is the continuous hygiene of an NHI programme: finding risky identities and settings and bringing them back to policy every day, not at audit time. In 2026 that means risk-scored findings, and permissions right-sized from real usage rather than guesswork.

• Excessive permissionsNHIs are often highly privileged, and many are over-privileged. Bring them back to least privilege, using usage data to remove what each NHI has not used.
• Inactive accountsOutdated, redundant or unused NHIs add risk with no benefit. Removing them improves security and simplifies operations.
• Shared accountsNHIs shared across applications break segregation of duties and least privilege, and make rotation and clean-up risky because the dependencies are unknown.
• Environment segregationUsing the same NHI in production and non-production creates lateral movement risk.
• Cloud and pipeline settingsLong-lived cloud access keys, over-broad trust policies and pipelines that deploy with static cloud keys are posture findings in their own right.

OWASP NHI Top 10 (2025): NHI5 Overprivileged NHI · NHI6 Insecure Cloud Deployment Configurations · NHI8 Environment Isolation · NHI9 NHI Reuse

For NHIs and agents: The best credential is one that is never stored: issued at run time, short-lived and scoped to the task.

Remediating NHI credential risk now starts with one question: does this workload need a stored secret at all? Remove the secret where you can, vault what you cannot, and rotate what remains. Moving plain-text credentials into a vault is still essential for legacy and third-party systems, but it is a step on the way, not the end goal.

• Secretless firstReplace stored secrets with short-lived credentials the platform issues at run time: cloud managed identities, workload identity federation (for example a CI/CD pipeline using OIDC to reach the cloud with no stored keys) and SPIFFE/SPIRE for workloads across clusters and clouds.
• VaultingMigrating credentials out of code into a vault is no small task: it must work at global scale and high volume, and be resilient. Support runtime, agent-based and build/deploy-time integration patterns for strategic and legacy applications, decide how credentials are onboarded (central inventory feeds or application teams), and define account namespaces to support rotation and reporting.
• RotationRotation reduces leaver and transfer risk, removes exposure in legacy code and version history, and uncovers hidden dependencies and sharing. It is also hard: if you do not know every script and application using a credential, rotating it can break things. Automate rotation, tightly coupled to your vault; manual rotation does not scale. Regulators now expect it: PCI DSS v4.0 (mandatory since 31 March 2025) bans hard-coded passwords for system and application accounts and requires periodic change based on risk.
• Strong authenticationReplace passwords with certificates, signed tokens or mutual TLS, keep any remaining secrets encrypted with securely managed keys, and scope every credential to one workload and one environment.

OWASP NHI Top 10 (2025): NHI2 Secret Leakage · NHI4 Insecure Authentication · NHI7 Long-Lived Secrets

For NHIs and agents: Every action is tied to an identity and its owner, so misuse is spotted and shut down in minutes.

This is one of the hardest controls to deliver well, and one of the most critical: a threat actor will always find a way to discover and misuse an NHI credential. The good news is that NHIs are predictable, with the same calls from the same places, which makes anomalies easier to see than with people. The goal is response in minutes, not just detection.

• Behaviour baselinesThe volume of events, the number of platforms and the uneven quality of their data make reviewing every event impossible. Baseline each NHI's normal behaviour (source, timing, API calls, data volume) and alert on deviations.
• Human use of NHIsUnderstand why people use NHIs. Uses teams consider business as usual need to be rooted out, or you will never see the wood for the trees.
• False positivesTune detections continuously so real threats stand out.
• Automated responseAgree playbooks in advance that revoke or rotate a credential, disable the identity and notify its owner when a leak or anomaly is confirmed. A leaked-secret alert should trigger revocation, not a ticket.

OWASP NHI Top 10 (2025): NHI10 Human Use of NHI · NHI2 Secret Leakage

For NHIs and agents: Zero standing privilege: no always-on access for NHIs or agents; access is granted just in time and checked at the moment of action.

Prevention is where the programme pays off: stop secrets being created and leaked, remove standing access, and enforce policy at the moment of access. In 2026 these are mainstream practice, not future state.

• Stop secrets at sourceAs part of a DevSecOps shift-left approach, scan code at check-in and block any commit that contains a secret. Code platforms now do this by default for new public repositories (GitHub push protection, since March 2024); extend it to private repositories and CI/CD.
• Zero standing privilegeMove from static to dynamic secrets through workload identity, so there is nothing long-lived for attackers to steal. Grant elevated access just in time, scoped to the task and revoked automatically when it ends.
• Real-time policyMove from after-the-event detection and response to real-time protection: anomaly detection and policy enforcement at, for example, the identity control plane or transport layer, blocking inappropriate access as it happens. Express policy as code and evaluate it on every request.
• Standards to watchWorkload identity is being standardised: the IETF WIMSE working group (workload identity across multi-system environments) and OAuth 2.0 Token Exchange (RFC 8693) for delegation. These are the same building blocks AI agents now rely on.

OWASP NHI Top 10 (2025): NHI7 Long-Lived Secrets · NHI2 Secret Leakage