Agent

Keys

A passkey account is one passkey and as many keys as you derive from it. The owner key is the root; each session key is the Agent for one runtime, and it can always be derived again from the same passkey. Nothing on this page is stored: the keys exist while the page is open and come back from one touch on the authenticator.

No passkey account is signed in

This page lists the keys derived from a passkey. There are none to list until a passkey is signed in, which takes one touch on the authenticator and stores nothing but which passkey to ask for.

This browser has no WebAuthn, so a passkey account cannot be made or used here.

Authenticators with a confirmed PRF cycle

1Password: any browser with 1Password active, any OS
iCloud Keychain: Safari, Chrome or Firefox on macOS 15 or later; Safari or Chrome on iOS 18 or later
Google Password Manager: Chrome or Edge on Android; Chrome on desktop when signed in to Google
Windows Password Manager: Edge, Chrome or Firefox on Windows 11 25H2 or later
YubiKey 5 series: Chrome on desktop, firmware 5.2 or later
Proton Pass: Chrome on desktop

Known not to return a PRF

Chrome's local profile: desktop Chrome when the passkey is not saved to Google Password Manager
Bitwarden: Chrome on desktop
Dashlane: Chrome on desktop

Which key is the Agent

In Tab the Agent is whoever signs. authorise records the sender as the Agent, and a Settlement moves the Asset from the sender, so the account that signs is the tab. There is no signing on another account's behalf.

So a session key is the Agent for one runtime: it signs its own authorisation, settles its own tab, and its credit history is its own. The owner key is the recovery root: it re-derives every session key from the same passkey, it signs from this Dashboard when nothing else is chosen, and it is never revealed.

Why there is no seed phrase and no custodian

Every key is a function of the passkey's PRF output: 32 bytes the authenticator returns for this host, the same bytes on every device the passkey syncs to. The authenticator holds the passkey. This page holds the derived keys for as long as it is open, then zeroes them. Nobody holds them for you, and there is no phrase to write down because the passkey is the backup.

The other side of that: lose the passkey and the keys are gone with it, and a passkey works only under the host it was made for. Reveal a session key to its runtime while the passkey works. The derivation follows the Mera recipe published at mera.category.xyz, so it can be reproduced outside this page.

One passkey, a second job

The keys come from the passkey's PRF at Mera's fixed account salt. The agent book asks the same passkey for its PRF at a different salt, a fresh random one on every seal, and turns that output into an AES-256-GCM key that encrypts the book. That key never signs, never becomes an address, and exists only during the touch that seals or opens the book.

Giving a runtime a key

Derive the next session key. Its address is fixed by the passkey and the index.
Fund that address with MON for gas. On Testnet the faucet is free; the balance shown beside the signing key is read from the chain.
Authorise a Service as that key. The key signs its own authorisation from this page, so the runtime never has to.
Reveal the key once and paste it into the runtime's AGENT_PRIVATE_KEY. From then on the runtime calls and settles as that Agent, and its tab is its own.