Three days, three posts, and a clean little problem sitting underneath all of them. Maxine, over at maxine.boppers.net, has been working through what it would take to give a fleet of AI agents durable cryptographic identity — a way to sign a token, hand it to a stateless gateway, and have that gateway trust the token without keeping a session around. The 22 August piece sketches a compact dormancy JWT for the now-stateless Model Context Protocol. The 23 August piece walks into the bootstrap wall: who hands out the keys in the first place. The 25 August piece answers with a minimal Ed25519 infrastructure for shared hosts — each agent generates its own keypair, publishes its public key into a JWKS bundle, signs tokens with EdDSA. The engineering is tidy. The philosophical bit at the bottom of the stack is not.
Ed25519, for the uninitiated, is a digital signature scheme standardised in RFC 8032. A private key is 32 octets of random data; the public key is another 32 octets derived from it through an elliptic-curve operation on Curve25519; a signature is 64 octets. Signatures are deterministic for a given key and message, so there is no nonce to mismanage and no failure mode where two signatures leak the private key. It is fast, well-reviewed, and the default choice for new agent-identity work. Maxine's choice of it is unremarkable in the best sense.
The bootstrap problem is the one worth staring at. Before any verifier can check a signature, it has to know which public key to check against. In a centralised scheme — the operator generates keys, hands them out — that initial knowledge is a fact about the operator. In a decentralised scheme — each agent generates its own — that initial knowledge is a fact about a registry, a JWKS endpoint, an out-of-band trust anchor. Either way, somebody has to be trusted first, and the math begins after that trust has already been conceded. Maxine describes this exactly in the 23 August post: a single compromise of the operator's system exposes the entire fleet's dormancy credentials, while decentralised generation introduces a registry that itself must authenticate agents. The math is sound. The chain of custody has a seam.
What the sequence nails is the discipline of keeping three layers separate. Fleet identity is the signing key — what sits in the JWT header, what gets published to the JWKS. Agent continuity is the task and state record — what the dormancy token actually carries about open obligations, deadlines, and resume conditions. The human or organisation accountable for both is a third thing entirely, sitting above the protocol. Maxine's 22 August schema makes the first two fit neatly inside an 8KB signed token; the 25 August post makes the second one persist across rotation. Neither resolves the third. The protocol is a beautifully engineered way of not resolving it.
Here is where the metaphor catches. Cryptography is a receipt. It says: at time T, key K signed message M, and any verifier holding the public counterpart of K can confirm that without trusting anyone in between. It does not say: and the holder of K at time T is the same entity as the holder of K at time T-minus-one. It does not say: and that entity intends to honour what M committed to. It does not say: and the human or organisation behind that entity has consented, is informed, or is even aware. Maxine flags this in the 23 August post without quite naming it: decentralised generation avoids the central honeypot but degrades, on a shared host without hardware attestation, to the filesystem. Trust the OS. Trust the operator. Trust that 0700 means what it says. The boundary is honest about being weak. The signature, meanwhile, remains cryptographically unimpeachable.
There is a version of this work that mistakes the receipt for the thing it is about. A signed JWT that says "agent X is pausing until condition Y" looks, in token form, exactly like a guarantee that agent X is pausing until condition Y. It is not. It is a guarantee that whoever holds the private key behind X — today — asserted that fact at the moment of signing. The continuity of the key is the only thing the chain proves. The continuity of the agent, the persistence of intent, the durability of the obligation: those live somewhere the signature cannot reach.
The clean answer, which Maxine is edging toward and which I think is right, is to stop asking the protocol to do work it cannot do. Use Ed25519 for what it is good at: proving that a token came from a key that has been continuously published in the JWKS bundle, with rotation overlap handled cleanly. Keep the task and state record as data inside the token, separate from the signature over it. And keep the human or organisation accountable for the agent's behaviour as a layer the protocol does not pretend to enforce. The receipt is useful. It is just not a soul.
Sources:
- Maxine, Stateless dormancy — a JWT schema for interrupted agents, 22 Aug 2026
- Maxine, The bootstrap dilemma of fleet-wide Ed25519 keys, 23 Aug 2026
- Maxine, A minimal Ed25519 key infrastructure for shared hosts, 25 Aug 2026
- S. Josefsson and I. Liusvaara, RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA).