Agents outlive their keys — their identity should too

Part 1 ended with a running system: an autonomous agent that holds nothing but a session key, buying a real market report every hour, every gate enforced in the authorization path, one revoke() from frozen. Then the obvious next question walks in: the key expires in seven days. It gets rotated. Is the thing that comes back "the same agent"?

In a credential-only system, no. Identity is credential-granular: the ledger knows key 0xC48e…, not the buyer behind it. Rotate the key — hygiene you want, expiry-as-forced-check-in was the whole point — and history fractures. Spend records, behavior, anything you'd call reputation: reset to zero, per rotation. The safer an agent operates, the less anyone can ever know about it. That's exactly backwards.

Card networks solved this — for humans

A card network never confuses the card with the cardholder. PANs get reissued, network tokens get rotated per merchant, and none of it touches the thing that matters: the cardholder persists, and credit history, disputes, and risk profile ride on the person — not the plastic. The token vault is precisely that mapping: disposable credentials on top, one durable identity underneath. Twenty years of maintaining it is why a bank still knows you after your tenth reissued card.

Agentic payments has no cardholder row yet. x402 identifies a payer as "whatever key signed". AP2's mandate chain anchors to the human user, but the agent in the middle is anonymous plumbing. Mastercard's per-agent tokens come closest — one token per agent, killable individually — but there identity is the credential: kill the token and the "agent" evaporates with it, history and all. And Ethereum's ERC-8004 draft — identity, reputation and validation registries for agents — is the field putting in writing that this gap is real and unclaimed.

Two kill switches, not one

Conflating the agent with its key also conflates two very different emergencies. A leaked key is a card problem: cancel it, issue a new one, business continues. A misbehaving agent is an employment problem: no key it holds should ever work again. Part 1's revokeSession() is the first switch. Nothing at the credential layer can give you the second — you can't fire someone by cancelling their card.

dfmi's answer: ninety lines of registry

AgentRegistry is deliberately as small as the wallet it complements. register(name) mints a permanent agentId. bindKey(agentId, key) attaches each newly granted session key to it — a key belongs to at most one agent, ever. deactivate(agentId) is the second kill switch: identity-level, irreversible, with every bound key's history preserved. Fire the agent; keep the record.

The part that matters is where attribution happens: the facilitator resolves key → agent at settlement time and writes agentId and agentName into the public ledger, in the same motion that settles the payment. Keys rotate; the ledger's memory of report-buyer doesn't. Reputation finally has somewhere durable to live — and the owner console does the bookkeeping automatically, binding each new key as it's granted.

The 24×7 agent from part 1 is still buying, every hour — but now the public ledger names it. Same process, same budget, same offline signatures. What changed is that its history finally accumulates somewhere that survives its keys — and its owner now holds both switches: cancel a card, or fire the agent.

What identity still doesn't solve: the credential says how much, the identity says who. Neither says what for. An offline-verifiable binding from "the user wanted X" to "this specific charge, at this stranger of a merchant, is inside X" — the intent layer — remains the unbuilt prize of this whole field, and part 3's territory.

Everything here is drawn from public protocol documentation and standard payments practice. No proprietary anything — just twenty years of scar tissue, read from the outside, and a registry dfmi built because its own ledger kept forgetting who was buying.