Holder’s agent wallet provides safe online payments with encryption

A guest essay on payments by Tom Shepherd, a Rust developer and full-stack engineer. Sources are linked.

June 8, and about 200 people

On June 8, 2026, MetaMask let about 200 people in an early-access program hand a trading agent a wallet of its own, and on August 6 it announced the Agent Wallet was live for anyone running Claude Code, Codex, Cursor or one of three other agent tools. The agent could swap, bridge, trade perpetuals, bet on prediction markets and park funds in yield vaults, inside limits the user set, with a threat scan and MEV protection on each transaction, by MetaMask’s own description. A smaller product, Holder, took the other road the same summer: the keys stay in the user’s browser, the agent gets an API key with a spending limit and an allow list, and a smart contract on the chain enforces the limit rather than the app.

A wallet is a good place to watch the work between humans and agents change, because a wallet was explicit about who is acting long before agents arrived. It holds something scarce. It signs instructions that cannot be undone. It has to tell the user who owns the account from the software asking to use it. An agent joining that relationship moves the design assumptions, and the two products show the same move from two directions.

The second loop

In a conventional wallet the user is present at the moment of action: an app proposes a transaction, the wallet explains it, the user taps approve, the wallet signs. An agent wallet adds a second loop around the first. The user states an intent, the agent finds a route and proposes, a policy checks the proposal, the wallet signs or escalates, and the user reviews what happened afterwards. The user has not left the loop. Their part moved earlier, into writing the authority, and later, into exceptions and review.

A task like “keep this balance earning yield” does not fit one confirmation dialog. The agent has to discover protocols, compare routes, wait for conditions, retry failed calls and adapt when prices change. The user cannot approve that work by reading a hexadecimal transaction at intervals of a few minutes. So the interface stops asking the user to approve gestures and starts asking them to draw an envelope the agent may act inside.

A budget is the first control

Holder makes the envelope visible as Spending Keys and policies. A key can be limited by account, network, asset, transaction template, value per transaction and spend over a period, and a new key starts with spending switched off. A request inside the envelope goes through; a request outside it becomes an approval or a refusal. MetaMask presents the same authority as a set of named workflows in its agent-skills repository: swap, bridge, transfer, earn, perpetuals, prediction markets, payments, each with the steps the agent follows and the fields it may not change. The two products differ in what they show, and share one rule: give the agent durable capability, and keep its authority smaller than the user’s. That rule is the Permissions pattern, and the questions on the screen are the ones that pattern lists.

The agent interprets; the policy decides

People state goals: swap enough to pay this invoice, move idle funds into a conservative lending market, keep at least $500 liquid. A chain accepts exact calls, amounts, accounts and signatures. The agent sits between the two languages and translates. Both products keep the translation and the authorization apart. MetaMask’s workflow files teach the agent how to turn a request into a supported operation; Holder ships a SKILL.md so an agent can reason about capabilities, quotes, approvals and transaction states, and then the wallet applies the user’s policy on its own rather than trusting the agent’s reading. The agent plans; a narrower, deterministic system decides whether the plan may run. That split is the one the Approval and Delegation patterns describe from the user’s side.

A secret the agent uses and not once reads

An agent needs a credential to act, and a credential pasted into a prompt, a transcript, an environment dump or a tool result becomes part of a very large surface with no clear edge. Holder’s credential flow, as its author describes it, moves the secret out of the conversation: a local helper receives a new Admin or Spending Key through an encrypted pairing session and stores it in the macOS Keychain, a Linux secret store, a systemd credential, Bitwarden or Proton Pass. The agent receives a reference that is not a secret. On each call to the Holder API, trusted local code fetches the credential and signs the request in one step. The agent knows what the credential permits; the runtime knows where it lives; neither has to say the value out loud. MetaMask hides the same hand-off inside its onboarding and pairing, which is the other way to reach the same end: the access an agent has in a conversation and the access it has to a secret should be two different things.

Pairing is a small ceremony

In Holder’s agent-initiated flow, the target machine creates a short-lived pairing code. The user types it into the unlocked wallet, reads which machine is asking and for what, and authorizes delivery. The durable key travels encrypted to the helper, and not through the chat. The direction of the code carries the meaning: it starts on the agent’s machine and comes back through the user’s hands, so the user confirms this is the machine they mean to equip. Agents will need more of these ceremonies, because they need to acquire authority without asking people to become security engineers. A good one says four things with little effort from the user: which machine is asking, what it will receive, where the secret will live, and how to revoke it later. Signing into a new device already works this way; pairing adds the scope of authority to the event.

Supervision moves to the exceptions

A conventional wallet interrupts on each request, at the moment the user has the least context. A policy wallet turns that around: routine activity runs inside the envelope, and the wallet brings the user back when an action is novel, large, outside the allow list or hard to read. The user’s screen stops looking like a remote control and starts looking like an operations console: an activity inbox in place of a stack of pop-ups, a notification that says why attention is needed, a decoded description of the call, trusted metadata about the app that made the request, a one-tap preset for a risk posture, and a clear line between proposed, authorized, signed, submitted and confirmed. Holder’s plainer screens give a less AI-native user a legible model of limits and scope; MetaMask’s simpler agent experience shows the opposite pressure, that most of the machinery has to disappear before an agent wallet becomes an ordinary tool. The likely end is both at once: intent first on top, inspectable custody and policy underneath. On this site that escalation is the Off-Brief Alert, and the console is Observability with a budget attached.

The skill file is part of the product

MetaMask’s repository splits into references, which describe the command-line surface, and workflows, which describe repeatable procedures for onboarding, swaps, bridges, perpetuals, prediction markets and earn. The files tell an agent which tools exist, in what order to call them, which fields must not change, when to ask for approval, how to poll for completion and how to recover from an error. They shape the product’s behaviour as much as its application code does. Holder is moving to the same shape, a root skill that routes the agent into references for credentials, policy, quote schemas and security invariants, and into workflows for sends, swaps and bridges. The human interface explains and controls authority; the agent skill explains and controls procedure; the API exposes actions and state; the policy system decides what may proceed. The skill file is the agent’s interface, and someone has to design it.

The wallet as shared state

A field note on this site describes several agents orienting themselves through one shared artifact that was not designed for them. A wallet can be that artifact on purpose. Balances, pending transactions, policy limits, approvals, quote expiries, signer availability and the activity record form one operational picture. The user reads it to see what the agent is doing; the agent reads it to see what remains possible; a second agent reads it before it proposes. If that state sits in logs, coordination happens by accident. If it is explicit, the wallet can carry several actors without pretending they share one mind, which is the problem the Agent-to-Agent pattern names. Shared state then needs rules of authority: who may propose a change, who may approve it, which record wins, whether two agents can spend the same remaining budget, and what happens when an approval, a cancellation and a signer’s reply arrive in the same second. A contradictory state is a broken conversation between participants, and a database engineer will not fix it alone.

Open questions, and one instruction

None of the eight is settled. The two products have not decided whether the wallet should run the agent’s cloud browser or only receive proposals from it, or whether the signer should share the agent machine’s uptime or live on a more isolated host. An authorization given in chat has no agreed path to durable, structured policy. The wallet still has no way to verify an app’s metadata without trusting the agent’s word, and authority has no safe way to follow an agent from one machine to the next without a transferable key becoming the weakest link. The direction is visible even so. The useful agent products will not remove the user from the loop; they will redraw the loop so the user contributes judgment where judgment matters, the agent contributes attention and procedure where those are scarce, and a third layer holds the agreement between them. A wallet stops being a container for keys and becomes the place where a user and an agent decide what acting together means.

Before you ship an agent that can spend, write the envelope as a screen the user can read in a minute: what the agent may do while they are away, how much and over what period, which apps and assets, what it did while they were gone, and what makes it stop and ask. Then put a stop next to that screen, and make sure the secret that lets the agent act does not appear in the chat that asked for it.