Agents Are Workloads: Why the Last Decade of Identity Standards Already Solves 95% of Agentic Identity
The fork in the road
The agentic identity conversation has split into two camps. One camp argues that AI agents are a fundamentally new species of non-human identity (NHI) and require a new stack: agent-specific identifiers, agent-specific consent flows, agent-specific authorization protocols. The other camp argues that agents are just workloads with novel UX layered on top, and that the IAM industry already shipped most of what we need — we’re just not deploying it.
At UberEther, we believe that agents are workloads, and 95% of the problem is solved now.
This isn’t a deflection. It’s a load-bearing claim. The architectural move is to stop chasing greenfield “agentic IAM” vendors and start asking why your existing infrastructure isn’t already issuing short-lived, cryptographically verifiable credentials to every agent in your environment. Stop buying new tools, every dollar should be spent on SPIFFE, OAuth token exchange, CAEP, and gateway-enforced policy. Everything else is a waste.
The pressure: scale, surface, and speed
Three forces make agentic identity an urgent operational problem rather than a future research topic.
Scale. A single human user might invoke ten agents in a workflow, each of which spawns sub-agents and tool invocations across multiple backends. The identity ratio inverts: where IAM teams have historically managed ~10 service accounts per human user, agentic workflows push that ratio toward 100:1 or 1000:1. Static, human-provisioned credentials don’t scale through that inversion.
Surface. Agents straddle platforms. An agent provisioned by Anthropic might call an internal API that calls an MCP server that calls a SaaS vendor that calls another agent. Each hop crosses a trust boundary. Long-lived bearer tokens that worked fine for a service-to-service call between two known endpoints become catastrophic when they traverse five domains controlled by different organizations.
Speed. Threat actors are already targeting agentic infrastructure. The attack surface includes prompt injection of agent instructions, exfiltration of agent-held API keys, hijacking of agent sessions to pivot into backend systems, and abuse of over-broad agent scopes. The “let’s figure it out as we go” approach that worked for early SaaS doesn’t survive contact with adversaries who specifically tune their tradecraft to agentic patterns.
If you don’t impose workload-grade identity discipline on agents now, you are inheriting a credential sprawl problem an order of magnitude worse than the one IAM teams have spent the last decade trying to fix in CI/CD pipelines and service accounts.
The API-key catastrophe, replayed
Walk into a typical agent deployment today and you’ll find a depressingly familiar pattern: a .env file or a Kubernetes Secret holding a long-lived API key for the LLM provider, another for the vector database, another for the tool integrations, another for the orchestration platform. The agent process loads them at startup and treats them as bearer credentials for the lifetime of the deployment.
This is the exact pattern that drove the workload identity movement in CI/CD five years ago, and it has the same failure modes:
- No revocation granularity. Compromised key means rotating across every consumer, with downtime.
- No attestation. Possession of the key is the only proof — there is no binding to the workload that’s supposed to hold it.
- No audit chain. When the key is used, you know what called the API, not which instance of the agent, on whose behalf, or as part of which transaction.
- No expiry pressure. Keys live until somebody remembers to rotate them, which usually means until they’re leaked.
The non-agentic workload world solved this with the Secure Production Identity Framework for Everyone (SPIFFE) and its reference implementation, SPIRE. The agentic world doesn’t need a different solution. It needs to adopt this one.
What “agents are workloads” actually buys you
The reason the workload framing is so powerful is that it inherits an entire technology stack that has been hardened, profiled, and standardized over a decade. Specifically:
Identity issuance. SPIFFE defines a URI-formatted identifier (spiffe://trust-domain/path) and three credential types — X.509-SVID, JWT-SVID, and the newer WIT-SVID — that bind a cryptographic key to that identifier. Issuance happens at workload startup via the SPIFFE Workload API, gated by attestation (what process is this, on what node, in what namespace, signed by what platform?). No long-lived secrets are distributed to the workload; the credential is minted on demand and rotated continuously, typically on the order of minutes to hours rather than months.
Client authentication. The IETF OAuth working group has adopted draft-ietf-oauth-spiffe-client-auth, which profiles RFC 7521 (Assertion Framework) and RFC 7523 (JWT Profile) to let SPIFFE-credentialed workloads authenticate to OAuth authorization servers using their SVIDs directly. No client secrets. No private-key JWTs distributed out of band. The SPIFFE ID becomes the client identifier, the SVID is the credential, and the AS validates against the SPIFFE Bundle Endpoint for the relevant trust domain.
Dynamic registration. Agents spin up and tear down on agentic time, not procurement time. The OAuth Client ID Metadata Document draft lets a client_id be a URL that resolves to a JSON document containing the client’s metadata — including its SPIFFE ID (with optional wildcard match, e.g. spiffe://example.org/agents/*) and bundle endpoint. The authorization server learns about new agents at first use rather than via a registration ticket process.
Authorization context. OAuth Token Exchange (RFC 8693) lets agents exchange one token for another scoped to a specific downstream call, with user identity, agent identity, and authorization context bound together. Transaction Tokens extend this to preserve user identity and authorization context across the entire call chain inside a trust domain, even when downstream workloads initiate new internal transactions.
Runtime revocation. Continuous Access Evaluation Protocol (CAEP), under the OpenID Foundation’s Shared Signals Framework, lets identity providers and resource servers communicate revocation events in near real time. A rogue agent doesn’t have to wait for token expiry to lose access — a CAEP signal at the gateway revokes the session mid-flight.
That stack — SPIFFE for identity, OAuth + token exchange for authorization, transaction tokens for context propagation, CAEP for revocation — is the 95%. Each piece is published as either a stable RFC or an IETF working group draft with active reference implementations. None of it requires a new vendor category.
The thesis, stated precisely
- An agent is a process with a key. Whatever else it is — LLM-backed, tool-using, multi-step planning — at the credential layer it is a workload that needs to prove who it is and what it’s allowed to do.
- Workload identity is a solved problem in principle. SPIFFE plus OAuth plus CAEP gives you cryptographic identity, scoped delegated authorization, contextual binding, and runtime revocation.
- The novel parts of agentic identity are user-facing, not infrastructure-facing. How do humans grant consent to an agent acting on their behalf for a class of future actions they cannot fully enumerate? How does an agent capture intent precisely enough that the authorization decision is principled? These are research questions. They are not the same questions as “how do I authenticate this agent to my API.”
- The risk of building greenfield agentic IAM is that you re-derive an inferior version of the workload stack. Most “agent identity” startups are reinventing client registration, attestation, and token exchange — usually worse, and usually proprietary.
The 5%: where the workload model needs help
The thesis is not “we’re done.” It’s “we’re 95% done on infrastructure; let’s focus the remaining work where it actually is.”
That remaining work has at least four pieces:
Agent-specific consent. OAuth was designed for users granting third-party apps access to specific resources for known purposes. Agents act in open-ended ways across long horizons. The semantics of “the user agreed to let this agent do X” need richer authorization grammar than current OAuth scopes provide. Work on this is happening at OpenID Foundation and in adjacent IETF drafts on AI agent authentication and authorization, but it’s earlier-stage than the workload identity pieces.
Intent capture and authorization at instance scale. Even if an agent has a valid SVID and a valid access token, the authorization decision for “should this specific agent invocation be allowed to call this specific tool with these specific arguments right now” requires policy. Static OAuth scopes alone don’t carry enough context. Policy-based access control (PBAC) at the gateway, fed by signals from the agent runtime and the user session, is the emerging pattern — and it’s where most enterprises are least mature.
Cross-platform federation at internet scale. A workload in your trust domain calling a workload in your partner’s trust domain works via SPIFFE federation today. An agent provisioned by Anthropic that needs to act inside your trust domain against an agent provisioned by Google is a federation problem at a different scale, requiring trust establishment between LLM providers, enterprises, and arbitrary third parties. Anthropic and Google have both shipped workload identity federation primitives (Google Agent ID is the most concrete example); the standards work to make these interoperable is starting now.
Governance traceability. A single agent often holds multiple SVIDs for multiple downstream callers, plus multiple OAuth access tokens with different scopes. Proving to an auditor that “this action happened because user U asked agent A which delegated to sub-agent B which called service S under transaction T” requires governance plumbing that exists conceptually but is rarely wired up end to end. This is the part most likely to bite first in regulated environments — DoD, FedRAMP High, financial services — because the audit story has to survive an assessor’s review, not just a security architect’s whiteboard.
What to do this quarter
For an architect responsible for any agent-enabled workload, the actionable form of the thesis is a short list:
- Stop provisioning long-lived API keys to agents. If your agents use bearer tokens loaded from environment variables, that is the leak waiting to happen. Issue SVIDs via SPIRE (or your platform’s SPIFFE-compatible issuer) and rotate them on the order of minutes.
- Adopt OAuth client authentication via SPIFFE. Configure your authorization server to accept the urn:ietf:params:oauth:client-assertion-type:jwt-spiffe assertion type. Keycloak has a preview implementation; the draft is at draft-ietf-oauth-spiffe-client-auth-01. Once your agents authenticate to your AS via SVID, you remove an entire class of secret-distribution risk.
- Use Client ID Metadata Documents for agent registration. A URL-based client identifier that resolves to a document with a SPIFFE ID wildcard (spiffe://your-domain/agents/*) lets you bring new agent instances online without a registration ceremony.
- Pilot transaction tokens for high-value call chains. Any flow where a user request fans out into multiple workload invocations and you cannot reconstruct user identity, agent identity, and the authorization decision at the end of the chain is a candidate. The draft is draft-ietf-oauth-transaction-tokens-07.
- Wire CAEP into your gateway. Even a partial implementation — session revocation events from your IdP consumed by your API gateway — buys back the ability to kill a misbehaving agent’s access in seconds rather than waiting for token expiry.
None of this requires a new product category. All of it is buildable on top of identity infrastructure you almost certainly already have, configured to standards that are either stable RFCs or actively progressing IETF drafts.
The thesis in one line
The moment you stop thinking of agents as a new species of identity and start thinking of them as workloads that happen to have an LLM in the middle, the architectural path becomes obvious and the engineering becomes tractable.
Subsequent articles in this series go deeper on each layer of the stack: SPIFFE and SVID issuance, OAuth SPIFFE client authentication, transaction tokens and identity chaining, and CAEP-enabled gateway revocation. Together they cover the 95% — and make it concrete enough to deploy this quarter.
Primary sources: IETF drafts draft-ietf-wimse-arch-07, draft-ietf-oauth-spiffe-client-auth-01, draft-ietf-oauth-transaction-tokens-07; SPIFFE specifications at spiffe.io; Sean O’Dell, “Agentic Identity Control Framework: You Already Have the Pieces. Now Build It.”