I’ve been working on a mechanism that allows agents—and other workloads—to identify themselves without relying on long-lived application secrets. My earlier proposal for workload-managed credentials with very short lifetimes never gained traction. Our existing OAuth client-secret approach establishes that a caller possesses the secret associated with a registered client, but that is not the same as establishing which running workload is presenting it. Rotation is operationally awkward in our environment, and a copied secret can be presented from somewhere other than its intended deployment.

So I’m setting up SPIFFE (Secure Production Identity Framework For Everyone) using SPIRE (SPIFFE Runtime Environment). SPIFFE defines workload identities and their verifiable credentials; SPIRE supplies the server and node-local agents that establish eligibility and issue those credentials. It is better understood as an attestation-based identity issuance system than as a proxy for certificate authentication.

There are two distinct trust decisions. First, the SPIRE server establishes the identity of the node’s agent through node attestation. In my configuration (x509pop), this is a machine certificate. There are, however, many other options. I used a jointoken to set up an initial sandbox, k8s_psat is ideal in a Kubernetes environment, and I could see using Azure/AWS/GCE for machines hosted in one of those environments.

Mechanism	What the agent presents	Typical fit
aws_iid	AWS EC2 instance identity evidence, verified against AWS	Agents running on EC2
gcp_iit	Google Compute Engine instance identity evidence, verified using GCP APIs	Agents running on GCE
azure_imds	Azure instance metadata/identity evidence	Agents running on Azure VMs
azure_msi	A signed token obtained through Azure Managed Service Identity	Azure nodes with managed identity enabled
k8s_psat	A Kubernetes projected service-account token, verified by the server against the Kubernetes cluster	Agents running in Kubernetes; the plugin specifically attests nodes inside Kubernetes
x509pop	A provisioned X.509 certificate plus proof of possession of its private key	Environments with an existing certificate-provisioning or machine-PKI process.
sshpop	SSH host-identity evidence plus proof of possession of the associated private key	Environments that provision and manage SSH host certificates/keys
tpm_devid	TPM-backed device identity evidence	Hardware-backed node identity where compatible TPMs are available
jointoken	A pre-provisioned, one-time join token	Bootstrap or environments where cloud/hardware attestation isn’t available; the token itself must be provisioned and protected
http_challenge	A challenge/response that checks the agent is reachable at a valid DNS name	Specific DNS-reachable deployments; it is not equivalent to hardware-backed instance identity

Second, when an application connects to the agent’s local Workload API, the agent establishes facts about the calling workload. Depending on the configured attestors, those facts can include its Unix UID, systemd unit, or Kubernetes namespace and service account. Registration policy determines which SPIFFE identity those facts entitle the workload to receive. The application does not simply say “I am Agent XYZ” and get XYZ’s credentials.

Access to the Workload API socket is therefore necessary in this local integration, but not sufficient: the calling process must also satisfy the identity’s registration policy. The important boundary is which workload may obtain the credential, rather than possession of a pre-provisioned application secret.

There is an important limitation: attestation controls issuance, not every subsequent use. If an attacker steals an issued certificate and its private key—or a bearer JWT-SVID—the credential can potentially be used outside the original workload until it expires. Workload isolation, credential protection, audience restrictions, and downstream authorization remain essential. SPIFFE reduces reliance on long-lived secrets; it does not make credential theft impossible.

 

Term	Meaning in this context
SPIFFE ID	Workload identifier; not a secret or credential by itself.
SVID	SPIFFE Verifiable Identity Document: a cryptographically verifiable identity document carrying a SPIFFE identity.
JWT-SVID	SPIFFE JWT identity document with intended audience; not universally an OAuth access token.
SPIRE	Workload identity implementation providing attestation and issuance.
STS	Security Token Service: validating evidence and issuing tokens under policy.
Subject	Principal whose authority is represented by the token.
Actor	Party exercising delegated authority; current actor is the outer act.
OAuth client	Client registration/authentication identity, distinct from subject and actor.
Delegation grant	Protected application approval/authorization context; implementation-specific.
Audience	Intended recipient context enforced by the agreed token profile.
Sender constraint	Token use requires possession of an associated presenting key.
Revocation window	Measured delay before every relevant enforcement point denies authority.