By NHI Mgmt Group Editorial TeamPublished 2026-06-18Domain: Governance & RiskSource: SecurEnds

TL;DR: Enterprise identity programmes now have to govern both human access and machine behaviour: the article argues that IGA handles provisioning, certifications, and least privilege for people, while AI governance manages runtime actions, drift, and accountability for agents and bots, according to SecurEnds. The key gap is that valid credentials do not guarantee valid behaviour, so access control alone is no longer enough.


At a glance

What this is: This is an independent analysis of why IGA and AI governance are distinct disciplines, with the key finding that runtime AI behaviour cannot be governed by access controls alone.

Why it matters: It matters because IAM teams now have to govern human users, NHIs, and AI agents with different control points, or risk leaving agent behaviour, privilege sprawl, and accountability gaps unaddressed.

By the numbers:

👉 Read SecurEnds' analysis of why AI governance is different from IGA


Context

AI governance is the discipline of controlling what AI systems do at runtime, while IGA is the discipline of controlling who has access to what. The problem is not semantic. Once enterprises connect agents, bots, and machine accounts to real systems, access governance alone no longer captures the risk.

That gap shows up most clearly in identity programmes that are mature for people but immature for non-human identities. Service accounts, API keys, OAuth tokens, and AI agent credentials often share the same lifecycle weaknesses: unclear ownership, excessive privilege, and weak offboarding. A programme that cannot govern those identities will struggle to govern autonomous behaviour as well.


Key questions

Q: How should security teams govern AI agents that use production credentials?

A: They should govern them as identities with both lifecycle and runtime controls. That means inventorying the credential, assigning ownership, limiting privilege, rotating secrets, and adding behaviour monitoring that can detect scope drift, unsafe tool use, or policy violations after access is granted. Access approval alone is not enough.

Q: Why do NHIs and AI agents complicate traditional IAM programmes?

A: Because IAM was designed to answer who should have access, not how a non-human actor behaves once access exists. NHIs and AI agents can move faster, scale further, and retain privilege in ways human-focused programmes do not model well. That creates risk in ownership, offboarding, and runtime accountability.

Q: What breaks when access certification is used as the main control for AI governance?

A: Certification only validates that a permission was approved at a point in time. It does not show whether an AI agent later accessed data outside its intended purpose, chained tools incorrectly, or caused policy exposure. If runtime behaviour is the risk, certification is necessary but incomplete.

Q: Who should be accountable when an AI agent acts outside its intended scope?

A: Accountability should sit with the named business owner and the technical owner of the agent, not with the abstract fact that the system was deployed. Organisations need explicit ownership for provisioning, oversight, exception handling, and decommissioning so that misbehaviour has a clear governance path.


Technical breakdown

Why IGA stops at the permission layer

IGA answers three classical questions: who has access, should they have it, and can you prove it. That model works because the subject is a person and the security problem is mostly static entitlements. Once access is granted, IGA can certify or revoke it, but it does not observe how the access is used. That makes it a provisioning-time control, not a runtime control. In practice, IGA is strong at joiner-mover-leaver governance, segregation of duties, and audit evidence. It is weak at detecting whether a legitimate identity is acting outside its intended purpose after the fact.

Practical implication: Use IGA to govern entitlements, but do not expect access reviews to detect misuse once a session has started.

Why AI agents behave like non-human identities with runtime risk

AI agents, bots, and machine accounts are NHIs because they act through credentials rather than human authentication flows. The difference is that agentic systems can make decisions and trigger actions continuously, at machine speed, and often without a person reviewing each step. That changes the governance problem from static access to dynamic behaviour. Credentials may be correctly issued, yet the agent can still access data it was not meant to use, chain multiple tools, or create legal exposure through its outputs and actions. The important point is that valid identity does not equal valid conduct.

Practical implication: Treat AI agents as governed identities plus monitored actors, with policy enforcement that extends beyond initial provisioning.

How shadow AI and over-privileged NHIs expand the blast radius

When business units deploy agents without central oversight, they often reuse shared keys, attach broad permissions, and skip owner registration. That creates shadow AI, which is simply unmanaged AI identity at scale. The same failure pattern already exists in conventional NHIs, where service accounts accumulate access over time and remain active after the original business need changes. The architectural issue is not just sprawl. It is that machine identities are often treated as disposable plumbing even when they can reach critical systems, customer data, or production workflows.

Practical implication: Inventory every AI-linked credential, assign ownership, and review permissions as if each one were a production system account.


Threat narrative

Attacker objective: The objective is to use legitimate identity access to perform actions or expose data in ways the governance model did not anticipate.

  1. Entry occurs through valid machine credentials such as service accounts, API keys, OAuth tokens, or AI agent accounts that were provisioned for business use.
  2. Escalation follows when those credentials carry excessive privilege or when an AI system expands its activity beyond the intended scope of the original approval.
  3. Impact comes from unauthorized data access, workflow manipulation, or policy violations that valid provisioning controls did not prevent.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

IGA and AI governance are structurally different disciplines, not adjacent labels for the same control set. IGA governs access entitlements at provisioning time, while AI governance governs behaviour at runtime. That distinction matters because the security failure changes once the actor can decide and act continuously. The implication is that organisations should stop treating AI runtime policy as a simple extension of access certification.

Non-human identity governance is the missing bridge between human IAM and AI governance. The article is directionally right that AI agents are NHIs, because their credentials, ownership, rotation, and offboarding still belong in identity governance. But the discipline must extend further than service account hygiene, because an AI agent can be correctly provisioned and still behave incorrectly. Practitioners should read this as a signal that NHI management is now the shared control plane for machine and agent identity.

Shadow AI is really shadow identity with runtime consequences. Business units that connect agents through shared API keys or unmanaged credentials are not just bypassing policy. They are creating identities that are outside normal lifecycle, certification, and accountability processes. That is a governance failure, not just a tooling gap. The implication is that AI inventory, ownership, and lifecycle controls now belong in the same conversation as NHI governance.

Named concept: runtime governance gap. The runtime governance gap is the space between a valid identity being approved and that same identity being allowed to act safely over time. Traditional IGA closes the approval question, but not the behaviour question. In environments with AI agents, that gap becomes the core security problem because action can diverge from intent after provisioning has already been validated. Practitioners need to recognise that the gap itself is the risk surface.

Access review cadences were designed for identities whose risk state changes slowly. That assumption fails when an AI agent can generate thousands of decisions or tool calls between review cycles. The implication is not simply more frequent reviews. It is a recognition that the review model itself cannot see the runtime state that now matters most.

From our research:

What this signals

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the operational signal is clear: identity programmes still lose sight of machine-connected access before runtime controls even come into play. That makes shadow AI and unmanaged NHI governance an inventory problem as much as a policy problem.

Runtime governance gap: as AI adoption expands, the programme failure will increasingly be measured by what happens after credentials are issued, not by whether approvals were collected. Security teams should expect more pressure to link IGA evidence, NHI ownership, and behavioural monitoring in a single operating model.

Practitioners should also track the boundary between identity governance and AI governance in their own programmes, because a control stack that cannot explain who owns an agent, what it can reach, and how its actions are supervised will be hard to defend during audit or incident review.


For practitioners

  • Map AI agents into the identity inventory Record every agent, bot, and machine account in the same authoritative inventory used for NHIs and human access reviews. Include owner, purpose, credential type, system reach, and whether the identity can trigger production actions.
  • Separate entitlement governance from runtime governance Use IGA for provisioning, certification, and lifecycle control, then layer runtime monitoring and policy enforcement for agent behaviour, data access, and tool use. Access approval alone does not tell you whether the actor is operating within intent.
  • Reduce over-privilege on machine and agent credentials Review AI-linked service accounts and tokens for write access, broad data reach, and inherited permissions that are not essential to the declared use case. Remove shared credentials and attach the minimum permissions needed for the task.
  • Tie accountability to each deployed agent Assign a named business and technical owner for every AI agent, including offboarding responsibility, exception approval, and incident response coordination. Unowned agents should be treated as unmanaged identities until proven otherwise.

Key takeaways

  • IGA still matters, but it only governs entitlements and cannot by itself govern what AI agents do with those entitlements.
  • Machine identities and AI agents expand the attack surface when ownership, privilege, and offboarding are weak, especially in shadow deployments.
  • Identity teams should pair lifecycle governance with runtime monitoring so that approved access does not become uncontrolled behaviour.

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 AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01AI agents use machine credentials that need lifecycle and ownership control.
NIST CSF 2.0PR.AA-01Identity governance must cover access assignment and accountability for machine actors.
NIST AI RMFAI governance must address runtime behaviour, accountability, and policy enforcement.

Establish govern and manage controls for AI agents, including runtime oversight and escalation paths.


Key terms

  • Identity Governance And Administration: The control discipline that manages who has access to what, why that access exists, and whether it should remain in place. In practice, it covers provisioning, access certification, segregation of duties, and deprovisioning for human identities and, where extended, non-human identities.
  • Non-Human Identity: A machine identity used by software, workloads, services, or agents to authenticate and act inside an environment. This includes service accounts, API keys, tokens, certificates, and AI agent credentials, all of which need ownership, lifecycle control, and access scope management.
  • Runtime Governance Gap: The space between approving an identity and supervising what that identity does after approval. For AI agents and other NHIs, this gap matters because valid access can still produce invalid, unsafe, or non-compliant actions once execution begins.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by SecurEnds: AI governance and IGA are not the same discipline for identity. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-18.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org