In the Agent Payments Protocol, a mandate is only worth what the key that signed it is worth. The merchant’s willingness to ship, the issuer’s willingness to authorize, the non-repudiation story you tell a dispute board — all rest on one claim: that signature could only have come from this user’s wallet. The wallet is therefore not a balance or a card list. It is the custodian of signing authority, and its architecture is the architecture of that claim. This piece stays on the key material: who holds it, where it is generated and stored, what happens during a signing request, how an agent gets scoped power without touching the key, and how you rotate and recover without breaking signatures the world already relied on.
The wallet is where signing authority lives
Strip a payment wallet down and two things remain: a private key and a policy about when it is allowed to be used. The public half is published so anyone can verify; the private half is the asset. A wallet that protects the key perfectly but applies no policy will sign whatever an attacker asks. A wallet with beautiful policy but a leaked key protects nothing, because the attacker signs directly and never visits your policy engine.
Agentic payments raise the stakes on both halves. In a card checkout the human is present at the moment of authorization. In AP2 an autonomous agent may act hours later, unattended, against a mandate the user signed once. The wallet has to keep a key usable by software the user is not watching, without making it usable by software the user never sanctioned. That tension — available to the agent, unavailable to everyone else — drives every design choice below.
Three custody models and what each asks you to trust
Custody is the first fork, and it asks one question: who can physically produce a signature?
| Model | Who holds the key | You trust | Fails when |
|---|---|---|---|
| User-held | The user’s device alone | Device hardware, and the user | Device lost, stolen, or offline when the agent acts |
| Custodial | Provider infrastructure | Provider controls and staff | Provider is breached, compelled, or misidentifies you |
| Threshold (MPC) | Nobody — split shares | Non-collusion of holders | Enough holders collude, or go dark together |
One distinction is worth being precise about, because the terms get swapped constantly. Multi-signature collects several signatures from several keys and the verifier sees all of them. Threshold signing (MPC) is different: shares held by different parties cooperate to produce a single signature, and the full private key is never assembled anywhere. Multi-sig is visible to the verifier and changes the mandate’s shape; MPC is invisible to it and changes only the operator’s risk.
Key generation: where the private key is born
The most consequential moment in a wallet’s life happens before it signs anything. If the key is generated on a server and delivered to a device, it existed outside that device — in memory, possibly in a log or a backup — and no amount of later hardening retracts that. Keys should be born inside the boundary that will protect them and never leave it.
Two properties decide whether that boundary is real. First, entropy: the key must come from a hardware random source, because a predictable seed makes every later control theatre. Second, non-extractability: the platform must create a key handle the application can invoke but cannot read. That is the difference between a key stored in secure hardware and a key merely protected by secure hardware — the second is decrypted into ordinary process memory every time it is used. Ask a wallet vendor which of the two they do; the answer tells you most of what their custody claim is worth.
Hardware roots of trust — enclave, TEE, HSM
Three hardware options recur, and they defend against different attackers. A phone’s secure enclave is a separate coprocessor with its own memory; it performs the signature internally and returns only the result, so a compromised application — even a rooted OS — can request signatures but cannot exfiltrate the key. It defends against software compromise of the device, not against someone holding the unlocked device.
A TEE is the same idea generalized to server silicon: a protected execution region isolated from the host OS and hypervisor, which lets a custodial or MPC operator run signing logic their own infrastructure team cannot read. An HSM is the heavyweight: a tamper-responding appliance that zeroizes its secrets under physical attack, with dual control and audited key ceremonies around it. Enclaves scale to millions because each user brings their own; HSMs concentrate risk, and demand concentrated discipline.
The signing ceremony when an agent asks
When an agent needs authorization, the wallet is not being asked to unlock. It is asked to bind a specific statement of intent to a specific key. A sound ceremony has four beats, and skipping any of them is where wallets get robbed.
Present. The wallet renders what is about to be signed, in human terms, from the bytes that will actually be signed — not from a friendly summary supplied alongside them. If display and payload can disagree, the user is signing blind. Authenticate. A user gesture — biometric or device passcode — releases the key handle for one operation. Sign. The private key operation happens inside the hardware boundary; only the signature crosses out. Record. The wallet logs which key signed what, when, and under which authentication method — the evidence you will need months later when someone claims they never agreed. Unattended agent runs skip the second beat by design, which is precisely why they need the delegation machinery that follows.
Delegation: scoped authority without handing over the key
The naive way to let an agent transact is to give it the key. That is always wrong: it converts a bounded grant into permanent, unlimited, unrevocable authority, and it destroys the wallet’s ability to tell the user’s signature from the agent’s. The correct shape is a delegation credential: the wallet uses the root key once to sign a statement that a named agent key may act within stated limits, and the agent holds only its own key.
The limits are what make delegation safe, and they should be narrow on every axis at once — amount, currency, merchant or category, transaction count, and a validity window in hours rather than months. The verifier then checks a short chain: the agent signed this, the user’s wallet authorized that agent, and the action fits the authorized bounds. The root key stays in hardware and is exercised rarely — exactly the property that lets you protect it with expensive, high-friction controls.
Session keys and the blast-radius calculation
A session key is delegation taken to its logical end: a freshly generated keypair, authorized for one errand, expiring on a timer. It exists so the material sitting in an agent’s process — the material most likely to be stolen, because it lives in ordinary memory on ordinary infrastructure — is worth as little as possible when it is.
Reason about it as blast radius: compromise of this key exposes how much money, over how long, at how many merchants? Root key compromise is unbounded until revocation propagates. Session key compromise is bounded before the incident happens, and that pre-commitment is the entire value. The cost is lifecycle machinery you must actually build: issuance, expiry, refusal to renew silently, and a revocation path verifiers consult rather than one you merely publish. A short-lived key whose expiry nobody checks is a long-lived key with better marketing.
Rotation without orphaning outstanding mandates
Keys have to change: staff leave, devices are replaced, algorithms age, policy demands rotation. But a wallet that rotates naively breaks its own past. A mandate signed last month by the old key still has to verify next month, or every recurring authorization built on it silently becomes unverifiable.
The mechanism is to make signatures reference a key identifier, not ‘the wallet’s key,’ and to publish key history with validity windows so a verifier resolves the key valid at signing time. Then note the tension that makes this hard: rotating a healthy key must preserve everything the old key signed, while rotating a compromised key must invalidate it. Same operation, opposite requirement — so the two cannot share a code path. Retirement marks a key as no longer valid for new signatures; revocation marks it untrustworthy from a stated moment and forces re-authorization of everything downstream of it.
Recovery: reconstruct the key, or never reconstruct it
Recovery is where most wallet designs quietly reintroduce the risk the rest of the architecture removed.
Seed-phrase backup pushes the problem onto the user and whatever they wrote it on. Shamir sharding splits a secret among holders so a threshold can restore it — but note what restoring means: the key is reassembled in plaintext on some machine, and that machine is now the most attractive target in the system. Social recovery lets designated guardians approve issuance of a fresh key, replacing a cryptographic problem with a human one — guardians can be impersonated, pressured, or unreachable. MPC re-sharing is structurally cleanest: shares are refreshed and a lost one replaced without the full key ever existing. Whichever you choose, a recovered wallet should re-establish authority rather than inherit it, because you cannot know what the lost device did after it left your hands.
The hard problems — lost device, coercion, compromise
Three cases resist clean answers, and an honest architecture states its position on each.
Lost device. The key may be intact in hardware and merely unreachable, or in an attacker’s hands with your unlock. You usually cannot tell which, so treat loss as potential compromise: revoke, do not merely retire. Coerced signing. Cryptography cannot distinguish a willing thumb from a forced one — biometrics arguably make coercion easier, not harder. The only real mitigations are non-cryptographic: value ceilings, delays on unusual high-value grants, a second party for large ones. Key compromise. Detection is the weak link, because a stolen key produces signatures that are perfectly valid. So the practical defence is never ‘prevent compromise’ but bound it in advance: narrow delegations, short lifetimes, per-key limits, and monitoring that flags signing patterns rather than waiting for a rejected signature that never comes.