Inventory First: A Practical Way to Start an Agentic Identity Strategy

Before debating products, protocols, or future-state architectures, enterprises beginning an agentic identity journey should learn from people already working through the problem. I have been lucky to have had many such people help me with my own strategy. I would like to call out two in particular.

Sean O’Dell, in his post You Already Have the Pieces, Now Build It, argues that enterprises can secure AI agents by treating them as dynamic workloads and assembling existing standards, including SPIFFE, OAuth, transaction tokens, gateways, and shared security signals, into a coherent identity, authorization, and assurance architecture.

Phil Windley, in his Agentic AI and Dynamic Authorization series, makes two important observations. First is that authorization cannot sit at the edge as a one-time check; instead, it must be embedded in the agent’s decision loop. The other is that delegation in agentic systems must be explicit, structured, and bounded so that authority can narrow safely as agents delegate to subagents or external domains while preserving control, trust, and auditability across the full chain.

Both shaped the practical approach I set out below. That begins with inventory.

Inventory Is the Foundation

The first step in an agentic identity strategy is not selecting a platform. It is building an inventory of agents.

That may sound administrative, but everything else depends on it. An enterprise cannot assign an identity to an agent it does not know exists. It cannot define authority without understanding the agent’s purpose. It cannot write meaningful policy without knowing which tools the agent can invoke. It cannot monitor behavior without knowing which credentials, APIs, data sources, and runtimes belong to it. And it cannot revoke access during an incident if nobody knows where the agent runs or how it authenticates.

No inventory means no ownership. No ownership means no accountability. Without accountability, an agentic identity strategy is mostly an architecture diagram.

Agents are already arriving through SaaS platforms, developer tools, low-code environments, workflow systems, security automation, internal AI projects, and Model Context Protocol integrations. Some look like ordinary features until someone realizes they can select tools, call APIs, delegate work, or act without direct approval.

The first enterprise objective should therefore be simple: know which agents exist, who owns them, where they run, what they can reach, and how to stop them.

Build a Living System of Record

The inventory should connect each agent’s business purpose to its identity, authority, dependencies, and lifecycle.

Each production agent should have a unique identifier, business and technical owners, an accountable sponsor, a documented purpose, a risk tier, and an approved environment. The record should also capture its runtime, data access, tools, APIs, MCP servers, workload identities, service accounts, OAuth grants, tokens, secrets, approved actions, logging location, and revocation method.

This information drives every later control. Identity teams learn what identity must be issued. Authorization teams learn what policies are needed. Data governance learns which restrictions apply. The SOC learns what telemetry to monitor. Audit learns who is accountable. Incident responders learn what must be disabled.

The inventory is not an administrative byproduct. It is the seed of the agentic control plane.

Enterprises should not wait for a product that can discover every agent. Cloud inventories, CMDBs, application portfolios, gateways, CI/CD pipelines, endpoint telemetry, identity systems, PAM platforms, SIEM data, and procurement records can all contribute.

Start with known production agents, especially those that access sensitive data, change production, modify entitlements, use privileged credentials, communicate externally, or update systems of record. Manual registration will be necessary at first. Make it part of production onboarding and automate discovery progressively.

Start With Workload Identity

Once an agent has been inventoried, the next question is how it should be identified.

A useful starting point is to treat agents as workloads. Agents can pursue broad goals, select actions dynamically, cross trust boundaries, and invoke subagents, so their risk profile stretches traditional non-human identity assumptions. Even so, workload identity is much stronger than hiding an agent behind a generic service account. The claim is not that an agent is merely a workload; it is that workload identity is the most mature primitive available today, and a far better foundation than a shared service account while agent-specific models mature.

An agent should have its own attributable identity tied to its inventory record, owner, purpose, runtime, environment, permitted tools, risk tier, delegation boundaries, and lifecycle state. The identity should represent the agent as an enterprise actor, not merely the server on which it executes.

Use SPIFFE IDs and SVIDs

SPIFFE offers a compelling model for workload identity.

A SPIFFE ID is the identifier assigned to the workload. It is represented as a URI within a defined trust domain. An SVID, or SPIFFE Verifiable Identity Document, is the cryptographic credential the workload uses to prove that it is entitled to that SPIFFE ID.

In simple terms, the SPIFFE ID says who the agent is. The SVID proves that identity. The inventory explains what the identity represents. Authorization policy decides what the agent may do.

An enterprise might use an identifier such as:

spiffe://enterprise.example/agents/security/alert-triage

The identifier should not attempt to encode every authorization decision. Policy still needs to consider delegated purpose, requested action, target resource, data classification, workflow state, risk signals, and approvals.

Every SPIFFE ID should map back to an authoritative inventory record. A cryptographically valid identity is not automatically an authorized identity. The enterprise still needs to know whether the agent is active, who owns it, where it may run, and what it may do.

SPIFFE establishes workload identity. The inventory supplies governance context. Authorization connects the two.

Preserve Dual Attribution

Treating an agent as a workload does not eliminate the need to identify the person or process behind its actions.

Enterprises should preserve dual attribution: the human, application, workflow, or business process that initiated the work, and the agent that performed it.

An audit trail should show who initiated the task, which agent accepted it, what authority was delegated, which tool was invoked, which policy governed the action, and which resource was affected. Workload identity tells us which agent acted. Delegation tells us on whose behalf it acted and why.

This is an important distinction because a generic service account rarely tells the whole story. It may authenticate the software, but it does not necessarily explain why the action occurred, who requested it, or what limits were placed on the agent.

Assemble What You Already Have

One of the most useful observations in Sean O’Dell’s work is that agentic identity is not only a standards gap. It is also an assembly gap.

Enterprises already operate many of the necessary components. The challenge is connecting them into a coherent model.

CMDB and application portfolio systems can provide the initial inventory. Workload identity and PKI can issue and validate agent identities. OAuth can provide short-lived, narrowly scoped access tokens. API and MCP gateways, service meshes, and tool brokers can become enforcement points. Existing policy engines can evaluate identity, delegation, resource, risk, and workflow context.

Identity governance platforms can assign owners and support reviews. PAM and secrets management can protect credentials. SIEM and ITDR capabilities can correlate the initiator, agent identity, delegation record, tool invocation, authorization decision, target resource, and result. CI/CD pipelines can prevent promotion into production unless ownership, identity, logging, and revocation requirements have been satisfied.

Not every existing system is agent-ready, but most enterprises already have many of the building blocks and can extend them instead of waiting for a completely new stack.

Put Authorization Inside the Agent Loop

Inventory and identity are only the beginning. Agents are given goals rather than single transactions. They may gather information, revise plans, call several tools, and delegate work. A one-time authorization decision at login or onboarding is insufficient.

Authorization should be evaluated before each meaningful action, especially when an agent accesses sensitive data, invokes a privileged tool, changes production, modifies entitlements, exports information, sends an external communication, accesses credentials, or performs an irreversible action.

A practical control loop begins when a person, application, or workflow initiates a goal. The agent and its workload identity are resolved through the inventory. A bounded delegation record is created. The agent plans within known constraints. Sensitive tool calls are intercepted by an enforcement point, which asks a policy engine to evaluate identity, delegation, tool, resource, context, risk, and workflow state.

The result may be permit, deny, constrain, rate-limit, escalate, or require approval. The decision and action are recorded, and delegated authority expires when the task ends or is revoked.

The model may be told what boundaries apply, but it should not enforce them.

Planning can be probabilistic. Enforcement must be deterministic.

Make Delegation Explicit

An agent should not automatically inherit every permission held by the user who invoked it.

Delegation should define who granted authority, which agent received it, what task is being performed, which actions and tools are allowed, which resources may be affected, how long the authority lasts, whether human approval is required, whether subdelegation is permitted, and how the authority can be revoked.

These facts should be structured, policy-evaluable data rather than information hidden inside a prompt.

Impersonation says the agent is effectively the user. Delegation says the agent has limited authority for a defined purpose and period.

Agentic identity should be built around delegation.

This becomes even more important when agents invoke subagents. A subagent should normally receive narrower authority than the parent agent, not inherit everything available to it. When delegation crosses into a vendor platform or another external trust domain, the enterprise will also need stronger assurance, logging, contractual commitments, and restrictions on onward delegation.

Begin With a Minimum Viable Architecture

A first implementation does not need to solve every future agentic pattern.

A practical minimum viable architecture can begin with:

1. An inventory containing the agent’s owner, purpose, tools, data access, and risk tier.
2. A SPIFFE ID identifying the agent workload.
3. An SVID providing cryptographic proof of that identity.
4. A bounded delegation record describing the authority granted for the task.
5. An API or MCP gateway intercepting sensitive tool calls.
6. An existing policy engine evaluating the action.
7. Short-lived OAuth tokens or brokered credentials.
8. SIEM logging that records the identity, decision, action, and result.
9. A tested method for revoking the agent’s authority.

Choose useful but constrained pilots: a read-only knowledge agent, a security triage agent that cannot contain systems, a coding agent that cannot merge or deploy, or a data agent that cannot export regulated information. Use them to test discovery, ownership, workload identity, bounded delegation, policy enforcement, logging, and revocation.

The objective of these pilots is not merely to prove that the agent works. It is to prove that the enterprise can govern it.

Start by Assembling

Agentic identity creates genuinely new challenges, but enterprises are not starting from nothing. They already have inventories, identity platforms, gateways, policy engines, privileged access and secrets management, CI/CD, and incident response.

The first task is to find the agents and connect them to those controls.

From there, treat agents as attributable workloads. Give them SPIFFE IDs and use SVIDs to provide cryptographic proof. Preserve the connection to the human or process that initiated the work. Make delegation explicit. Enforce policy at the tool boundary. Record the full decision chain. Design revocation from the beginning.

The standards and products will continue to evolve. Enterprises should follow that work, but they should not wait before starting.

You probably already have many of the pieces. First, build the inventory. Then start assembling.

KuppingerCole Analysts perspective: This post starts from workload identity. Martin Kuppinger cautions against that framing. Agents aren't just another non-human identity, he argues, given their varying autonomy, the distinct differences between invocation, delegation, and impersonation, and the entity-vs-instance nature of "ephemeral" agents.

 Watch this Analyst Chat for the full argument.