AI Agent Wallets Explained

By Nika, NodeTimes newsroom.

An agent wallet is not a wallet but a permission set: a smart account that holds the funds and a scoped signing right that lets the agent act inside limits you defined. The question that matters is not where the key is stored but what the agent can sign, for whom, up to what amount, and how that right is taken away. Everything below follows from that shift: once the object of control is a permission rather than a key, the design work moves into scope, limits and revocation.

A wallet is a permission set, not a key

Giving an agent a key gives it your whole balance; giving it a permission gives it exactly the actions the policy allows, and nothing outside them.

Smart account: an account whose rules are code, so that a valid operation is one the account itself accepts, which may mean a signature from an authorised signer, a call to a specific contract, or both. Session key: a separate signing key that has been authorised by the account for a limited purpose, rather than the account's main key. Scope: what that key is allowed to do, expressed as allowed targets, allowed functions and a time window. Policy: the rule the account applies to a proposed operation before accepting it, such as a spending cap or a recipient allowlist.

The practical consequence is that the agent never needs to hold anything valuable. It holds a right to instruct, and how that right is actually spent on the settlement rails is set out in the explainer on agentic payments, while the funds stay behind the account's own validation logic.

• What the agent gets: a signing right with a scope, a lifetime and a ceiling.
• What the agent does not get: the ability to move funds outside that scope, or to widen the scope itself.
• What the operator keeps: the account, the policy that defines the scope, and the ability to withdraw the right.

Custody models compared

Custody models differ along one axis: who actually produces the signature, and therefore what a compromise of the agent costs. That makes custody the storage half of the same question: the model decides what can be signed and who has to sign it, not only where a key sits.

The shared-key row is the one to recognise in your own setup, because it is the default result of giving an agent a private key and calling it an integration. The last two rows trade a single point of signing for coordination: an MPC threshold does not remove the risk, it changes who has to collude before a wrong payment can happen, and a signing service inside a protected environment still depends on the policy you configured there. How one platform approaches the wallet-security side of that picture is set out in the wallet platform comparison.

Session keys and scoped signing

A session key is a separate signer with an expiry and a defined area of action, designed so that losing it costs the allowance rather than the account.

The mechanism comes from account abstraction: on a modular smart account the session key is installed as a validator module with policies attached, and each proposed operation is checked against those policies before the account accepts it. A policy can bound the target contract, the function being called, the total value moved and the period during which the key is valid; the account refuses anything outside that envelope. Practical implementations also require the account owner to sign the session into existence, so a session cannot be created by the agent for itself.

A session key is not a second password, and the difference is what makes it useful:

• It cannot be rotated only when you remember to: it expires on its own, and the account stops accepting it.
• It is not a copy of the main key: revoking it does not require reissuing the account's own signer.
• It is not a blanket approval: what it can move is bounded by the policy, not by the balance.

Where the agent pays in tokens rather than in the chain's own currency, the same bounding logic appears at the token level: an allowance for a specific spender contract is itself a ceiling, and what a token is and how approvals work is set out in the explainer on tokens.

Limits, allowlists and a stop switch

Limits and allowlists are what turn a leaked agent credential from a loss of everything into an incident with a known maximum.

Three controls do most of the work, and they are worth configuring before the agent sees any funds. A per-transaction ceiling bounds the worst single mistake. A rolling limit over a period bounds a loop that repeats a small payment. A recipient allowlist makes the destination of an incorrect payment a set you chose, rather than an address chosen by whoever is prompting the agent.

• Pause: a switch that stops new operations while keeping balances and history, for use during a suspicion rather than after a loss.
• Revoke: withdrawal of the session itself, which is the only control that works after a key is known to be compromised.
• Escalate: routing anything above the ceiling to a human approval step instead of refusing it, which keeps the agent useful at the edges.

The stop switch has to be reachable when the agent is misbehaving, which in practice means it lives with the human and not with the agent: a revocation that requires the agent to cooperate is not a control. Neither is an alert that nobody reads, so the useful version of monitoring is a limit that fails closed plus a notification on every refusal.

What stays with the human

Three things stay with the human in every workable design: the policy, the recovery key, and the record of what the agent did.

The policy is the actual control surface, since the session key is only an instance of it. Whoever can edit the policy can widen the agent's scope, so that ability has to sit with the same person who can move the funds. The recovery key is the second element: if the account's own signer is held by the agent or by the same infrastructure the agent runs on, there is nothing left to revoke with once the agent misbehaves. The audit log is the third, and it is what makes an incident reviewable: which operations were proposed, which were refused by policy, and which signer produced each accepted signature.

• Policy: a human-owned configuration, changed deliberately rather than by the agent's runtime.
• Recovery: a signer the agent never sees, kept where the agent cannot read it.
• Audit: an append-only record of proposals and refusals, sufficient to reconstruct an incident.

The workflow question follows from this division: an agent that can request a wider limit is useful, while an agent that can grant itself one is a liability, and the difference is not in the agent's code but in where the policy lives.

How agent wallets fail

Agent wallets fail in three recognisable ways, and each has an early signal that is visible before any money is lost.

The first failure is a scope that is too wide: an agent authorised for a whole contract when it needed one function, or for the account's full balance when it needed a budget. The signal is a permission that cannot be described in one sentence, and the fix is to start from the smallest envelope the task can run in. The second is the absence of revocation: a session key without an expiry, or an allowance that stays in place after the integration ended. The signal is a permission with no owner and no end date, and it is the most common one because nothing breaks at the moment it is created.

The third is a leaked session key with no ceiling behind it, where the scope was technically correct but nothing bounded the amount. The signal is a policy with no ceiling line of its own, and the fix is a ceiling on the session rather than on the scope.

Before granting access, confirm that the answer to each of these is a fact rather than an intention:

• The scope names the contracts and functions, and the agent has no path to anything else.
• The key expires without anyone remembering to revoke it, and revocation is possible today.
• The ceiling is low enough that losing the key is survivable, and refusals raise an alert.
• The human signer is not stored where the agent can read it.

Credential theft is the surrounding risk rather than the agent-specific one, and the shapes it takes in an agent's environment, from hostile prompts to a compromised dependency, are described in the overview of crypto threats.

Frequently asked questions

Does an AI agent need its own wallet?

A separate wallet exists so that the damage from an agent's mistake is bounded by its allowance rather than by the balance it was pointed at.

It is not a convenience feature; it is the control that makes the rest of the design meaningful.

What is a session key?

A session key is a separate signing right with a limited scope and a limited lifetime, which the account can withdraw without reissuing its main signer.

That is why it is not a second password: it expires and it is scoped, while a password is neither.

Can spending limits really contain a leak?

Yes, if the limits and the recipient allowlist are in place before access is granted, because then a leaked key can only spend what the policy allows.

A leak under a ceiling is an incident with a known maximum, and a leak without one is the whole account.

Is MPC safer than a smart account?

They solve different problems: threshold signing removes the single signer, while a smart account defines the rules an operation has to satisfy.

In practice the two are combined: the policy sits on the account and the signature is split across parties.

Who is responsible when an agent pays wrongly?

Responsibility starts with whoever issued the permission, because the policy and the recovery key are held by a person and not by the agent.

The technical form of that answer is simple: the human owns the account, so the human owns the consequences.