.svg)
SPIFFE is an open specification under the Cloud Native Computing Foundation (CNCF) for how workloads prove their identity to each other without shared secrets, hardcoded credentials, or trust based on network position. It has become the de facto answer to a problem every infrastructure team eventually hits: services need to authenticate to other services, and the conventional approaches such as long-lived API keys, IP allowlists, shared service-account credentials all degrade badly at scale.
SPIFFE replaces them with a uniform model in which each workload is issued a cryptographic identity (a SPIFFE ID, expressed as a URI) backed by a short-lived, auto-rotating credential (an SVID, in either X.509 or JWT form). This credential is automatically provisioned based on observable platform properties rather than secrets by a SPIFFE Runtime Environment (SPIRE). The SPIRE also handles attestation, and rotation via plugins for the target platform such as AWS, Azure, GCP, hardware TPMs, etc.
SPIFFE is part of most modern compute platforms and is beingwoven into Agentic platforms.
This enables workload identity based on infrastructure rather than configuration. There are no credentials for application teams to provision, rotate, or recover from compromised storage; every SVID is short-lived by construction and replaced automatically before it expires. Mutual TLS becomes practical to deploy at scale because the certificate-management problem that traditionally made mTLS painful has been moved out of the application and into the platform.
Audit and incident response improve because every service-to-service call carries a cryptographically attested identity that resolves to a specific workload rather than a shared service account. And because the same SPIFFE primitives work uniformly across Kubernetes, virtual machines, bare metal, and multiple cloud providers, identity stops being aper-environment problem and becomes a property of the platform stack itself.
SPIFFE was designed for the traditional system model where functionality, access, and use are predefined. That is how we have always built systems and the workload-identity problem in that model is well-bounded. Every service has a configured purpose, a fixed scope, and a deployment-time identity that says everything meaningful about what it does.
Agents, tools, and resources do not fit that model. In an agentic AI world, they represent capabilities that are discovered at runtime based on the task or goal being pursued. The same goal pursued twice may legitimately resolve to different capabilities each time.
Agents lack the structure of a traditional program. They have no pre-defined place in a larger process, no built-in awareness of who delegated the work, and no application-layer controls to enforce order, prerequisites, exclusions, or compensation. The controls that traditional systems express in code no longer statically exist. Because agents, tools, and resources are composed on demand, they must be controlled within context of their use.
Authorization for an agent is dominated by questions the workload identity layer was never intended to answer.
On whose authority is this agent acting right now? ASPIFFE ID names the workload. It does not carry the originator and it does not propagate that originator across hops. When agent A calls agent B calls agent C, the SVID at each hop names the calling workload; the chain of delegated authority that brought the call to this point is invisible at the identity layer.
What authorized business process is this agent participating in? Because of dynamic discovery and their use outside of traditional system controls, authorization decisions for agents relies on context that is outside SPIFFE’s scope
What does this agent claim to do, and who vouches for it? A SPIFFE ID is a name, not a declaration. It says nothing about what capabilities the workload offers, what NFRs it commits to, what processes it expects, or what publisher attests to its behavior. Agent ecosystems need discoverable, signed, semantic intent declarations of the capabilities they need/provide, data they expect, and operational concerns. These definitions must be verifiable and tamper resistant.
Is the authorization still valid right now? Workload-credential rotation refreshes the workload's identity. It does not re-evaluate whether the originator still holds the authority they delegated, whether the business process is still active, or whether the downstream party still consents to the relationship.
How do I log for auditability and non-repudiation? Workload credentials allow you to definitively capture what workloads call other workloads but are silent as to under what authority, what unique transaction instance, and the intent, or business process, for which the call was made.
How does this work across organizations, clouds, and sovereignty boundaries? SPIFFE Federation handles cross-trust-domain workload identity through bundle exchange. That solves the workload-naming problem across boundaries; it does not solve the agent-governance problem across boundaries. Cross-organization agent ecosystems need governance primitives that operate at a layer above workload identity, with peer federation rather than coordinated trust-domain operation.
How do I discover Agents, tools, and Resources? Discovery is clearly beyond the scope of what SPIFFE attempts to address but there is an overlap with federation. SPIFEE addresses the mechanisms discussed above for passing workload identities across boundaries but it is silent on whether or not those workloads should flow across those boundaries. Should this agent be able to discover andcall other agents, tools, and/or resources across the boundaries? If the workload was in the bundle, then SPIRE will allow the invocation to occur regardless of the context of the call.
This is not a SPIFFE gap. It is emerging needs of Agentic AI that should coexist with SPIFFE.
Agents need a layer that names the capability rather than the workload, declares semantic identity rather than opaque names, propagates originating authority and business context rather than dropping them at each hop, and refreshes authorization rather than just identity. That layer composes with SPIFFE (or other standards) underneath; it doesn't replace it. But for agent systems, it is the layer where the security property actually lives.
SPIFFE answers a question about workloads: Is this running process the workload it claims to be, attested by the platform it runs on?
SADAR answers different questions:
· Is this the registered agent, tool, or resource it claims to be
· Cryptographic provenance to the publisher
· What is the agent requesting or providing
· On whose authority is it acting
· Within what process is the request being made
· What is the unique instance ID of this process instance
· What discoveries, therefore what invocations across boundaries are allowed
· Bilateral agreement between requester and service
· Non-functional requirements – operational, financial, legal, & compliance
The answers are in a signed manifest for each agent/tool/resource, participant authentication with TTL, discovery with TTL, a provider issued time-of-use token, and industry-standard process/transaction and data definitions. A persistent context token is passed to every step and cryptographically bound into the context chain with the business process UUID and instance ID.
The specification defers management and issuance of these elements directly to the parties with each side able to cryptographically verify their provenance. The specification allows for different implementations that each party supports/requires within their respective manifests.
SPIFFE and SADAR do not talk to one another nor rely on each other. They operate as different layers agnostic of one another. The two specs are independent, and that independence is deliberate. SADAR is intended to provide the context and controls required within Agentic AI. It cando so with, or without, SPIFFE. SPIFFE,on its own, does not meet Agentic AI’s needs.
SADAR works at the layer above SPIFFE's deliberate scope boundary. The pieces:
Identity is anchored by registry entries (publisher, agent/tool/resource, process definitions, federated registries). Each entry has a durable signing keypair held by its publisher. The publisher signs a manifest declaring the entity's capabilities, NFRs, process expectations, credential scopes, and the verification key that validates the entity's signatures. The manifest is published through a registry as a trust anchor and for discovery and attribution. The registry stores and serves the manifest. The participating entities (e.g. publishers of entries) are sovereign in that they:
· Expose endpoints (defined in the manifests) for authentication
· Issue time-of-use tokens
· Establish their own cryptography algorithms
· Publish their own JWK for authentication and signature validation
· Have bilateral rights to agree to transact
· Own their operational, financial, legal, and compliance NFRs
The registry acts as the trust anchor for the exchange of this information with provenance and tamper evident. Because the content is directly attributed tothe respective party, it is independently verifiable (for example using X.509 certificates to verify parties). No party can publish to the registry with valid entries except for the true owner. Transactions from that point are directly between the requester and the service provider.
Trust anchors for entity keys are deployment-chosen. SADAR specifies that manifests declare how their verification key is anchored — X.509 chain to an enterprise or industry or sovereign CA, Sigstore transparency log inclusion, DID resolution, etc. Both parties declare which methods they accept. Bilateral matching on trust-anchor method becomes part of how relationships form. SADAR does not mandate any single trust-anchoring method, because the appropriate method varies by sector, sovereignty boundary, and organizational maturity.
Authorization is bilateral and time-bounded at the relationship layer. When a requester resolves a server through the registry, the server issues a time-of-use credential scoped to that specific relationship, that specific scope, and that specific window. The requester independently re-resolves through the registry on its own discovery TTL, picking up manifest changes and revocations without depending on the server tofail a call. Both endpoints have independent freshness control. Renewal cadence is risk-configurable per relationship; renewal at the boundary is substantive re-authorization, not automatic re-issuance. Caching is encouraged with the knowledge that a TTL expiration simply results in a reauthentication and authorization request.
Originator authority and business-process context propagate via SCT. Every invocation carries a SADAR Context Token — a signed chain naming the originator, the business process, the prior chain of agents that brought the call to this point, and the scope of authority delegated. Each downstream server validates the SCT against the current state of the originator's authority. The chain is signed, attributable, and re-verifiable at each hop.
Discovery is mediated by registries that federate as peers .No central authority sits between any two registries. Cross-trust-domain authorization is resolved through bilateral manifest matching and registry-mediated credential-scope resolution, not through a coordinating party.
SADAR mandates mTLS and that workload-layer attestation and mutual authentication occur. It does not specify the mechanism for establishing those certificates or attesting the workload underneath them. The mechanism choice is the deployment's; the requirement that something meets the bar is the spec's. The how is expressed in the manifest allowing parties to agree on what is acceptable.
If you're running SPIFFE today and you're starting to deploy agents, you don't need to choose. SPIFFE keeps doing what it does at the workload layer; SADAR adds the entity-identity, semantic-identity, and authorization layers above it. Your workloads continue to bootstrap identity through platform attestation; your agents additionally publish manifests, validate against trust anchors, and propagate originator authority and business-process context through SCT. The two run in parallel without conflict.
If you're deploying SADAR-governed agents in environments without SPIFFE — customer on-prem, air-gapped, partner-operated, edge — you don't need SPIFFE for SADAR to work. The entity layer carries durable identity that survives the deployment shape. You lose the workload-attestation property at the platform layer, and you should think carefully about how your threat model accounts for that, but the agent-governance properties remain intact.
If you're deciding what to adopt for a new deployment, the question isn't which spec to pick. It's which layers your workloads need. Workload identity with no agent semantics: SPIFFE alone. Agent governance with platform-attestable workloads: both. Agent governance in environments where platform attestation isn't available: SADAR with whatever workload-layer mitigations the deployment can support.
SPIFFE and SADAR aren't competitors and aren't dependencies. They're two specs solving adjacent problems at different layers, written by different communities, evolving independently, and composing well at the deployment level when the use case calls for both. Neither needs to know aboutthe other to do its job. That's what good layered design looks like.
