The Enterprise Blueprint for Agentic Identity: Workload Attestation and Lifecycle Governance
The Identity industry is not starting from scratch. Existing foundational frameworks provide robust and immediately applicable solutions for securing today’s agents. The best practices of separating concerns, applying least privilege, and ensuring clear audit trails are the bedrock upon which the next generation of agentic systems must be built.
Apr 20th, 2026
Chief Technology Officer
Identity Management for Agentic AI, OpenID Foundation (October 2025)
The OpenID Foundation’s whitepaper on Identity Management for Agentic AI opens with a deceptively simple observation: AI agents are fundamentally different from traditional software. They take autonomous actions, adapt in real-time, and operate across sequences of external tool calls, none of which was anticipated when the industry designed its identity infrastructure around human logins and static service accounts.
What follows from that observation is a challenge that security and platform teams are only beginning to confront: the identity model we inherited from the era of web applications is not adequate for a world of autonomous agents. Agents need identities that are cryptographically attested, short-lived, enterprise-governed, and lifecycle-managed alongside human users, and not bolted on as an afterthought.
This post describes a proof-of-concept that builds precisely that system. It integrates SPIFFE/SPIRE workload attestation, OAuth 2.1 Dynamic Client Registration, RFC 8693 token exchange, enterprise scope policy, and a SCIM 2.0 lifecycle API into a single, coherent identity architecture for Model Context Protocol servers. Every design decision maps to a specific recommendation from the foundational research or addresses a gap the authors identified as critical.
The Problem Is Not New. The Stakes Are.
Every platform engineer who has provisioned a microservice has faced a version of this problem: how does a machine prove who it is? The traditional answer has been a shared secret: an API key, a client secret, a long-lived token stored in an environment variable, or a secrets manager. That answer has always been uncomfortable, but for stateless services with predictable, bounded behavior, the risk was manageable.
AI agents change the equation in three ways simultaneously:
-
Agents act autonomouslyUnlike a microservice executing a deterministic function, an agent interprets unstructured input and decides what actions to take at inference time. A single user instruction can generate dozens of API calls across multiple downstream systems. The blast radius of a compromised agent identity is not bounded by the service’s code; it is bounded only by the permissions the agent holds.
-
Agents act on behalf of usersAn agent accessing a company’s CRM on a sales representative’s behalf carries both the agent’s own permissions and a delegated subset of the user’s authority. When that agent’s requests appear indistinguishably from direct user requests in audit logs (which is the current state in most implementations), accountability disappears entirely. To frame this directly: agents often act indistinguishably from users, creating accountability gaps and security risks that demand a move to explicit delegated authority.
-
Agents have lifecyclesThey are provisioned, their entitlements change as organizational roles evolve, and they must be decommissioned, often urgently, in response to a security event. None of the incumbent tooling for service accounts handles this lifecycle with the same rigor enterprises apply to human identities.
These represent the most pressing near-term challenges, leading to a clear core recommendation: bring agents into the same standards-based identity infrastructure that governs human users, rather than building bespoke, proprietary alternatives that fragment the ecosystem.
Layer One: Cryptographic Workload Attestation with SPIFFE/SPIRE
The foundational question in any identity architecture is: what does it mean to trust a client’s identity claim? For human users, trust is established through authentication: a password, a hardware token, a biometric. For workloads, the analogous mechanism is attestation: proving, through properties of the running environment itself, that a process is what it claims to be.
Industry guidance explicitly names SPIFFE (Secure Production Identity Framework for Everyone) and its runtime environment SPIRE as the model for workload identity for AI agents:
“By integrating with SPIRE, an AI agent could be provisioned with a short-lived, automatically rotated identity that it can use to mutually authenticate with other services, establishing trust without relying on static, shared secrets like API keys.”
Our implementation instantiates this model end-to-end. Each application container runs an embedded SPIRE Agent that attests itself to the SPIRE Server using x509pop (X.509 Proof of Possession): the agent presents a TLS certificate signed by an internal CA, and the SPIRE Server validates it against the registered certificate chain for that node. There are no join tokens. There are no static secrets. The CA certificate is the only root of trust, and it is established once at infrastructure setup time, not per-workload.
Once a node agent has its identity, workloads receive SVIDs (SPIFFE Verifiable Identity Documents) through the SPIFFE Workload API via a gRPC. Private key material is delivered directly to process memory and never written to disk or passed through environment variables. Every workload in the system (the MCP Client, MCP Server, Management API, and SCIM Server) receives a SPIFFE ID following a consistent naming convention:
- spiffe://spire.indigolabs.ca/workload/mcp-client
- spiffe://spire.indigolabs.ca/workload/mcp-server
- spiffe://spire.indigolabs.ca/workload/management
- spiffe://spire.indigolabs.ca/workload/scim-server
The SPIRE Server is configured with a 1-hour X.509 SVID TTL and a 5-minute JWT-SVID TTL. These short lifetimes are the mechanism for limiting blast radius: a leaked X.509 SVID expires in at most 60 minutes; a leaked JWT expires in at most 5 minutes. SPIRE rotates the X.509 SVID automatically at approximately 80% of its lifetime (~48 minutes), and the application layer propagates that rotation to the authorization server without a restart, which is a critical property for production environments.
This is the Enhanced Service Account model identified as the most viable near-term enterprise pattern for agentic workloads: an agent with an identity token enriched with workload-specific metadata (in this case, a SPIFFE ID encoding the service name, trust domain, and path), issued through a standards-based attestation mechanism, not through a human-mediated provisioning workflow.
Layer Two: Closing the DCR Anonymity Gap
RFC 7591 (OAuth 2.0 Dynamic Client Registration) is the mechanism by which clients register themselves with an authorization server at runtime. This is exactly the kind of autonomous, self-service onboarding that agent architectures need. The MCP specification mandates DCR as the registration mechanism for MCP clients.
But there is a pointed concern: unauthenticated DCR endpoints create anonymous clients: entities with OAuth credentials but no verifiable link to a real workload, organization, or accountable party. Mass anonymous registration is a denial-of-service vector, and an unattested client_id is a weak foundation for an enterprise security model.
The solution implemented here bridges DCR and SPIRE directly: the software statement field in the DCR request carries a JWT-SVID (a JWT issued by SPIRE, signed with the SPIRE trust domain’s EC P-256 private key, and containing the workload’s SPIFFE ID as the sub claim). The authorization server (PingAM) validates this software statement by fetching the SPIRE OIDC Provider’s JWKS endpoint over HTTPS (https://spire-oidc.docker.internal/keys) and verifying the JWT signature.
The result is that every DCR request is cryptographically linked to a specific, attested workload. PingAM registers the client with private_key_jwt authentication, using the EC public key extracted from the workload’s X.509 SVID as the registered client JWKS. The client can now authenticate to PingAM by signing JWTs with its SPIRE-issued private key. This key was never written to disk, never passed as an environment variable, and expires in 60 minutes.
This is a direct implementation of the pattern recommended for robust DCR: clients linked to a verifiable identity assertor, rather than anonymous registrations with no accountability chain.
Layer Three: Zero-Downtime Key Rotation as Operational Reality
One of the underappreciated properties of short-lived credentials is that they are only as secure as the rotation mechanism. If rotating keys requires a human operator, a deployment pipeline, or a service restart, organizations will extend TTLs to reduce operational burden, and the blast radius reduction evaporates.
The implementation addresses this directly. After DCR, each workload starts a SVID polling loop that checks the certificate fingerprint every 30 seconds. When SPIRE issues a new SVID (at ~48 minutes for a 1-hour TTL), the fingerprint changes. The application detects the change, extracts the new EC public key from the fresh X.509 SVID, fetches a new JWT-SVID for use as a renewed software statement, and issues an RFC 7592 PUT to the registration_client_uri, all without restarting the process or interrupting in-flight requests.
This is not a theoretical capability. It has operated continuously throughout the development of this POC, rotating keys dozens of times without a single failed request.
The properties this delivers align directly with discussions of credential lifecycles in agentic systems:
-
No operator involvementThe rotation is fully autonomous.
-
No secrets ever at restPrivate key material lives only in process memory for the SVID’s lifetime.
-
Short, bounded blast radiusA compromised key expires within the SVID TTL; the polling loop propagates the revocation to the authorization server within 30 seconds of SPIRE issuing the replacement.
Layer Four: Enterprise Policy at the Authorization Layer
Significant attention must be dedicated to the principle of least privilege, calling it especially critical when deploying AI agents given their non-deterministic nature. The concern is straightforward: an agent that holds broader permissions than the task requires amplifies the consequences of any misuse or compromise.
The standard mechanism for scoping agent access is OAuth 2.0 scopes. But scopes are only as meaningful as the policy that governs their issuance. An agent that can request arbitrary scopes and receive them has no effective scope constraint at all.
This implementation enforces scope policy at the authorization server, not at the client or resource server. PingAM runs an Access Token Modification Script that fires on every token issuance. The script queries PingDS (the LDAP directory) for the user’s group memberships and strips any MCP scope not earned by those memberships before the token is returned.
The mapping is explicit and auditable:
| LDAP Group | MCP Scope Granted |
|---|---|
| Engineering | mcp.engineering |
| Sales | mcp.sales |
| Leadership | mcp.leadership |
| HR | mcp.hr |
A user in the Sales group who requests mcp.engineering receives a token with that scope stripped. The client cannot circumvent this, as the filtering happens server-side, inside the authorization server, before the token is issued. This is the separation of the Policy Enforcement Point (PingAM token endpoint) from the business logic that industry experts recommend, referencing NIST SP 800-162 as the architectural model.
The MCP Server then validates scopes on every incoming request as a second line of defense. The scope enforcement at the authorization server ensures the token cannot carry unauthorized scopes; the enforcement at the resource server ensures the resource cannot be accessed without the correct scope even if somehow a token arrived with unexpected claims.
Layer Five: True Delegation Over Impersonation
One of the most consequential architectural choices in any agentic system is how the agent represents its authority when acting on behalf of a user. The naive implementation is impersonation: the agent holds the user’s access token and presents it directly to downstream systems. This is what analysts call the accountability gap where the downstream service cannot distinguish the agent’s actions from the user’s.
The alternative is explicit delegation, and the MCP ext-auth specification provides the protocol mechanism for it. This is framed as the critical shift from a security posture perspective:
“True delegation requires explicit ‘on-behalf-of’ flows where agents prove their delegated scope while remaining identifiable as distinct from the user they represent.”
The implemented ext-auth flow achieves this through a two-step RFC 8693 token exchange chain:
-
Step 1: Identity Binding.The MCP Client presents the user’s OIDC ID Token to PingAM’s token endpoint and requests an ID-JAG (Intermediate Agent Grant). Critically, this request is authenticated with a Private Key JWT signed using the SPIRE SVID, the agent’s cryptographic workload identity. The resulting ID-JAG carries the user’s identity, but is issued to a client that has proven, through SPIRE attestation, that it is the specific workload authorized to perform this exchange. -
Step 2: Scope-Filtered Access Token.The MCP Client presents the ID-JAG to request a final MCP Access Token. At this point, PingAM’s Access Token Modification Script fires, filtering the requested scopes against the user’s LDAP group membership. The returned token carries both the user’s identity and the filtered scope set. Neither can be escalated by the client.
-
Step 3: Attested Tool Call.The MCP Server receives the access token as a Bearer credential, validates it against PingAM’s JWKS endpoint, and enforces scope-based access control before executing any tool.
What makes this delegation rather than impersonation is the audit trail embedded in the token itself. The act claim in the final access token records the agent as the acting party, while the sub claim carries the user who delegated authority. Any downstream system that logs the token claims gets an unambiguous record of who authorized the action and which agent instance performed it, closing the accountability gap identified as endemic in current agent deployments.
One practical note on implementation: the ext-auth specification prescribes an RFC 7523 JWT Bearer grant for Step 2. PingAM does not honor the RFC 8693 audience parameter during ID token exchange; it sets aud=client_id per OIDC conventions rather than aud=token_endpoint_url as required by the JWT Bearer validator. We work around this by using a second token exchange rather than a jwt-bearer grant. This is a PingAM-specific constraint; an IdP that correctly implements the audience parameter would enable the spec-prescribed flow without client code changes.
Layer Six: SCIM as the Enterprise Governance Layer for Agentic Identities
A dedicated focus must be placed on SSO and provisioning, with a pointed conclusion:
“The System for Cross-domain Identity Management (SCIM) protocol is the standard for automating user lifecycle management. This same lifecycle management is equally critical for the agents themselves, which require formal processes for creation, permissioning, and eventual decommissioning.”
The experimental SCIM Agentic Identity Schema Draft is highly relevant as the mechanism for bringing agents into the same provisioning model as human users. Our implementation builds a production-pattern SCIM 2.0 server that implements this model concretely.
The AgenticIdentity resource type uses the schema URN urn:ietf:params:scim:schemas:core:2.0:AgenticIdentity. Its attributes are purpose-built for the unique governance needs of workload identities:
| Attribute | Purpose |
|---|---|
| displayName | Human-readable identifier for the agent |
| spiffeId | SPIFFE URI linking the SCIM record to the SPIRE workload entry |
| spireEntryId | Internal SPIRE entry UUID, used for deprovisioning |
| oAuthClientIdentifiers | Array of OAuth2 client registrations associated with this identity |
| entitlements | Scope claims or permission tags governing the agent's access |
| owners | Human stakeholders accountable for this agent's behavior |
| active | Whether the agent is currently authorized to operate |
The SCIM server implements the full RFC 7644 protocol surface for AgenticIdentity resources (list, get, create, patch, and delete) and also proxies standard Users and Groups operations through to the LDAP directory. This gives enterprise administrators a single SCIM endpoint for managing both human and non-human identities, using the same tooling and governance workflows.
Provisioning: One API Call to Create a Workload Identity
When a POST /scim/v2/AgenticIdentities request arrives, the SCIM Server does more than record the data. It calls the SPIRE Server’s gRPC API directly using the BatchCreateEntry method to register a workload entry with a deterministic SPIFFE ID derived from the SCIM record’s UUID:
spiffe://spire.indigolabs.ca/workload/agentic/{uuid}
The response to the API caller includes the assigned spiffeId and confirms that the workload is now authorized to receive SVIDs from SPIRE. In a single API call, an operator has provisioned a cryptographic workload identity. There are no manual SPIRE CLI commands, no operator-mediated key generation, and no static secrets to distribute.
This is the integration described as essential for scalable agentic identity management: SCIM as the provisioning trigger, with downstream identity systems (SPIRE, the OAuth2 provider, the LDAP directory) updated automatically.
Deprovisioning: The Cascade That Matters
Deprovisioning is not an afterthought; it is a foundational pillar of safety:
“A compromised agent identity that is merely ‘revoked’ may retain its underlying registration and trust relationships, representing a dormant but persistent threat. De-provisioning is the ultimate response to a compromise or end-of-life event.”
The DELETE /scim/v2/AgenticIdentities/:id endpoint implements a full five-step deprovision cascade:
-
SPIRE entry deleted via gRPC BatchDeleteEntry, meaning the workload can no longer attest and cannot receive a new SVID.
-
LDAP group memberships removed from PingDS so the scope entitlements derived from group membership are immediately revoked.
-
OAuth2 clients deleted from PingAM via the DCR registration endpoint, rendering existing client_id credentials invalid.
-
Record tombstoned in SQLite (marked deprovisioned=1 with a timestamp; never hard-deleted to preserve the audit trail).
-
Audit log written with the full list of completed actions and an optional reason string.
This cascade triggered by a single SCIM DELETE ensures that deprovisioning an agentic identity is complete, irreversible, and auditable. The SPIRE workload cannot attest. The OAuth2 client cannot authenticate. The scope entitlements are gone. Every action is recorded. This is the formal de-provisioning signal that must propagate across all integrated systems when an agent is decommissioned.
Layer Seven: Deterministic Infrastructure with No Operational Escape Hatches
A thought leadership argument about identity architecture is only credible if the system actually runs without human shortcuts. One of the most common failure modes in zero-trust deployments is the presence of “escape hatches” like manual certificate injection, hard-coded bootstrap credentials, or one-time setup scripts that never get cleaned up.
The entire system runs from a single docker compose up command, with no external orchestration, no manual steps, and no operator-provided secrets. Startup ordering is enforced through depends_on health checks that are deterministic, not timing-based. The cert-init container generates all TLS certificates; spire-init registers all node and workload entries; application containers start only after both have completed successfully. The certs-data Docker volume is the single root of trust.
This matters beyond operational convenience. An architecture that requires a human to “just quickly run this script” in a specific order has a security model that depends on that sequence being followed correctly every time. The Docker Compose model makes the trust chain explicit, reproducible, and auditable. This is precisely what is meant by automating agent lifecycle management rather than tightly coupling it to human workflow.
At startup, the SCIM Server also seeds SCIM records for the four pre-configured workloads that SPIRE already knows about: MCP Client, MCP Server, Management API, and SCIM Server itself. This means the Management UI’s identity management view is accurate from the first request, not populated on demand. Operational state is consistent from boot.
What This Demonstrates and Where the Frontier Lies
There is a clear line between what existing standards solve well and what remains genuinely unsolved. Understanding where this implementation falls on each side of that line is essential for evaluating its relevance.
What This POC Proves Today
-
Autonomous bootstrap with no human-touched secrets.From infrastructure initialization to a fully authenticated MCP tool call, no human provides a secret to any agent. The SPIFFE/SPIRE attestation chain is the only authority.
-
OAuth 2.1 compliance as a practical floorEvery token operation uses current best practices: PKCE, private_key_jwt client authentication, RFC 8693 token exchange, RFC 9728 Protected Resource Metadata. The call to implement open frameworks like OAuth 2.1 for authentication rather than custom mechanisms is the baseline, not the aspiration.
-
True delegation with an auditable identity chainThe ext-auth flow produces tokens where agent and user are distinct, identifiable parties, enabling the audit trail that is foundational for trustworthy autonomous systems.
-
SCIM-driven lifecycle with cascading deprovisionThe agentic identity lifecycle is governed by the same provisioning protocol as human users, with a deprovisioning cascade that propagates across SPIRE, the OAuth2 provider, and the LDAP directory in a single API call.
-
Least privilege enforced at the authorization server.Scope entitlements derive from LDAP group membership and are filtered server-side at every token issuance, not negotiated between the client and the resource.
Where the Research Identifies Unsolved Problems
Current frameworks, including this implementation, do not yet solve everything:
-
Scope attenuation in recursive delegation chainsWhen agents spawn sub-agents across trust domains, OAuth 2.0 Token Exchange provides a centralized mechanism for down-scoping. For truly decentralized, dynamic agent networks, capability-based token formats like Biscuits and Macaroons, tokens that allow offline attenuation without contacting a central authorization server, represent an active research area.
-
Cross-domain federation.SPIFFE/SPIRE works within a controlled infrastructure. The SPIFFE/SPIRE model fundamentally relies on knowledge and control of that infrastructure. When agents must operate across organizational boundaries where no shared infrastructure exists, a different trust fabric is required, such as OpenID Federation, Verifiable Credentials, or the emerging OIDC for Agents proposals.
-
Scalable human governance and consent fatigueA looming problem exists of users facing thousands of authorization prompts as agents proliferate. The proposed solution (policy-as-code for agent authorization, risk-based dynamic authorization, CIBA for out-of-band approval) is not implemented in this POC. It is the natural next layer above what we have built.
-
Agent behavior identityAgent identity must eventually be enriched with metadata about the underlying model, version, and capabilities to enable risk-based access control; not just what the workload is, but how it behaves. This is beyond the current state of any standard.
Building on Standards, Not Around Them
The prevailing guidance concludes with a call to action directed at two groups. For developers and architects: build on the secure foundation of existing standards while designing systems with the flexibility to incorporate emerging models of delegated authority. For enterprises: begin treating agents as first-class citizens within IAM infrastructure and establish robust lifecycle management.
This implementation is a response to both. It demonstrates that the existing standards (SPIFFE/SPIRE, RFC 7591 DCR, RFC 7592 client management, RFC 8693 token exchange, RFC 7644 SCIM) are sufficient to build a production-pattern identity architecture for AI agents today, within a single trust domain, without any proprietary extensions or vendor lock-in.
The system is entirely composed of open-source components and IETF/W3C standards. SPIRE is CNCF-graduated. PingAM and PingDS can be replaced with any OAuth 2.0/OIDC-compliant authorization server and LDAP directory. The SCIM server is a custom implementation, but it speaks a standard protocol that every major IAM vendor already supports.
The enterprise that begins building agentic identity infrastructure on these standards today is making a durable investment. The enterprise that builds it on a proprietary service account model, or does not build it at all, letting agents run with hardcoded API keys, is accumulating identity debt that will compound with every agent it deploys.
Agent identity fragmentation is a major risk to avoid: “Vendors could develop proprietary agentic identity systems, which would reduce developer velocity by forcing repeated one-off integrations and compromise security by creating multiple security models.” The alternative of convergence on workload attestation, OAuth 2.1 for authorization, and SCIM for lifecycle management is not a future aspiration. It is an architecture that runs today.
Architecture Summary
The following table maps each component of the system to the standard it implements and the recommendation it fulfills:
| Component | Standard | Recommendation |
|---|---|---|
| SPIRE workload attestation | SPIFFE / x509pop | Enhanced Service Account model (§3.1) |
| JWT-SVID software statement in DCR | RFC 7591 | Close the DCR anonymity gap (§2.5) |
| private_key_jwt client auth | RFC 7523 | Authenticate all agent interactions (§2.14) |
| Automatic SVID key rotation | RFC 7592 | Short-lived credentials, automatic rotation (§2.8) |
| PKCE Authorization Code Flow | RFC 7636 | OAuth 2.1 best practices (§2.4) |
| ID Token → ID-JAG → MCP Access Token | RFC 8693 | True delegation over impersonation (§3.2) |
| Group-based scope filtering at issuance | OAuth 2.1 scopes | Least privilege enforcement (§2.6) |
| act claim in delegated tokens | RFC 8693 §4.4 | Close the auditability gap (§2.11) |
| Protected Resource Metadata | RFC 9728 | Externalizing authorization to a dedicated AS (§2.4) |
| SCIM AgenticIdentity lifecycle | RFC 7644 | SCIM for agent provisioning and governance (§2.9) |
| Deprovision cascade (SPIRE + LDAP + OAuth2) | RFC 7644 DELETE | Formal de-provisioning signal (§3.2) |
| Audit tombstone with actions log | IGA best practices | Maintain clear audit trails (§2.14) |
Further Reading
- Identity Management for Agentic AI: OpenID Foundation, October 2025
- SPIFFE/SPIRE documentation
- Interoperability Profiling for Secure Identity in the Enterprise (IPSIE)
- RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol
- RFC 7592: OAuth 2.0 Dynamic Client Registration Management Protocol
- RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
- RFC 8693: OAuth 2.0 Token Exchange
- RFC 7644: System for Cross-domain Identity Management: Protocol
- RFC 9728: OAuth 2.0 Protected Resource Metadata
- EXT-Auth: MCP Authorization Extension