Machine Identity and Inventory Management for Production AI Agents

Production AI agent security begins with enumeration and durable, scoped identities. Runtime autonomy, tool access, and delegation make agents useful, but also make static service-account models insufficient. A rigorous identity and inventory practice must establish which agents exist, what each may do, and who remains accountable for its actions.

Why AI agents cannot be secured using the identity frameworks built for service accounts

The Microsoft legacy OAuth incident showed how a forgotten non-human identity with elevated rights and no MFA could become the front door for a nation-state actor. Giving a production AI agent a shared admin token creates the same exposure and adds autonomous execution. The credential now authorizes an actor that decides at runtime which tools to call, which data to read, and which actions to take. Its behavior is not fixed in advance.

A service account is governable through its predictable scope, behavior, and callers. An agent instead receives a goal and works out how to accomplish it, while a successful prompt injection can rewrite its intent mid-session. Treating these as equivalent identity subjects is an architectural category error. The same access grant has different consequences when its holder selects its own sequence of actions.

Saviynt’s 2026 identity security trends notes that agents often have more administrative privileges than the humans who created them, but do not have the lifecycle controls used for human accounts. That asymmetry increases the cost of misclassification. When organizations cannot identify their active agents or explain their decisions, the failure extends beyond monitoring. The identity model has not captured the actor it is supposed to govern.

How the agentic operational profile expands the identity attack surface beyond what legacy IAM addresses

Kurtz & Krawiecka’s 2026 Machine Identity Governance Taxonomy identifies four operational capabilities that distinguish agents from static machine identities, including tool invocation, multi-step autonomous execution, agent-to-agent delegation, and environmental interaction with persistent memory [1]. Each creates a separate identity governance surface. A tool call is an authenticated action under the agent’s identity, so a shared API key prevents reliable attribution to an individual agent. It also obscures whether the original human principal authorized that call.

Individually permitted steps can combine into an outcome that no single access decision approved. Kurtz & Krawiecka call this the behavioral trajectory challenge. Legacy IAM evaluates access at a point in time rather than the aggregate effect of a sequence, leaving a gap between permission to perform each step and authority to produce the final result.

Delegation extends that gap across multiple actors. A supervisor may pass instructions and credentials to subagents through relationships that are not cryptographically verified, making each handoff a potential privilege escalation point. Persistent memory extends the risk across time instead. When agents keep context and effective access across sessions, gradual corruption or objective drift can develop in ways that a review of one session may miss.

MCP connections add a machine-to-machine access layer to these surfaces. Saviynt names MCP tokens, credentials, and access rules as key targets because they let agents work within critical systems at machine speed. Visibility into those connections is often absent. Kurtz & Krawiecka document that Silk Typhoon and Salt Typhoon have already operationalized ungoverned machine credentials as espionage vectors against critical infrastructure. The agent-specific concern is that manipulated intent can exercise such authority through tools, memory, and delegation without an adequately governed identity constraining it.

Why the inventory problem comes before the identity problem

An unknown agent cannot receive a meaningful access review, a justified privilege scope, or a reliable incident response. Enumeration must therefore precede effective identity design. Gravitee’s State of AI Agent Security 2026, published in April 2026 and covering 750 senior technology leaders in the UK and US, found that the enterprise agent estate had roughly doubled in a single quarter while security coverage had barely moved. Deployment velocity was outpacing governance implementation, increasing the absolute number of unmonitored agents.

Discovery is difficult because creation is distributed. Agents emerge through cloud consoles, CI/CD pipelines, SaaS integrations, and agent frameworks, with no default system of record spanning them all. Delay therefore enlarges the blind spot. Orphaned agents make that gap especially dangerous when they no longer have an owner but their credentials and tool access still work.

Teams may argue that identity controls can come first, with inventory emerging as a byproduct. That reverses the dependency. Without knowing what an agent does and what it touches, the team lacks the basis for defining its scope and risks granting broad access by default. Inventory without identity is a list. Identity without inventory is a guess.

What a governed agent registry actually contains

A production registry must record an agent’s identity, operational envelope, trust relationships, ownership, and lifecycle state. It is not a directory of names. The taxonomy specifies an authoritative AI Identity Registry with metadata covering ownership, business purpose, access grants, associated systems, and scheduled review. For production agents, that record must describe both the executing actor and the dependencies through which it acts.

Each entry requires a unique, cryptographically verifiable agent identifier and a named human owner accountable for its existence and behavior. A human-assigned label is not sufficient. Purpose and authorized workflow scope must say what the agent may do clearly enough for a reviewer to check for drift.

The access record must enumerate every authorized API, database, memory store, vector store, plugin, and external provider. It must also list every token, key, and certificate the agent holds, with its issuance date and expiry. MCP connections belong here as governed access paths. Recording only the agent process leaves out the machine-to-machine permissions that let it reach critical systems, so the registry must cover the full dependency stack.

Trust records must map the users, orchestration layers, tool execution layers, and downstream agents with which the agent may interact. If the agent spawns subagents or passes credentials, the registry must explicitly record those delegation relationships. The trust map shows which interactions are allowed, while the delegation chain shows how authority passes through them.

Each record must also identify whether the agent is active, dormant, pending retirement, or deprovisioned, with a dated review cadence. Retirement must have an operational consequence. When an agent or workflow is no longer needed, the registry should trigger credential revocation and access removal rather than rely on someone remembering to deprovision it. Continuous maintenance makes the registry a control surface for access reviews and retirement.

The five properties a durable agent identity must have

The AGENT framework formalizes five required properties, which are Attest, Grant, Enclose, Notarize, and Terminate. It grew out of work with AI-native SaaS teams getting ready for SOC 2, ISO 42001, and enterprise procurement. These properties turn a registry entry into an enforceable identity. These properties enable security operations to distinguish an agent, constrain its actions, reconstruct its authority, and end its access.

Attest requires a unique, cryptographically verifiable identity tied to a human owner. Without it, agents become indistinguishable in logs and vulnerable to impersonation. SPIFFE, the Secure Production Identity Framework for Everyone, is a CNCF project and the open standard underpinning this control.

Grant requires just-in-time, short-lived credentials scoped to each task and never shared across agents or sessions. Standing access is the opposite design. A credential that remains usable whenever it is presented gives an attacker authority beyond the task that justified its issuance. Purpose-bound credentials valid for minutes rather than months, with automatic revocation when the task completes, shift the model from granting persistent access to authorizing actions.

Enclose requires a sandbox with explicit allow-lists for tools, data, and outbound calls. Those limits come from the registry’s authorized workflow scope. Anything outside the allow-list is denied by default, making the recorded purpose an enforceable boundary.

Notarize requires every action to be logged with a delegation chain attributable to a human principal. Detection alone cannot show who authorized an outcome. The chain must make it possible to trace the decisions that caused it, including authority passed between agents.

Terminate requires automatic deprovisioning at the end of the lifecycle, with the registry triggering revocation. No manual step should preserve a zombie identity. Shared credentials would undermine this individual control just as shared passwords do for users, destroying attribution and making the reach of a compromise impossible to bound.

How trust boundaries and delegation chains must be designed in multi-agent systems

A multi-agent system cannot treat authorization of its orchestrator as authorization of every downstream action. Authority must be verified at each hop. The taxonomy identifies agent-to-agent delegation as an emerging governance surface because these relationships convey real access authority across organizational and trust boundaries, often without the cryptographically verifiable accountability its controls require. A human’s approval of the originating task does not remove those boundaries.

The practical failure begins when an orchestrator holds elevated privileges and passes instructions and credentials to a subordinate. If the chain is not verified, a compromised intermediate agent can pass fraudulent instructions downstream while appearing to act under a legitimate principal. Prompt injection can enter through that intermediate agent’s context. Without verification in the identity architecture, the resulting instruction can propagate beyond the manipulated agent as an authorized command.

To constrain that propagation, each agent must receive credentials limited to its assigned subtask. Subagents must not inherit the orchestrator’s full credential set. The trust map establishes permitted relationships, while verification at the handoff establishes whether the authority being exercised is legitimate. Notarize complements that enforcement by recording which agent acted, under whose authority, and where legitimate authorization broke.

These boundaries must also survive changes to the system. Tightening one agent’s credential scope can break downstream dependencies that are invisible when the agent is considered alone. Continuous security verification must prove that approved workflows still pass after a change to identity or scope. Running the full workflow shows how decisions about one agent’s privileges affect its operation, without making broader access the default fix.

What an operational lifecycle for agent identities requires beyond initial provisioning

The highest-risk period begins after an identity is created, when authorized scope drifts from behavior, an owner leaves, or a purpose ends while credentials remain valid. Initial provisioning does not settle these conditions. Agent identities require joiner-mover-leaver handling equivalent to human identity governance, with creation for a defined purpose, adjustment when that purpose changes, and deprovisioning when the workload retires. Named ownership and a substantive review cycle must persist throughout.

An access reviewer must understand the agent’s tools, data access, and delegation relationships to judge whether it still needs the permissions it has. Recognizing a name is not certification. Periodic comparison of authorized scope with observed behavior is necessary because agents can accumulate effective access across sessions and tool calls, allowing entitlement creep to remain hidden behind an unchanged purpose field.

Short-lived, task-scoped credentials reduce much of the exposure by design, but the registry must still track clear rotation schedules for long-lived certificates and external-provider API keys. Rotation cadence must reflect privilege level. Saviynt recommends dynamic privilege enforcement and continuous monitoring for autonomous workflows, while automatic retirement must revoke credentials and remove access when the workflow ends.

Changes to safeguards require evidence before release. A tightened scope, new tool restriction, or updated credential must be verified against approved workflows because a control that breaks legitimate work is vulnerable to removal under operational pressure. An unverified change may instead fail quietly in production. The verification record must therefore remain connected to the identity and scope changes it evaluates.

ISACA’s 2026 white paper requires threat modeling each agent workflow, including memory, tool calls, human approvals, tenant boundaries, and privileged actions. That workflow model gives ongoing verification the context it needs after the initial design. Approved workflows must be verified after each change, with the verification record serving as the artifact a release approver signs.