Non-Human Identity Management: The Full Lifecycle for AI Agents

A non-human identity is a credential that belongs to software rather than a person. Service accounts, API keys, certificates, OAuth grants, workload identities, and AI agent credentials all qualify. For the underlying definition and how NHIs relate to machine identities generally, see what machine identity is and what managing it involves.

Non-human identity management is the practice of governing those credentials across their whole life, from the moment they are created to the moment they are revoked. In a mature program, every NHI has a known purpose, a named owner, permissions scoped to that purpose, and a defined end.

AI agents are non-human identities, but they are a different class from everything that came before, and the difference is worth stating precisely because it determines which controls still work.

Every earlier NHI is deterministic. A service account executes the same job the same way every night. Its permissions describe its behavior almost exactly, so reviewing the grants tells you what the identity does.

An AI agent is probabilistic. It receives a goal and decides its own actions at runtime, composing sequences nobody specified in advance. Its permissions describe the outer boundary of what it could do, and nothing in the grant list tells you what it will do.

That single property is why NHI programs built for service accounts produce misleading results when pointed at agents. The review still runs. The answer it gives no longer means what it used to mean.

Stage 1: Creation, where sprawl begins

A service account is created by a platform team through a pipeline, usually with a ticket and an approval attached. However imperfect, there is a path, and the path produces a record.

An agent is created by an employee in a web console in about ninety seconds. There is no ticket, no approval, and no record outside the platform it was built on. Multiply that across every department with access to an agent-building tool and the population grows faster than any quarterly inventory can track.

This is NHI sprawl, and its defining property is not volume but invisibility. The problem is not that there are many agents. It is that the list of them lives in several different platform consoles, none of which talks to your identity system, and the list changes daily.

Underneath the agents sit their connections. Every MCP server an agent uses is itself a credentialed connection to a real system. Local MCP servers run as a subprocess with no port and no hostname, so they never appear in a network scan or an asset inventory, and they are added and removed between audits.

Stage 2: Entitlement, where inheritance replaces provisioning

Provisioning a service account means deciding what it needs. Somebody thinks about the job and grants the minimum that makes it work.

Agents skip that step almost universally. An agent runs on its creator's credentials, which means its reach equals a person's reach. That person accumulated access over years, across projects, for reasons unrelated to this agent. Nobody decided the agent should have all of it; it simply arrived that way.

The result is that agent permissions are not a deliberate grant at all. They are a copy of somebody's accumulated history.

Stage 3: Operation, where privilege escalation happens without an exploit

This is where the risk becomes concrete, and where the board-level version of the story usually lives.

Agent privilege escalation does not require a vulnerability. It requires only that an agent holds access somebody else does not, and that the somebody else can prompt it. A person with no access to a system asks an agent whose credential does have access, and the data comes back. No control was bypassed, so no control fires. The access was inherited and then borrowed.

This is the machine insider pattern. Access reviews cannot see it, because they examine who holds permissions, not who can reach an identity that holds them. The person in the escalation path holds nothing unusual. They just know which agent to ask.

Three operational patterns make it worse:

Over-permissioning by default. Because entitlement is inherited rather than scoped, most agents hold far more than their workflow requires. For how to right-size this without breaking the workflow, see reducing AI agent over-privilege.

Fixed-credential connections. Some agent platforms connect to systems using the builder's credentials for every user of the agent, rather than the credentials of the person invoking it. Every user of that agent then operates at the builder's permission level.

Compounding reach across connections. An agent's authority is the union of everything it can reach in a session. A read-only data connection is unremarkable. An outbound messaging connection is unremarkable. An agent holding both has a data movement path that neither connection granted.

Stage 4: Change, where drift goes unobserved

Human access is re-examined when someone changes role. Agents have no equivalent trigger. Their entitlements drift as their creator's access grows, as connected platforms add capabilities, and as new MCP servers are attached to extend a workflow.

None of those events produce a review, because none of them look like an identity change. The agent's configuration did not change. Its reach did.

This is the gap between theoretical configuration and effective authority. The config page records what was set up. The credential records what can be reached now. Those answers diverge continuously, and only one of them describes your actual exposure.

Stage 5: Retirement, where orphans accumulate

Offboarding is built around the human. The account is disabled, sessions revoked, devices collected. The agents that person built keep running.

An orphaned agent is one whose creator has left, holding a credential tied to a departed employee, executing on a schedule with nobody accountable for whether it should still exist. Nobody retires it, because retiring an agent risks breaking a workflow nobody can identify, while leaving it running has no visible cost. The rational local decision is always to leave it.

Unsanctioned agents are the adjacent case: agents built by employees still present, but never reviewed by anyone. Both categories share the same root, which is that agent creation never produced a record anybody owns.

Five controls, mapped to the five stages.

Inventory continuously, across platforms. Cover every AI platform in use, not one at a time, and collect from runtime activity rather than periodic export. A population that changes daily cannot be governed from a quarterly snapshot.

Establish creator and owner for every agent. This is the single highest-leverage control, because it fixes the root cause of the retirement and scoping failures at once. An agent with a named owner can be scoped correctly and retired safely. An agent without one cannot be either.

Resolve effective access rather than configuration. For each agent and each connection, determine what the credential actually reaches inside the connected system today. This is what converts an inventory into a risk picture.

Score combinations, not individual grants. Rank by what one agent can reach across everything available to it in a session, and flag the pairings that create a path from sensitive data to an external destination.

Tie agent lifecycle to human lifecycle. When a person is offboarded, their agents should surface for a decision rather than continuing silently. This requires knowing the creator, which is why ownership comes first.

Obsidian builds this from runtime activity across connected AI platforms: an inventory of agents and the MCP servers they reach, the creator behind each one, the effective access each holds inside your SaaS applications, and scoring on the combinations that widen blast radius. Runtime enforcement is available today for Claude and Microsoft Copilot; other platforms are covered for discovery and governance.

Non-human identity management for AI agents requires a different governance model than the one built for service accounts and certificates. The principles are the same. The mechanisms must be rebuilt for autonomous, probabilistic systems.

Unified NHI governance across the full identity spectrum: boards and security leadership often believe access is under control because reviews run on schedule. The real risk lives in lingering entitlements, especially for non-human identities that were never included in the review cycle. Effective non-human identity management treats human identities, service accounts, certificates, API keys, and AI agents as a single governance domain. Separating them creates coverage gaps that attackers exploit.

Inventory as the prerequisite for everything else: you cannot govern what you cannot see. A complete AI agent inventory answers the questions security teams currently cannot: which agents exist, which platforms they run on, who created them, what credentials they hold, and what data they can actually access. That inventory must span sanctioned and unsanctioned agents across every platform in the environment. A single pane of glass across Microsoft Copilot Studio, Salesforce Agentforce, Amazon Bedrock, Google Vertex AI, n8n, and ChatGPT Enterprise is the foundation of any NHI program that includes agents.

Named ownership tied to identity events: every agent must have a named owner. That ownership must be enforced through the identity lifecycle. When an owner's account is disabled, the agent must be flagged immediately, reviewed, and either reassigned or decommissioned. Every agent should carry its own unique identity from the moment it goes into production, and every agent action should be traceable back to a human decision.

Least privilege enforced at the agent level: agents should receive task-scoped access, not standing privileges. An agent built to summarize customer support tickets does not need write access to the CRM or read access to financial records. Enforcing least privilege for AI agents requires understanding effective authority, not just reviewing configuration.

Runtime monitoring as the control layer: configuration review tells you what agents are set up to do. Runtime monitoring tells you what they actually did, which credentials they used, which data they accessed, and whether any of that was policy-aligned. For probabilistic agents, deterministic guardrails applied at runtime are the only reliable enforcement mechanism. Reviewing logs after an agent has completed an action chain is ghost chasing. Seeing the chain as it executes is runtime truth.

Know what your agents can actually do. Obsidian's AI agent risk assessment maps effective authority across every platform in your environment and surfaces orphaned agents, maker mode configurations, and toxic combinations you cannot see with configuration review alone. Start your assessment

A non-human identity has a lifecycle whether or not anyone manages it. Four stages, and most programs only instrument the first.

Creation

An agent is built and granted credentials, usually by a developer, usually without a ticket. The gap to close is registration at creation rather than discovery months later.

Accumulation

Scopes grow. A grant approved for one integration picks up permissions as the product ships features, and nothing revokes what stopped being needed. This is where privilege escalation lives, and it happens without an attacker.

Drift

The identity keeps working while its context changes. Its owner moves teams or leaves. The project ends. The agent keeps its access because nothing connects a human departure to a non-human credential.

Orphaning

Nobody owns it, nobody reviews it, and it still authenticates. Orphaned machine identities are the most common finding in any first inventory and the easiest to remove once visible.

Sprawl is what this looks like at scale: identity count growing faster than the review process, with no stage of the lifecycle owned by a named team.