You Already Have the Pieces. Now Build It. | The Identity Underground

Join NowApply Now

Identity in Depth

You Already Have the Pieces. Now Build It.<br>Stitching existing standards into end-to-end assurance for agentic identity

Sean (O’Dentity) O'DellJune 4, 2026CVS Health<br>ᐧDistinguished Engineer, Identity and Security

The problem most people talk about and companies are chasing to try to wrap their arms around<br>AI agents are being deployed at scale across enterprise environments right now. They're calling APIs, reading data, executing workflows, making decisions - often autonomously, without a human in the loop, and almost universally without a coherent identity security model underpinning any of it.<br>This isn't a tooling gap. It isn't a standards gap. It's an assembly gap.<br>The protocols required to build end-to-end identity assurance for non-human workloads -agents, services, containers, pipelines - already exist. SPIFFE. OAuth 2.1. Transaction Tokens. Shared Signals Framework. OpenID Federation. OAuth ClientID Metadata. They were built, in many cases, precisely because the industry anticipated this moment.<br>What doesn't exist yet is a documented, opinionated reference architecture that shows how these pieces connect into a coherent trust fabric for agentic systems.<br>This post is an attempt to start building that.

Framing the problem: what makes agentic identity different<br>Before diving into the stack, it's worth being precise about why identity matters for agents. Agents are workloads, but with a risk profile that strains every assumption from which the traditional NHI model was built.<br>Agents are workloads with intent and broad missions.<br>A legacy service account calls a database with a constrained purpose.<br>An agent is handed a mission, "resolve this customer ticket," "reconcile these invoices," "investigate this alert", and decides at inference time which APIs or tools to call, in what order, based on reasoning that didn't exist at deploy time. The action surface is dynamic and nondeterministic and context-dependent in a way static NHI patterns weren't designed to handle.<br>Agents operate across trust boundaries. A single agent workflow routinely spans internal services, third-party APIs, MCP servers, and other agents - each in different trust domains, each with different authorization models. Cross-domain access isn't an edge case for agents; it's the baseline...which is why interoperability and federation matter (more to come on this).<br>Agents are ephemeral and instantiated at scale.<br>You don't have one agent. You have instances that are continuously changing: spinning up, fanning out, terminating, potentially with different versions, configurations, mission/task at hand and operational context. Identity needs to travel with the instance, not just the type and it has to come and go at the rate the instances do.<br>Agents are high-value targets. An agent with ambient credentials or inherited permissions is essentially a privileged insider with no audit trail, no scope enforcement, and no revocation mechanism. The blast radius of a compromised agent is enormous.

The identity model must account for all of this. Which is why point solutions, "just give the agent an API key", are not only insufficient, but they're also dangerous.

The architecture: five components, one fabric<br>1. SPIFFE: persistent identity and operating bounds<br>Before we dive in there are 3 basic principles that need some grounding. While often used interchangeably in supply chain, security and identity contexts, attestation , registration , and provenance serve distinct and important functions.<br>Attestation - this is the cryptographically signed proof (aka digital verifiable credential, the JWT SVID - a SVID, or SPIFFE Verifiable Identity Document, is the cryptographic proof that a specific workload is who it claims to be, implemented with a JSON Web Token).‍<br>Registration - is the agentic registry where both identity and trust are established.‍<br>Provenance - is a record of where an item came from. This is where the registry is needed in conjunction with attestation (the proof). Having an agentic, and even machine or workload, registry is key for establishment of trust. Before an agent can run (or operate) it must be registered as this is key for SPIFFE (Secure Production Identity Framework for Everyone) ID generation and coupling to business, financial and security contexts.<br>SPIFFE is the foundation of identity. Every agent gets a SPIFFE ID: a URI-formatted, cryptographically verifiable workload identifier issued by a trusted SPIFFE implementation (SPIRE or a productized equivalent).<br>They take the following format: spiffe://trust domain/workload identifier ‍<br>spiffe://trust-domain.org/agent-type/agent-name-or-purpose<br>The SPIFFE Workload API provides a consistent interface for a workload to retrieve its identity documents - JWT-SVIDs for token-based flows, X.509-SVIDs for mTLS. Credentials are ephemeral by design. The identity is persistent; the...