Your agent authenticates with a long-lived key in an environment variable, and one successful exfiltration replays it for a year. All four systems here fix that, properly, and the difference between them is mostly where the trust anchor lives. What none of them fixes is the half of agent identity that 2026's incidents are actually about — an agent that is perfectly authenticated while doing what a web page told it to. Buy workload identity for the machine layer, know that it buys you nothing against the confused deputy, and pick on trust anchor and policy plane rather than on features.
At a glance
Three of these speak SPIFFE. One of them mostly consumes it.
| System | What it is | Trust anchor | What the agent ends up holding |
|---|---|---|---|
| SPIRE | Reference implementation of SPIFFE; CNCF-graduated since 2022 | Your own trust domain, run by you | An X.509 or JWT SVID, default one-hour lifetime, auto-rotated |
| Teleport Machine & Workload Identity | SPIFFE-compatible issuance inside a broader access platform | Teleport's CA, federatable with SPIRE trust domains | The same SVIDs, plus one audit log shared with human access |
| AWS IAM Roles Anywhere | Exchange for AWS credentials from outside AWS | AWS Private CA, or a CA certificate you upload | Temporary AWS credentials for a mapped IAM role |
| HashiCorp Vault | Secrets broker that accepts an identity and issues secrets | An external SPIFFE authority, or Vault's own auth methods | A dynamic database credential, a short-lived cert, a leased secret |
What workload identity fixes — and the half it does not touch
The half that is genuinely solved
SPIFFE's mechanism is attestation rather than a stored secret. SPIRE attests in two stages — first the node, then the workload running on it — and issues a SPIFFE Verifiable Identity Document from that evidence, with no bootstrap secret to provision. The private key is generated locally and never transmitted. The default X.509 SVID lifetime is one hour, and the agent renews around the half-life, so a credential that is somehow captured is worth minutes, not a year. For an agent process this is strictly better than any key-in-a-vault arrangement, and it is worth doing on that basis alone.
The half that is not
An SVID attests a process: this binary, on this node, in this namespace. It says nothing about which user's request the agent is currently serving, and nothing at all about the fact that the current turn's instructions arrived inside a retrieved document. Every one of these systems will cheerfully issue a valid identity to an agent in the middle of executing an injected instruction, because from the attestation layer's point of view nothing is wrong — the right process is making the call.
That is the confused deputy, and it is a different product. Per-user delegation lives in a consent record and a per-task token; per-task scoping lives in your tool layer; the question of what is in the context lives in taint tracking. Workload identity is the floor. Treating it as the ceiling is how teams end up with a beautifully rotated credential to exactly the same god-role they had before.
SPIRE — the highest ceiling, and the one you operate
What it does
SPIRE is the SPIFFE runtime: a server holding the trust domain and its registration entries, and an agent on each node performing node and workload attestation and serving SVIDs over a local Workload API socket. It issues X.509-SVIDs for mTLS and JWT-SVIDs for things that cannot do mTLS, federates across trust domains, and is the substrate several service meshes already sit on.
Where it stops
SPIRE gives you identity and leaves authorisation to you. Its registration entries are a policy store you now own and must keep in sync with reality — and for agent fleets, reality changes when someone edits a deployment. The common failure is not cryptographic; it is that a pilot turns into an operations project bigger than the problem it was started for, with a datastore to run and entries to garbage-collect.
Who it fits
Teams with more than one cloud or more than one orchestrator, who need a vendor-neutral trust domain and already have platform engineers who will own it. Also anyone who wants federation with a partner's trust domain, which is the case none of the others handle as cleanly.
Teleport — SPIFFE without the registration database
What it does
Teleport's Machine & Workload Identity issues the same SPIFFE IDs and SVIDs over the same Workload API with the same trust bundles, so standard SPIFFE SDKs work unmodified, and it can federate with SPIRE-managed trust domains. The difference is the policy surface: a WorkloadIdentity resource maps to Teleport's existing role-based access control, managed through the same CLI and Terraform provider as everything else, with no parallel registration database to maintain.
The part that matters for agents
Human access and workload access run through one control plane and land in one audit log. For agent work that is not a convenience — it is the difference between being able to answer "who or what touched this system in March" as a single query, and joining two systems that disagree. It also supports TPM-based node attestation and can act as the CA trust anchor for AWS Roles Anywhere, which removes the AWS Private CA line item below.
Who it fits
Organisations that already run Teleport for human access, and teams that want the SPIFFE plane without staffing it. The trade is the obvious one: you are inside one vendor's control plane, and the federation story is what keeps that from being a one-way door.
AWS IAM Roles Anywhere — narrow, cheap, and done by Friday
What it does
You register a trust anchor — either a reference to AWS Private CA, or a CA certificate you upload from your own PKI — and a profile that binds that anchor to one or more IAM roles and sets the session duration. A workload outside AWS presents its certificate and gets temporary AWS credentials for the mapped role. The service itself carries no per-request charge.
Where it stops
It issues AWS credentials, full stop. If your agent also calls a Postgres instance, an internal service and a SaaS API, Roles Anywhere solves one quarter of the problem and you are back to a secret for the rest. It is also not a general identity plane: there is no workload attestation, only possession of a certificate, so the strength of the whole thing is the strength of whatever issues those certificates.
The cost note
The service is free; the CA is not. AWS Private CA's general-purpose mode runs around $400 per month plus per-certificate issuance, with a short-lived-certificate mode at roughly an eighth of that — and short-lived is what you want for agents anyway. An external CA, including one fronted by Teleport, removes the line entirely.
Who it fits
An agent running on your own hardware or another cloud whose downstream calls are overwhelmingly AWS. This is the smallest possible amount of work that deletes a static access key, and for a lot of teams it is the right first move.
Vault — it consumes an identity better than it mints one
What it does
Vault's job is the step after identity: turn "I am this workload" into a database credential that expires, a certificate for this connection, or a leased secret with a revocation path. Its SPIFFE auth method accepts and validates SVIDs issued by an external authority such as SPIRE — it does not generate them — while a SPIFFE secrets engine can mint JWT SVIDs, and Vault Enterprise 1.21 added native SPIFFE identity issuance for non-human workloads.
Why the distinction matters
Teams reach for Vault and think they have adopted workload identity. What they usually have is a better secret store with the same bootstrapping problem moved one layer down: something still has to prove to Vault who it is. Pair it with a real attestation source and the combination is excellent. Deploy it alone with an AppRole secret ID baked into an image and you have a rotating credential guarding a static one.
Who it fits
Almost everyone, as the second component. It is the right answer to "my agent needs a Postgres password that expires" and the wrong answer to "prove which process this is".
What actually decides it
Across all four, the axis that never appears in a comparison table is what the identity unlocks. Attestation quality is a real difference — SPIRE and Teleport prove which process is asking; Roles Anywhere proves possession of a certificate — but it is second-order if the SVID maps to a role that can do everything. The useful exercise is to list your agent's capabilities and check that each identity unlocks a narrow set of them, which is the blast radius question wearing an IAM hat.
The second axis is breadth. Roles Anywhere terminates at AWS; Vault terminates at whatever it has a secrets engine for; SPIRE and Teleport terminate at anything that can verify an SVID, which in practice means anything you also control. An agent calling three third-party SaaS APIs is not served by any of them, and that reach stays in OAuth tokens held per user.
When to pick which
| Situation | Start with | Add next | Watch for |
|---|---|---|---|
| Agents outside AWS, calling mostly AWS | IAM Roles Anywhere | Short-lived CA mode, or an external CA | The Private CA line item, and role scope creep |
| Multi-cloud or multi-orchestrator fleet | SPIRE | Vault behind it for downstream secrets | Registration entries drifting from deployments |
| Teleport already in place for humans | Teleport Workload Identity | Federation with a partner SPIRE domain | One control plane is also one dependency |
| "My agent needs a password that expires" | Vault | A real attestation source in front of it | A static AppRole secret ID under everything |
| Agent acts for individual end users | None of these alone | Per-user tokens and consent records | Assuming the SVID answered the question |
FAQ
Does a one-hour SVID actually help if the agent is compromised while running?
Not during the run — an attacker with code execution simply uses the live identity. It helps against everything else: a credential lifted from a log, an image, a backup or a leaked env dump is worth minutes rather than indefinitely, and it cannot be replayed from somewhere the attestation does not hold.
Can I give each agent task its own identity instead of each agent process?
Not with attestation, because attestation describes the process and a task is not a process. The usual construction is a stable workload identity for the process plus a short, narrow, per-task token minted on top of it — two credentials with different lifetimes, and the second one carries the authority.
Is SPIFFE overkill if we only run on Kubernetes?
Often yes at first. Kubernetes service account token projection with OIDC federation to your cloud covers a lot of ground with no new infrastructure. SPIFFE earns its cost when you cross a boundary Kubernetes does not span — another cloud, bare metal, or a partner.
Where does MCP fit in this?
An MCP server is another workload and should hold its own identity rather than share the agent's. The authorisation an MCP call needs is generally user-scoped, so it rides on OAuth rather than on the SVID; see MCP auth.
What single change gives the most security per hour spent?
Deleting the longest-lived static credential your agents hold and replacing it with any of these. After that, the highest-value hour goes to narrowing what the resulting identity can reach, not to improving the attestation.
Further reading
On this wiki:
- Agent Identity & Permissions — authentication, authorization and attribution as three separate questions.
- Ambient Authority — the reach that no credential store lists.
- Agent Identity & Attestation — the mechanism in depth.
- Scoped Credentials for Agents — narrowing what the identity unlocks.
- Access Reviews for Agent Credentials — what to do with the grants once they exist.
Product documentation:
- SPIFFE concepts and the SPIRE documentation.
- Teleport Workload Identity with AWS Roles Anywhere.
- The IAM Roles Anywhere trust model.
- Vault SPIFFE auth method.