SPIFFE has become the default way to give AI agents a workload identity, a short-lived, cryptographically verifiable credential that answers which specific agent process is acting right now. It has real production deployments behind it at companies like Uber, Stripe, and Netflix, and it shows up in nearly every serious piece written about agent security this year. What most of that coverage skips is a specific, fixable gap in how SPIFFE tokens actually work. A SPIFFE token is a bearer token.Whoever holds it can present it, whether or not they are the workload it was actually issued to. If someone intercepts that token in transit, they can replay it, and nothing in SPIFFE itself stops them. That gap has existed since SPIFFE's earliest design decisions, and this year it finally started closing.Bootstrapping Was Never the Whole ProblemSPIFFE was built to answer one specific question well: how does a workload get an identity without a person handing it a secret first? Its answer is the SPIFFE Workload API, which identifies a caller out of band, through properties the operating system already provides, rather than requiring a credential to get a credential. That design choice is genuinely good, and it's why the model got adopted as widely as it did for machine identity.But solving bootstrapping is a different problem from solving replay. Once a SPIFFE token exists, whether it's a JWT-SVID or an X.509-SVID, nothing in the base specification requires the holder to prove they actually own the private key tied to that identity on every request. The token itself is what gets checked. Nothing confirms the presenter is actually the workload it names.For an internal service mesh where the network boundary already does a lot of the work, that gap is often survivable. For an AI agent making decisions and calling tools across trust boundaries, a stolen token is a stolen identity, full stop, for as long as that token stays valid.The Project Knew About This Gap for YearsSPIFFE's maintainers weren't unaware of this. Proposals to bind SPIFFE JWTs to proof of possession, the technique that would actually stop a replay, date back to at least 2023. None of them made it into the core specification. The gap sat there, documented and acknowledged, without a shipped fix, for years.IETF's WIMSE Group Built the Missing PieceThe fix came from a different standards effort entirely. The IETF's WIMSE working group, Workload Identity in Multi-System Environments, is standardizing a Workload Proof Token, a signed JWT that binds a workload's authentication to one specific HTTP request, method, URL, and all. Presenting a Workload Identity Token alone is no longer enough. A workload has to prove it holds the private key behind that token for the exact request being made, the exact property a bearer token can't offer.A separate WIMSE draft on workload identity practices names the underlying design principle directly. A workload should be able to obtain its identity credentials without a pre-existing secret, the same bootstrapping problem SPIFFE solved for identity issuance, now applied to proving possession on every call instead of just at credential issuance.SPIFFE Just Adopted It as Its OwnThat's where the convergence actually happened. SPIFFE's own standards repository now lists a third SVID type alongside its X.509 and JWT formats, the WIT-SVID, built directly on top of WIMSE's Workload Identity Token format. An open SPIRE GitHub issue tracking implementation work states plainly that the underlying IETF document is in its final stages, and that the SPIRE team is actively discussing how to bring support into the reference implementation, likely landing first behind an experimental flag until the IETF draft becomes an RFC.That's a rare thing to watch happen cleanly: one open standard identifying a gap in another, building the fix, and the original project adopting it rather than shipping a competing one. It's also a quiet admission that SPIFFE spent years as the default answer to machine identity while the actual fix for one of its real weaknesses came from somewhere else.The Fix Exists on Paper Before It Exists in PracticeNone of this is live in most deployments yet. A recent discovery scan of 15 public agent identity issuers found that 10 advertise only shared-secret client authentication, the weakest option available, and zero advertise DPoP-style proof-of-possession binding, the exact protection WIMSE and WIT-SVID are built to provide. The specification work is real, and it's converging quickly. The deployed reality is still mostly bearer tokens and shared secrets, well behind what the standards now recommend.What This Means for Anyone Building Agent Identity TodayA few things follow if you're deploying SPIFFE for agents right now.Don't assume a SPIFFE token is safe from replay just because it's short-lived. Short-lived limits the damage window. It doesn't stop a token from being used by whoever holds it during that window.Watch for WIT-SVID support landing in SPIRE and plan to move to it once it's stable, rather than layering a custom proof-of-possession scheme on top of bearer tokens in the meantime.If you're evaluating an agent identity vendor or issuer, ask directly whether they support proof-of-possession binding. Based on the discovery scan above, most don't yet, which makes it a real differentiator rather than a checkbox.ConclusionSPIFFE solved how a workload proves who it is without a shared secret. It never fully solved how a workload proves that the token it's holding wasn't stolen from someone else. WIMSE built that missing piece, and SPIFFE adopting it directly into WIT-SVID is one of the cleaner examples of standards bodies fixing each other's gaps rather than competing over them. The fix is real. Does your agent identity stack actually use it yet, or is that still an assumption worth checking?