Stitching existing standards into end-to-end assurance for agentic identity
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.
This isn't a tooling gap. It isn't a standards gap. It's an assembly gap.
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.
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.
This post is an attempt to start building that.
Framing the problem: Agents need identity, here is why
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.
Agents are workloads with intent and broad missions.
A legacy service account calls a database with a constrained purpose.
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.
Agents operate across trust boundaries by default.
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).
Agents are ephemeral and instantiated at scale.
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.
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
1. SPIFFE: persistent identity and operating bounds
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.
- Attestation - this is the cryptographically signed proof (aka digital verifiable credential, the JWT SVID - a SVID, or SPIFFE Verifiable Document, is the cryptographic proof that a specific workload is who it claims to be, implemented with a JSON Web Token).
- Registration - is the agentic registry where both identity and trust are established.
- 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.
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).
They take the following format: spiffe://trust domain/workload identifier
spiffe://trust-domain.org/agent-type/agent-name-or-purpose
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 credential expressing it is not. This is where every "instance" of an agent sits. Instances are short-lived and will use either the JWT-SVIDs or X.509 SVIDs (SPIFFE Verifiable Identity Document) as a means of proof
The namespace as an authorization primitive
Here's where it gets interesting. The SPIFFE namespace isn't just a naming convention - it's an opportunity to encode operating bounds directly into the identity fabric.
Consider structuring namespaces like this (this is for illustrative purposes and will vary by organization):
spiffe://enterprise.org/agents/advisor/payments
spiffe://enterprise.org/agents/fraud/frauderator
spiffe://enterprise.org/workload/orchestrator-planner/
spiffe://enterprise.org/machine/k8/
spiffe://enterprise.org/agents/NCC-1701/starship
The namespace encodes:
- The agent's functional domain
- Its intent or name
- The organizations and realms of trust (i.e. 1st or 3rd party)
When the gateway or policy engine sees this SPIFFE ID (via the subject of the JWT-SVID), there are already implied boundaries of what it can or should be able to access or call (i.e. tool/service). You've collapsed the gap between agentic authentication and coarse-grained authorization, the moment an agent proves who it is, a first layer of operating bounds is already established.
What this does give you is a fast, cryptographically anchored first gate that requires no additional policy lookup. This doesn't replace fine-grained authorization, that lives in a PEP (Policy Enforcement Point) or via policies in a PBAC (Policy Based Access Control) setup.
This is not RBAC. Not ABAC. Not *BAC. The whole purpose is to move to dynamic and reactive authorization based on the evolving nature of the agent's needs and outside context; enter relationship graphs (not a new concept). When you bridge together the encoding of authorization into the SPIFFE namespace + graphs you truly unlock the power of this framework.
Instance identifiers and continuity
Beyond the SPIFFE ID, each agent instance needs a unique instance identifier, essentially a transaction-scoped entity ID that travels through the call chain. This is the mechanism by which you achieve chain of custody across multi-hop agentic workflows. Without it, you can prove an agent type was involved in a transaction but not which instance, at what time, with what context. More to come on this below in Transaction Tokens. You can think of the instance identifiers as a form of state.
2. The Agentic Gateway: policy enforcement point and resolution layer
The gateway is the central nervous system of the agentic identity fabric. All agent traffic routes through here. No exceptions.
The gateway does four things:
Resolution. Post-inference, an agent knows what tool it needs to invoke but not necessarily where that tool lives. This is a fundamental problem today that could exist in a gateway but must live outside of it for many reasons. Organization may have many gateways due to the layout or setup of agentic vendors or tools. That said, this is where the importance of the identity/trust broker comes in. It presents an intent and gets back a resolution.
Policy enforcement. Before resolving a tool, endpoint or initiating a token request, the gateway evaluates whether this agent, with this SPIFFE ID, this JWT-SVID, this declared intent, is permitted to invoke this tool at all. This is where the SPIFFE namespace operating bounds are enforced for access, and where a relationship graph query is initiated for dynamic authorization decisions.
Token brokering. The gateway initiates token requests on behalf of the agent. The agent never calls the identity broker directly. The gateway is the only surface that interfaces with the broker, preserving the credential shielding guarantee. This abstraction also either maintains or proxies to a client metadata registry. This is where the IETF ClientID Metadata Document Draft (CIMD) semantics applied to tool/service endpoints comes into the picture where tool names are resolved to actual service endpoints. The agent never has hardcoded URLs.
Observability. Every invocation, every resolution, every token request is logged with full context: agent ID, instance (JWT-SVID), tool requested, token issued, transaction identifier, timestamp, declared intent. This is how you answer "what has access to what, and why" for non-human identities.
3. The Identity/Trust Broker: credential shielding and token minting
The broker is a dedicated component in a system with a narrow, non-negotiable mandate: never hand credentials, such as API Keys or client secrets, back to an agent.
This deserves emphasis because it runs counter to how most workload identity is implemented today. The standard pattern is to let the workload manage its own long-lived credentials. For agents, this is unacceptable, credentials in agent context windows, memory, or logs are credentials at risk.
A broker may be implemented as a service, sidebar or any other mechanism that isolates the broker from the Agent. This prevents the Agent from accessing primary credentials directly, only requesting that the Broker use them on the Agent's behalf to obtain short lived transaction tokens.
The broker's flow:
- Gateway passes the agent's JWT-SVID and invocation request for Tool Y.
- For example, the policy and enforcement are going to be done here and not at the gateway layer. The broker validates the request against the agent's registered metadata (charter & purpose) and operating bounds
- Broker resolves the underlying semantics for Tool Y (lookup via a tool-to-endpoint/service registry, and/or dynamic issuance using CIMD) to authorize the call.
- Broker obtains a short-lived, scoped transaction token for this specific invocation, which it may mint itself or request from a token issuance service, like an OAuth Authorization Server, subject to the request.
- Broker returns the token to the gateway, never to the agent directly
- Gateway passes the transaction token to the agent alongside the resolved endpoint
- Agent makes the call; token is revoked/expired after the transaction is successful; nothing persists.
Token types which the broker needs to support:
- Transaction Tokens (Tx-Tkn):
Emerging standard carrying agentic context - intent, allowed actions, call chain, principal - for downstream service verification - JWT-SVIDs:
SPIFFE-native credential for workload-to-workload authentication - OAuth 2.1 access tokens:
For RESTful service access - OBO tokens (RFC 8693):
For user-initiated flows where a human principal delegates to an agent - critically, the agent should not inherit the user's full permissions, only a scoped delegation for the task/transaction
The confused deputy problem, solved
The broker architecture directly addresses the confused deputy problem - where an agent with broad permissions is manipulated into using those permissions on behalf of an attacker. Because the broker mints tokens scoped to a specific invocation based on the agent's registered bounds, there are no broad permissions to exploit. The agent can only ever exercise exactly what the broker decides to issue for this specific call.
4. Transaction Tokens: call-chain integrity and continuity
Transaction Tokens (being developed in the IETF Transactional Authorization and Delegation working group) solve a specific and critical problem in multi-hop agentic workflows: how does a downstream service know that the request arriving at its door followed a legitimate, authorized path to get there?
On-Behalf-Of Agentic Flow with a Transaction Token
In this example, a user interacts with an agent to perform a task. It hits the gateway, the gateway requests a transaction token, which can originate from the gateway but minted by the identity/trust broker. This will use the JWT-SVID token from the agent (to essentially prove the agent to then call the identity/trust broker so a transaction token can be minted for the agent’s task. The requesting workload `req\_wl` is the agentic gateway. The agent here uses the SPIFFE namespace which is copied from the `sub` claim in the JWT-SVID token. You will notice the `sub` claim below contains the user's information. This is passed in from the initial access_token where the user is interacting with the agent and carried in a claim in the JWT-SVID token.
json
{
"txn": "b6dc4883-2d85-432a-94c5-2ee9f04d276d",
"sub": "martymcfly@88mph.com", //only if this is human initiated
"aud": "https://payments.flux.88mph.com",
"iss": "https://txn-svc.88mph.com",
"purp": "process.payment",
"req\_wl": "apigateway.88mph.com",
"act": {
"sub": "spiffe://o88mph.com/agents/advisor/payments", //This is your Agents Identifier "version": "1.21",
"deployment": "us-east-1"
},
"agentic\_ctx": {
"agent\_type": "planner+tool-orchestrator",
"agent\_version": "1.2.1",
"intent": "process refund for order 84729",
"allowed\_actions": \["read", "write"],
"authorization\_details": \[
{
"type": "search\_service\_thing",
"actions": \["list", "read"],
"locations": \["https://flux-capacitor.88mph.com/search/v1"]
}
],
"environment\_constraints": {
"environment": "prod",
"region": "us-east"
}
}
}Multi-Agent Flow with a Transaction Token
This example will tie it all together with complexity. Here, a user interacts with a researcher agent that spawns an instance/task, which then delegates a specific action to a Search Agent.
json
{
"txn": "b6dc4883-2d85-432a-94c5-2ee9f04d276d",
"sub": "martymcfly@88mph.com", //only if this is human initiated
"aud": "https://payments.flux.88mph.com",
"iss": "https://txn-svc.88mph.com",
"iat": 1712850000,
"exp": 1712850300,
"purp": "web.search.execute",
"req\_wl": "apigateway.88mph.com",
"act": {
"sub": "spiffe://88mph.com/agents/search", //This is the delegated agents identifier
"version": "1.776",
"deployment": "us-west-1"
},
"act\_chain": \[
{
"sub": "spiffe://88mph.com/agents/einstein-research",
"iat": 1712849950
}
]
"agentic\_ctx": {
"agent\_type": "tool-orchestrator",
"agent\_version": "1.2.1",
"intent": "validate search services",
"allowed\_actions": \["read"],
"environment\_constraints": {
"environment": "prod",
"region": "us"
}
}
}A payments service can be configured to accept a transaction token only if the context shows that a fraud validation service previously handled the request. A data service can require that a compliance check appears in the chain. You're not just authenticating the caller - you're verifying the legitimacy of the entire transaction path.
This is call-chain integrity. And it's the mechanism that makes multi-agent workflows auditable and enforceable rather than just observable.
5. Shared Signals: continuous assurance across the plane
This is where the stack transcends point-in-time security and becomes a reactive fabric.
The Shared Signals Framework (OpenID SSF) defines a standard for transmitting security events — risk signals, authentication events, session changes, behavioral anomalies - between transmitters and receivers in real time.
In an agentic identity context, this means:
The posture is always current. A token minted 60 seconds ago reflects the world as it was 60 seconds ago. Shared signals mean the gateway and broker are continuously receiving updates about that world. If a risk signal arrives - anomalous behavior from agent instance X, a downstream service reporting unexpected call patterns, a credential appearing somewhere it shouldn't - the system can respond without waiting for token expiry.
The response is automatic. Receivers (the gateway, the broker, the policy enforcement point / authorization graph) are configured with response policies. A high-confidence anomaly signal triggers immediate token revocation and stops new minting. A medium-confidence signal might trigger step-up verification or scope narrowing. No human needs to write a new policy. The signal drives the response.
The plane is aware of itself. When you layer shared signals across an agentic deployment at scale, you get emergent visibility - the security fabric starts to understand the behavioral baseline of your agent population and can detect deviations that no static policy would catch.
Combining with SPIFFE namespace bounds:
When a shared signal arrives indicating anomalous behavior from an agent, the response can be targeted with surgical precision because the SPIFFE namespace already encodes the operating bounds. You don't just revoke access broadly — you can narrow the namespace, tighten the scope, or quarantine the specific instance while leaving the agent type operational.
The full flow, end to end:
1. Agent is attested at startup (registration)
└── SPIFFE ID issued: spiffe://enterprise.org/agents/advisor/payments
└── This is written to a registry
2. Agent completes inference
└── Knows it needs to invoke: payments-processing-tool
└── Does NOT know where it lives or how to authenticate
3. Agent presents SPIFFE ID (via JWT-SVID) + intent to Agentic Gateway
└── Gateway validates agent is registered, legitimate and still active
└── Gateway validates SPIFFE namespace operating bounds
└── Gateway queries PEP/relationship graph: can this agent call payments-processing-tool?
└── PEP returns: authorized, with these constraints
4. Gateway initiates token request to Identity Broker
└── Broker validates request against agent registered metadata (charter and purpose)
└── Broker resolves payments-processing-tool endpoint
└── Broker mints short-lived \& scoped Transaction Token
└── Token includes agentic\_ctx, intent, allowed\_actions, call-chain context
5. Gateway returns to agent: endpoint + token
└── Agent never sees underlying credentials
└── Agent never directly interacted with broker
6. Agent invokes payments-processing-tool with token
└── Downstream service validates Transaction Token
└── Verifies call chain includes required upstream services
└── Processes request
7. Token expires
└── Nothing persists in agent context
└── Full audit trail in gateway observability layer
8. Throughout: Shared Signals flowing across the plane
└── Any anomaly signal triggers automatic posture adjustment
└── Gateway and broker respond without human intervention
What's still being figured out
This is a bleeding edge architecture, and intellectual honesty requires acknowledging what's unresolved:
The gateway-broker relationship. Should the broker be invoked inline per request by the gateway, or should there be a session establishment phase? Inline is simpler but adds latency at every hop. Session-based is more efficient but introduces state management complexity.
Client metadata ownership. Who owns the tool endpoint registry — the gateway, the broker, or a dedicated service discovery layer? How does it stay current as services scale and move?
Multi-hop token chaining. In complex agent-to-agent workflows, does each hop require a fresh broker invocation? How do you maintain call-chain integrity across agent boundaries without creating a latency tax that makes the system impractical? OAuth Identity and Authorization Chaining Across Domains is pushing boundaries in this space.
SPIFFE namespace governance. The namespace-as-authorization-primitive pattern is powerful but requires discipline. Who governs the namespace schema? How do you prevent namespace sprawl? How do you handle namespace changes when an agent's operating scope changes?
Shared Signals receiver policy standardization. The SSF defines how signals travel. What's less standardized is receiver response policy — how aggressively should a gateway respond to a medium-confidence signal? These policies need to be authored, tested, and maintained. There is work being done in the SSF working group to allow for the introduction of prescriptive signals with "closing of the loop" with action receipts.
Why this matters beyond agents
Solving agentic identity with this stack has a compounding benefit: every component applies equally to the broader NHI problem. Services, containers, pipelines, CI/CD systems...all of them benefit from SPIFFE-based identity, scoped token issuance, transaction chain integrity, and continuous signal-driven posture.
You're not just building an agentic identity architecture. You're building a universal non-human identity fabric with agents as the first and most demanding use case.
The standards are written. The protocols are mature. The pieces are on the table.
Now build it.
References:
- SPIFFE/SPIRE: spiffe.io
- RFC 8693: OAuth 2.0 Token Exchange
- IETF Identity Chaining: draft-ietf-oauth-identity-chaining
- IETF Transaction Tokens: draft-ietf-oauth-transaction-tokens
- IETF Agentic Transaction Tokens: draft-oauth-transaction-tokens-for-agents
- IETF Transaction Token Authorization Grant for OAuth Identity and Authorization Chaining: draft-fletcher-transaction-token-chaining-profile
- OpenID Shared Signals Framework: openid.net/specs/openid-sharedsignals-framework
- IETF CIMD: draft-parecki-oauth-client-id-metadata-document
- OpenID Federation 1.0: openid.net/specs/openid-federation