Non-human identity governance is breaking under agentic AI sprawl

At a glance

What this is: This is an analysis of non-human identity governance and how AI agents intensify the ownership, scope, and lifecycle problems already present in service accounts and tokens.

Why it matters: It matters because IAM, PAM, and IGA teams now have to govern software identities that authenticate, act, and delegate without human login patterns or review triggers.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read WitnessAI's analysis of non-human identity and AI agent governance

Context

Non-human identity is the governance problem that appears when software, not a person, authenticates and acts inside enterprise systems. The primary issue is not just volume, but the absence of human lifecycle triggers, named accountability, and usable oversight for identities that can reach sensitive data and perform actions on their own. For identity programmes already stretched across IAM, PAM, IGA, and secrets management, that gap becomes harder to ignore as AI agent identity joins the estate.

WitnessAI’s article frames the problem as a combined lifecycle and accountability challenge: service accounts, API keys, OAuth tokens, workload identities, and AI agents all need ownership, scoped access, and revocation discipline. That framing is consistent with current NHI practice, but it becomes more urgent when autonomous agents inherit permissions, invoke tools, and outpace periodic review cycles.

The practical takeaway for practitioners is that NHI governance can no longer sit in a separate corner of infrastructure or DevOps. Discovery, right-sizing, runtime policy, and decommissioning need to be governed as one programme across machine identities and agentic AI identities, with human accountability attached to every consequential action.

Key questions

Q: What problem does ownership attribution solve for service accounts and API keys?

A: It closes the gap between exposure detection and accountable remediation. Many organisations can find the secret, but not the human who introduced it, maintains it, or can safely replace it. Ownership attribution gives security teams a practical way to assign action without relying on informal knowledge that disappears during staff changes.

Q: Why do non-human identities increase zero trust risk?

A: Non-human identities increase zero trust risk because zero trust assumes every access request can be verified in context, but machine credentials are often distributed across code, pipelines, and third-party integrations. If those credentials are hard to discover or rotate, continuous verification becomes incomplete. Zero trust for machines requires identity inventory, short-lived credentials, and confirmed revocation.

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Who should be accountable when an AI agent causes a security incident?

A: Accountability should sit with the human owner, platform team, or business function that granted and operated the agent. The identity may act independently, but governance cannot detach responsibility from the delegation chain. Programs should define ownership, escalation, and remediation paths before deployment so responsibility is clear when the agent's behaviour changes.

Technical breakdown

What makes non-human identity different from human identity governance?

A non-human identity is not tied to an employee record, a login session, or a human lifecycle event. It is usually bound to code, a workload, a token, or a certificate that can authenticate without a person present. That difference matters because access review models built for joiner-mover-leaver processes do not naturally catch drift in service accounts, API keys, OAuth grants, or workload roles. Most NHIs also cannot complete MFA, so teams compensate with scoped credentials, ownership, and auditability. The governance problem is therefore structural, not just operational.

Practical implication: Map each NHI type to its own lifecycle trigger and review owner instead of reusing human access review cadences.

Why do AI agents expand the NHI attack surface?

AI agents change the identity problem because they can make runtime decisions, call tools, and delegate work without a fixed script. That means their effective privilege surface is the union of every credential, tool, and downstream system they can reach during execution. When an agent inherits access from a parent system, the audit trail may name the credential but not the accountable person behind the action. Agents also create more identity objects as workflows branch, which turns a static inventory problem into a moving target. The result is not just more NHIs, but more volatile NHIs.

Practical implication: Treat agent access as dynamic and task-scoped, with runtime policy checks on every tool invocation and delegation path.

How does lifecycle enforcement reduce NHI risk?

Lifecycle control is the only practical way to stop NHI accumulation from becoming permanent exposure. Discovery creates the inventory, ownership establishes accountability, right-sizing limits blast radius, runtime enforcement prevents out-of-policy action, and scheduled decommissioning closes credentials that no longer have a purpose. Without all five, identities tend to survive the work they were created for. This is especially important for long-lived keys, roles reused across workloads, and agents that inherit access from the systems that spawn them. The mechanism is simple: every live credential should have a purpose, an owner, and an end date.

Practical implication: Build decommissioning and revocation into the same control plane that issues and monitors NHI access.

Threat narrative

Attacker objective: The attacker aims to abuse ungoverned machine access to expand reach, evade accountability, and extract or alter sensitive data at speed.

1. Entry occurs when service account credentials, API keys, or OAuth tokens are issued or inherited without sufficient ownership and scoping.
2. Escalation follows when the same credential is reused across workloads, tools, or agent actions, widening the reachable systems and data.
3. Impact occurs when leaked or over-privileged non-human access is used to move faster than human review cycles and reach sensitive systems or data.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.

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

NHI Mgmt Group analysis

Non-human identity governance fails when ownership is implicit rather than explicit. Service accounts, tokens, and workload identities do not carry human lifecycle signals by default, so orphaned access is the predictable outcome when ownership is left in spreadsheets or tribal knowledge. That creates a control gap across IAM, PAM, and IGA because nobody can answer who is responsible for revocation, scope changes, or exception handling. The practitioner conclusion is that every live NHI needs an accountable human owner, not just a technical system of record.

AI agent identity creates identity blast radius, not just identity volume. The important shift is not that there are more identities, but that a single agent can combine tools, credentials, and delegated actions in ways a static entitlement model never anticipated. That expands the effective privilege surface into a union of runtime choices, downstream tools, and recursive delegation. Practitioners should therefore assess agent control by reachable actions, not by the nominal role alone.

Runtime policy is now part of identity governance, not a separate security layer. Periodic reviews can only certify what still exists at review time, while agents and ephemeral workloads can act, branch, and close out before a human process catches up. That means pre-execution inspection, response inspection, and approval gates above defined impact thresholds are governance controls, not optional add-ons. The practitioner conclusion is that review cadences must be paired with runtime enforcement or they will miss the event entirely.

Named ownership and scheduled decommissioning are the two controls that turn NHI from sprawl into inventory. Discovery without offboarding just creates a better list of stale identities, while offboarding without ownership creates unowned exceptions that never close. WitnessAI’s article is correct to treat lifecycle controls as a single model because the same issue appears in service accounts, workload identities, and AI agents. The practitioner conclusion is to govern identity retirement as deliberately as identity issuance.

OWASP’s NHI risk lens is increasingly the right starting point for this category. The article’s emphasis on offboarding, secret leakage, and machine credential misuse aligns with the fact that NHI failure is usually lifecycle failure, not just authentication failure. That matters because the controls teams need are the ones that reduce exposure windows, not only the ones that detect misuse after the fact. The practitioner conclusion is to map current governance gaps to the NHI risk class that actually exists, rather than treating all software identities as interchangeable.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to our Ultimate Guide to NHIs.
• For a broader breakdown of breach patterns and lifecycle failure modes, see 52 NHI Breaches Analysis and compare the offboarding gap with your own revocation process.

What this signals

Identity blast radius will become the most useful planning concept for NHI teams. Once agents can inherit access, call tools, and branch into sub-agents, the unit of governance is no longer the credential alone. It is the full set of systems, data, and actions the identity can reach during execution, which is why runtime scoping will matter more than static entitlements.

With 91.6% of secrets still valid five days after notification, remediation speed is clearly out of step with exposure windows. That means NHI programmes should measure revocation latency, not just inventory completeness, and use lifecycle metrics as an operational signal rather than a reporting exercise.

As AI agent identity matures, practitioners should expect a stronger link between NHI governance and model governance. The right operating model will combine ownership, runtime policy, and decommissioning with external guidance such as the NIST AI Risk Management Framework and SPIFFE workload identity specification where workload trust and runtime attestation are part of the same control story.

For practitioners

• Inventory every active non-human identity Scan application installs, OAuth grants, API keys, agent frameworks, and workload roles together so you can see what is authenticating in production. Treat undocumented identities as governance exceptions until an owner and purpose are assigned.
• Assign a named human owner to each identity Bind every service account, token, workload role, and agent to a person who can approve scope changes, explain purpose, and authorise revocation. If ownership moved when the creator left, the identity should be reassigned before it stays live.
• Right-size privileges to actual runtime need Review whether the identity can reach systems it never legitimately needs, especially when one role is reused across multiple workloads or when an agent can invoke external tools. Reduce the reachable systems and data before the next deployment cycle.
• Enforce policy before and after execution Use pre-execution checks for prompts and tool calls, then inspect outputs before they move into tickets, records, or downstream agents. Require human approval above a defined impact threshold so risky actions do not slip through review gaps.
• Schedule decommissioning and revocation as a lifecycle control Set an end date for every NHI and automate revocation when the workload, integration, or agent is retired. Closing live credentials is what prevents old access from becoming permanent attack surface.

Key takeaways

• Non-human identity governance fails most often at ownership, offboarding, and scope control rather than at simple authentication.
• AI agents turn NHI sprawl into an identity blast radius problem because they can combine credentials, tools, and delegation at runtime.
• The practical control shift is from periodic review alone to continuous lifecycle governance with runtime enforcement and scheduled revocation.

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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Runtime Policy Enforcement: Runtime policy enforcement evaluates a request at the moment it is executed instead of relying only on preconfigured permissions. For AI agents, this allows decisions to reflect current context, target sensitivity, and behavioural signals rather than static assumptions.
• Lifecycle Decommissioning: Lifecycle decommissioning is the controlled removal of an identity when its purpose ends or its trust context changes. For non-human identities, this includes revoking keys, retiring certificates, and removing downstream dependencies that still accept the old credential. Without it, stale trust persists as hidden risk.

What's in the full article

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

• The article expands on how service accounts, OAuth tokens, workload identities, and AI agents differ in practice.
• It lays out the five lifecycle controls in more operational depth, including how to apply them across AI agents.
• It explains how named ownership and audit trails support compliance when agents act without a person present.
• It adds WitnessAI's framing of runtime enforcement across prompts, tool calls, and outputs.

👉 WitnessAI's full article covers the lifecycle model, agent risk, and accountability detail behind this analysis.

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 IAM programme, it is worth exploring.