By NHI Mgmt Group Editorial TeamPublished 2026-06-30Domain: EventsSource: Zluri

TL;DR: Access governance, lifecycle control, and visibility fail when service accounts, API keys, and AI agents sit outside the programme, according to Zluri; the deeper issue is that identity governance still treats machine access as an exception instead of the operating model.


At a glance

What this is: This is Zluri's view that NHI governance must be folded into IGA, with service accounts, API keys, and AI agents treated as governed identities rather than unmanaged exceptions.

Why it matters: It matters because identity teams cannot secure modern access paths if machine identities, human identities, and lifecycle processes are managed in separate control planes.

By the numbers:

👉 Read Zluri's view on NHI governance inside IGA


Context

NHI governance is the discipline of discovering, controlling, and lifecycle-managing non-human identities such as service accounts, API keys, tokens, certificates, and AI agents. Zluri's article argues that these identities belong inside IGA, because access review, offboarding, and compliance controls break down when machine access is treated as an exception.

That framing is directionally right for IAM teams, but the practical challenge is broader than visibility alone. Once machine identities span SaaS, workflows, integrations, and emerging agentic systems, the issue becomes whether the programme can continuously govern access across human, NHI, and lifecycle processes with one operating model.


Key questions

Q: How should security teams govern service accounts inside an IGA programme?

A: Treat service accounts as governed identities with owners, lifecycle states, and review evidence. Use the same inventory discipline as human access, but require technical context such as application purpose, integration dependency, and offboarding trigger. That avoids certifying stale records while active machine access remains in place.

Q: Why do access reviews fail when applied to non-human identities?

A: They fail when teams use human review logic for machine access. A service account cannot explain business need, and an API key may be embedded in a system rather than visibly assigned to a person. Reviews must focus on ownership, usage, and retirement criteria instead of attestation alone.

Q: What breaks when AI agents are given access without runtime monitoring?

A: Governance loses visibility into what the agent actually did after authorization. An agent can choose tools, change action paths, or exceed expected scope during a session, so static approval alone does not prove control. Teams need behavioural evidence, not only entitlement evidence.

Q: Who should be accountable for machine identity offboarding?

A: Accountability should sit with the system or application owner, with identity operations enforcing the control. If no one owns retirement, service accounts and keys outlive the process that created them and continue to expand the attack surface long after their use case ends.


Background and context

Why NHI governance fails when machine identities sit outside IGA

Non-human identities behave like identities, but they are often provisioned, used, and forgotten as if they were infrastructure settings. That creates long-lived access paths that bypass joiner-mover-leaver controls, recertification, and offboarding. In practice, service accounts and API keys accumulate permissions without the ownership, review cadence, or termination logic applied to people. Once that happens, the IGA record no longer reflects the real access surface. The result is not just poor visibility, but a control gap where entitlement governance and actual runtime access diverge.

Practical implication: bring every machine identity into the same governance inventory and review cycle as human access.

Access reviews for service accounts are not human access reviews

Access review is a governance process, not a document exercise. Human reviews assume a person can confirm role fit, business need, and continued legitimacy. Service accounts and API keys do not behave that way, because their owners may be application teams, integration teams, or vendors, and the access may be embedded in workflows rather than visible to end users. A service account that powers a critical integration can retain privilege long after the business use case changes. That means reviewer context, entitlement evidence, and retirement criteria all need to be different from human IAM.

Practical implication: separate machine identity certification from human access recertification and require technical ownership evidence.

AI agents add runtime variability to identity governance

AI agents are not just another workload credential because they can select actions, invoke tools, and adapt behaviour during execution. That means the access question is not only who approved the identity, but what it may decide to do after it is active. Traditional governance models assume stable intent and predictable use patterns. Agentic systems can change the sequence and scope of access within the same operational session, which makes entitlement review and least-privilege design harder to define at provisioning time. Governance has to account for behaviour, not just static assignment.

Practical implication: treat agent permissions as behaviour-bound and monitor tool use, not only entitlement state.


NHI Mgmt Group analysis

NHI governance belongs inside IGA, but only if the programme can distinguish ownership from runtime access. Machine identities are often governed by application teams, platform teams, or vendors, while their privileges live in directories, SaaS admins, and integration layers. That split creates an accountability gap where no one owns the lifecycle end to end. The practical conclusion is that identity governance must join entitlement records to technical owners, or the control plane will never match the access plane.

Service account lifecycle is the real control problem, not just secret storage. The common failure is to treat a credential as the whole problem and miss the underlying entitlement persistence. If a service account is not offboarded when the integration changes, the secret rotation only preserves a live access path. The named concept here is identity persistence debt: access survives after the business need that created it has disappeared, and governance has no clean retirement point. Practitioners need to recognise that as a lifecycle failure, not a storage issue.

AI agents force identity governance to move from static approval to runtime accountability. The old assumption is that access can be assessed at grant time because action paths are stable enough to predict. That assumption breaks when an actor can decide which tool to use and when to act during execution. The implication is that least privilege becomes behavioural, not purely declarative, and that review models must account for active decision-making rather than only assigned rights.

Access review is losing effectiveness wherever it is applied to identities that do not resemble people. Review cycles built for employee access do not map cleanly to service accounts, API keys, or autonomous systems because the evidence and decision logic are different. The organisation ends up certifying records instead of actual control. Practitioners should expect that mature IAM programmes will increasingly separate human certification, NHI certification, and autonomous behaviour review into distinct governance paths.

Visibility without lifecycle control produces a false sense of NHI maturity. Discovery tells you what exists, but it does not tell you whether access is still justified, who can retire it, or how quickly it will be removed when the business context changes. That is why NHI governance has to connect visibility, ownership, review, and offboarding into one workflow. Otherwise, the programme measures exposure without reducing it.

From our research:

What this signals

Identity persistence debt: the next maturity gap in NHI governance is not discovery, but retirement. Teams that can inventory machine identities but cannot prove timely revocation will keep accumulating dormant privilege across SaaS, integrations, and agent workflows.

The control question is shifting from "can we see it?" to "can we remove it when the business context changes?" That is why machine identity governance has to connect lifecycle events, ownership, and approval records to the same operating model used for access management.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, the governance issue is already structural, not theoretical. Security teams should align NHI controls with NIST Cybersecurity Framework 2.0 functions to make lifecycle accountability measurable.


For practitioners

  • Map every non-human identity to a named owner Build an inventory that links each service account, API key, token, and certificate to a business owner, technical owner, and system of record. Without named ownership, review and offboarding will fail when the original team changes.
  • Separate machine identity certification from human access review Use different evidence, approval criteria, and review cadences for service accounts and employee accounts. Machine identities need usage context, integration purpose, and retirement triggers, not just manager attestation.
  • Tie offboarding to application and integration change events Revoke machine identities when the integration, workflow, or vendor relationship ends. A credential rotation program alone will not remove stale privileges if the identity itself remains live.
  • Add runtime monitoring for AI agent tool use Track which tools an agent invokes, what data it touches, and whether it stays inside approved operational bounds. Behavioural monitoring is the only way to see scope drift once execution starts.

Key takeaways

  • Zluri's argument is that NHI governance cannot remain separate from IGA if machine identities are expected to be controlled, reviewed, and retired like other identities.
  • The evidence across identity research points to a persistent gap between visibility and removal, which leaves service accounts and API keys active long after their business purpose changes.
  • Practitioners should split human and machine governance paths, tie ownership to lifecycle events, and add runtime monitoring where AI agents can change behaviour after access is granted.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01Covers discovery and governance of non-human identities in the access surface.
NIST CSF 2.0PR.AC-4Access permissions must be managed for both human and machine identities.
NIST Zero Trust (SP 800-207)AC-4Zero trust depends on continuous verification, including for machine and agent access.

Apply least-privilege controls to service accounts and validate them through recurring governance reviews.


Key terms

  • Non-Human Identity: A non-human identity is a digital identity used by software, services, workloads, or agents rather than a person. It includes service accounts, API keys, tokens, and certificates. In governance terms, these identities need ownership, lifecycle control, and review just like human accounts.
  • Identity Persistence Debt: Identity persistence debt is the accumulation of machine access that remains active after the business need has changed or ended. It shows up when service accounts, keys, or tokens survive normal offboarding logic. Over time, it creates hidden privilege that discovery alone cannot remove.
  • Machine Identity Certification: Machine identity certification is the review process used to validate that non-human access is still needed, correctly owned, and appropriately scoped. Unlike human access reviews, it depends on technical evidence such as integration purpose, usage patterns, and retirement triggers rather than employee attestation.
  • Runtime Accountability: Runtime accountability is the ability to understand and govern what an identity actually does while it is active, not just what it was allowed to do at provisioning time. For AI agents, that includes tool selection, action timing, and behavioural drift during execution.

What to expect at the briefing

Zluri's full article covers the operational detail this post intentionally leaves for the source:

  • The article's product workflow for bringing access reviews and lifecycle management into the same platform
  • The specific feature set Zluri maps to service account visibility, access governance, and lifecycle control
  • The implementation framing for teams that want to connect identity management to broader SaaS administration

👉 Zluri's full article expands on the lifecycle and access-management framing behind the NHI governance argument.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-30.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org