By NHI Mgmt Group Editorial TeamBased on Clarity Security: “Who Governs AI? Why Identity Governance Should Come Before AI Adoption” (April 23, 2026)

TL;DR: Clarity Security says AI governance is already lagging because 63% of organisations lack formal AI governance policies and department-led AI integrations are creating non-human identities outside IT oversight; the core problem is inventory, not model policy. Governance breaks when teams cannot account for who provisioned access, what the identity can reach, and when it should be removed.


At a glance

What this is: This is an analysis of why AI governance fails when organisations cannot inventory the non-human identities created by AI integrations.

Why it matters: It matters because IAM and IGA teams cannot govern, certify, or revoke access for AI-connected systems they cannot see, especially as shadow adoption expands outside central IT.

By the numbers:

👉 Read Clarity Security's analysis of AI governance and missing NHI inventory


Context

AI governance fails when organisations cannot answer a basic identity question: who provisioned access, and what does the AI-connected identity actually reach. The article argues that the gap is already present because shadow AI adoption is creating non-human identities outside central IT workflows and outside existing governance visibility.

Traditional governance models were built around human joiner-mover-leaver processes, manager attestation, and periodic review cycles. Those assumptions do not hold for AI integrations created by departments, left running after a pilot, or connected directly to business systems without formal ownership.

The article frames this as an identity governance issue rather than a model-safety issue because the operational risk starts with untracked access, not with the AI model itself. That makes NHI inventory the first control boundary, not an optional reporting layer.


Key questions

Q: What breaks when an AI agent is not part of identity inventory?

A: When an AI agent is not part of identity inventory, governance breaks at the point of discovery. Teams cannot reliably answer who owns the agent, what credentials it uses, or what systems it can reach. That makes access review, offboarding, and incident response incomplete because the trusted entity was never formally brought under control.

Q: Why do AI infrastructure programmes create new identity governance risk?

A: They create risk because machine-speed workflows can combine APIs, secrets, and delegated authority faster than conventional review cycles can observe. That breaks assumptions built around human-paced approval, auditing, and recertification. The result is not just more access, but less clarity about which component exercised that access and whether it was still appropriate.

Q: How do teams know whether AI governance is actually working?

A: Look for evidence that every AI interaction can be traced end to end, from identity and intent to output and enforcement. If auditors can ask for a transaction and receive a complete record in hours, not weeks, the programme is producing usable control evidence rather than just documentation.

Q: Should organisations treat agentic AI access differently from service account access?

A: Yes. Service accounts are usually persistent and can be managed through lifecycle controls, while agentic AI access is often ephemeral, runtime-selected, and initiated on demand. The right governance model is different because the identity behaviour is different. Treating both as the same class leads to control gaps and delayed policy decisions.


Technical breakdown

How shadow AI creates unmanaged non-human identities

When a department connects an AI tool to a business system, it usually creates a persistent credential or delegated access path that functions as a non-human identity. The security problem is not the tool label, but the fact that the identity exists outside standard provisioning, review, and offboarding workflows. These identities can access CRM records, pipeline data, or internal systems without appearing in HR-driven governance processes. Because they are often created during pilots or experiments, they outlive the use case that justified them. In identity terms, the enterprise gains access paths that are real, active, and invisible to the governance program responsible for them.

Practical implication: Treat AI integrations as identity objects and inventory them with the same rigor used for service accounts and API credentials.

Why human lifecycle governance does not fit AI-connected access

IGA programmes assume a human lifecycle: join, change role, leave. That model depends on a manager, an employment record, and a predictable offboarding trigger. AI-connected non-human identities do not have those signals. Quarterly access recertification also breaks down because there may be no person to attest ownership when the integration is created outside IT. The result is orphaned access that remains valid long after the original business purpose has disappeared. This is a lifecycle mismatch, not just a tooling gap, and it explains why human-centric governance controls miss AI-created access paths.

Practical implication: Map AI-connected identities to an ownership and revocation process that does not depend on human HR events.

Why partial visibility turns governance into partial protection

Visibility is the control plane for identity governance. If teams can only see centrally provisioned identities, then every department-level AI integration expands the ungoverned perimeter. That creates a structural blind spot in risk decisions, certifications, and audit evidence. The problem compounds because each new integration adds a separate access path, often with broad permissions and weak lifecycle discipline. In practice, the governance programme starts reporting coverage while the real attack surface grows outside the boundary. This is why inventory quality determines whether AI governance is operationally real or merely documented.

Practical implication: Extend discovery to department-owned AI tools, shadow integrations, and non-human identities created outside standard workflows.


Threat narrative

Attacker objective: The practical objective is to gain persistent, unmanaged access through AI-connected identities that can later be abused, audited poorly, or left active after their original purpose ends.

  1. Entry occurs when a business unit connects an AI tool to a system such as a CRM without formal IT involvement, creating a new non-human identity and access path.
  2. Credential or delegated access is then granted broadly enough for the tool to read or process customer, contact, or operational data as part of the workflow.
  3. Privilege persists after the pilot or use case changes because no offboarding event removes the identity or reviews its access.
  4. Impact is the accumulation of orphaned AI-connected identities that expand the attack surface and leave governance teams unable to answer who has access to what.
  • Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.
  • DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

AI governance fails first as an inventory failure, not a policy failure. Formal policies matter only after an organisation can enumerate the identities actually touching its environment. When departments can connect AI tools directly to business systems, the governance programme loses sight of the access boundary itself. The practitioner conclusion is simple: no inventory means no governance.

The governance assumption that access belongs to a tracked human lifecycle breaks for AI-connected identities. Joiner-mover-leaver models assume a manager, an employment record, and an offboarding trigger. AI integrations created during a pilot may have none of those signals, so quarterly reviews certify nothing and remove nothing. The implication is that identity governance must stop assuming human-paced lifecycle events are universal.

Ephemeral adoption creates permanent identity debt when ownership is undefined. The article shows that AI tools can be connected by finance, marketing, HR, or operations without central approval, then left running after the original use case fades. That is not merely shadow IT. It is shadow identity accumulation, and the practitioner conclusion is that ownership assignment must precede scale, not follow it.

Complete NHI visibility is now a governance prerequisite for AI scale. The enterprise cannot defend least privilege, audit evidence, or revocation without knowing every AI-connected identity in scope. That means the identity programme must recognise department-created AI access as part of the governed estate, not as an exception. Practitioners should treat inventory completeness as the gate that makes AI adoption defensible.

NHI lifecycle control is becoming the shared language between AI security, IAM, and audit. The article aligns with the broader direction of frameworks that expect access to be identified, owned, reviewed, and revoked across all identity types. For practitioners, that means the future control set is not AI policy alone, but governed lifecycle management for every non-human identity that AI introduces.

From our research library:

What this signals

Shadow AI adoption is becoming a lifecycle problem before it becomes a model-risk problem. Once departments can connect AI tools directly to business systems, the governance challenge shifts to discovery, ownership, and revocation. Security teams should assume that every new integration can create a non-human identity that will outlive the pilot that introduced it.

Complete inventory is the control that turns AI governance from policy into evidence. Access review cycles, audit requests, and incident investigations all depend on being able to say what the AI-connected identity can reach and who is accountable for it. When that answer is missing, the programme is already behind regardless of how mature the written policy looks.


For practitioners

  • Build a complete AI-connected identity inventory Discover every AI tool, service account, OAuth app, token, bot, and delegated integration that can touch business systems, including department-owned deployments outside IT.
  • Assign named ownership to every non-human identity Record a responsible owner for each AI integration so access review, exception handling, and revocation do not depend on informal team memory.
  • Remove standing access from dormant AI integrations Identify AI-connected identities tied to pilots, experiments, or unused workflows and disable those that no longer serve a valid business purpose.
  • Shift certification to evidence-based access review Replace assumption-driven recertification with direct evidence of what each AI-connected identity can reach, who approved it, and when it was last validated.

Key takeaways

  • AI governance fails when organisations cannot inventory the non-human identities created by departmental AI integrations and shadow adoption.
  • The real risk is orphaned access that escapes human-centric lifecycle controls, not model behaviour alone.
  • Practitioners need complete discovery, named ownership, and evidence-based revocation before AI adoption can scale safely.

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 addresses the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01 — Improper OffboardingAI-connected identities persist after pilots end, creating orphaned access that is never removed.
NHI-05 — Overprivileged NHIThe article describes AI integrations receiving broad access to CRM and business systems.
NHI-09 — NHI ReuseDepartments repeatedly connect tools and credentials outside IT, creating duplicated unmanaged identities.
Recommendation — Apply NHI-01 by revoking AI-connected identities when their business purpose ends. Enforce NHI-05 by scoping AI-connected access to the minimum required system privileges. Reduce NHI-09 by consolidating repeated AI integrations into governed identity patterns.
NIST AI RMFGOVERN — AI Governance and AccountabilityThe article is fundamentally about governance accountability for AI-connected access.
Recommendation — Use GOVERN to define ownership and accountability for AI-related identity decisions.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe central control issue is whether AI identities have visible, appropriate permissions.
Recommendation — Apply PR.AA-05 to inventory and limit entitlements for AI-connected identities.
CIS Controls v8CIS-5 — Account ManagementThe article is about tracking and removing account-like identities created by AI tools.
Recommendation — Use CIS-5 to manage ownership, review, and removal of AI-connected accounts.

Key terms

  • Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
  • Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
  • Identity Inventory: Identity inventory is the process of discovering and recording every identity that can access systems or data. For NHIs, it includes owner, purpose, privilege scope, lifecycle status, and where the credential is used. Without inventory, governance, audit evidence, and incident response all become partial and unreliable.
  • Access Recertification: Access recertification is the periodic review of user or account permissions to confirm that access is still justified. It is useful, but it is not enough on its own because it reacts after entitlements already exist, which is why lifecycle governance must reduce the volume of exceptions before review time.

What's in the full article

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

  • How the Clarity non-human identity suite inventories service accounts, OAuth apps, AI agents, API tokens, and bots in one view
  • How ownership assignment and risk assessment are applied to specific NHIs after discovery
  • How the article frames board and examiner questions about AI-connected access
  • How the vendor positions continuous visibility as the basis for audit-ready identity governance

👉 The full Clarity Security article covers the visibility gap, lifecycle mismatch, and practical identity governance steps in more detail.

Deepen your knowledge

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