Machine Identity, Explained: Ours Revokes and It Does Not Expire
The established field, and what actually defines it
Machine identity is older than the agent conversation. Service accounts, certificates issued to servers, and workload identity systems that hand a running process a credential proving what it is have been ordinary infrastructure for years.
The defining property is not the format. It is the lifetime. A workload credential is issued to a process, lives for minutes or hours, and is replaced automatically before it lapses. Nobody revokes it, because nothing lasts long enough to need revoking.
That is the design. Short lifetime converts a stolen credential from a permanent problem into a brief one, without anybody noticing the theft.
What we issue, and the column that is not there
We issue an identifier and a credential bound to an agent, not to a process, and the credential states who owns the agent and what it may do.
The credentials table has an issue time and a revoke time. It has no expiry column. Not an unused one, not a nullable one waiting to be filled: the concept is absent from the row.
So an ownership or capability credential we sign is valid until somebody revokes it. There is no moment at which it stops on its own.
And the mitigation is real, so here it is at the same volume
Revocation is not an afterthought bolted on. Every credential carries a pointer into a signed status list, and that list is re-signed and re-advertised on a short refresh interval.
Two intervals exist, deliberately. The general one is sixty seconds. One list refreshes every ten, because for time-critical authorisations a revocation has to reach a counterparty within seconds rather than within a cache lifetime.
That is a well-built revocation path, and a page that led with the missing column while hiding this would be misrepresenting the system.
The asymmetry that survives the mitigation
Revocation is an action. Expiry is a default.
A system whose only invalidation is an action fails open over time. For a credential to stop being valid, somebody has to notice, decide and act. For a short-lived credential to stop being valid, nobody has to do anything at all.
Every forgotten agent, every operator who stops paying attention, every credential issued for a project that ended, stays valid. Not because a check is missing, but because nothing counts down.
The key does not rotate either
Under the custody our adapters use, the signing key is generated once and kept, encrypted, by the backend. There is an export path and it does not rotate anything: it returns the key and leaves the stored copy in place.
So neither half of the identity ages out. The credential has no expiry and the key has no rotation, which means the lifecycle has exactly one ending, and somebody has to perform it.
It does not interoperate with the machine identity you already run
Measured rather than characterised: zero. A search across the backend and the shared package for certificate, workload-identity and cloud access-management vocabulary returns nothing at all.
CONTROL: the same search paths return thirteen files for key-algorithm vocabulary, so the searcher works and the zero is an absence.
There is no bridge, not a partial one. If your infrastructure already issues identity to workloads, nothing here plugs into it, and saying so is more useful than implying a migration path nobody has built.
Why the two are not the same job, without excusing the gap
A workload identity answers a question inside one operator's infrastructure: may this process call that service, right now.
A credential answers a question across a boundary: what can somebody who does not run your infrastructure, and has no account with you, check about this actor.
Those are different questions and both are real. What the shared word "identity" hides is that the established field solved the lifetime problem decades ago and we have not. Borrowing the vocabulary without inheriting the property is the thing to watch for, in our copy and in anybody else's.