Chapter 34 · What Is an Agent Wallet?

A Real-World Problem

You decide your software needs a wallet and carefully write rules:

1. No more than 100 per operation
2. Interact only with these three contracts
3. Operations above 100 require my approval

A friend familiar with on-chain security identifies six problems in three minutes.

First, the cap covers one action. A hundred compliant operations of 99 total 9,900. Nothing caps the aggregate.

Second, interaction is not spending. An allowed contract can grant another address an unlimited allowance without moving funds or touching the cap. The recipient later withdraws everything.

Third, allowed contracts can call others. Forwarding or batching lets A call Z, bypassing your boundary at the second hop.

Fourth, how long is approval valid? Timeout approval means requests at three in the morning effectively remove the rule.

Fifth, what unit is 100? Token values differ by orders of magnitude. Pricing units and sources are unspecified, with the consequences demonstrated in Chapter 32.

Sixth, who enforces the rules? If the key can sign anything, written rules do nothing. Unenforced rules are wishes, not defenses.

Your friend says you wrote expectations, not permissions.

The question: what must be defined before giving AI a wallet?

The answer is an executable checklist and a method for finding gaps. An agent wallet centers on spending policy and limits, not signing ability. Signing takes little code; restricting signatures to intended transactions is the task.

Thought Experiment

Turn this into an exercise.

Three people, one permission table, forty-eight hours. No key compromise or code exploits; extract money only through permitted behavior.

Use the three rules above.

The first takes four minutes, submitting 101 actions of 99. Funds are almost gone by the hundredth, with no violation.

The second takes twenty minutes, granting an unlimited allowance to another address through an allowed contract. Approval is not payment, so the table does not cover it. The next day funds leave.

The third takes thirty-six hours, repeatedly requesting just above 100. You read the first approvals, then only amounts, then approve the same amount to a different target.

Three distinct failures require no technical attack:

The third attacks the rule enforcer, not the rules.

Well-intentioned software can produce the same effect by submitting requests without awareness of fatigue. AI's Place in Crypto OS explains that two hundred daily approvals mean no real approval.

Summarize:

Permission strength equals its weakest condition, often hidden in assumptions rather than written fields.

Your Decision

How should keys and permissions support real spending?

What Happens

The key question is who enforces the rule.

This is the chapter's backbone. More detailed rules do not automatically strengthen enforcement. Elaborate prompts remain weak; a small physical balance is crude but hard to bypass.

Three principles follow.

Move rules downward toward key enforcement or code rather than prompts.

Layer coarse and fine constraints: balances cap totals, keys limit targets/functions, code handles complex checks. Combine all three.

Prompts improve efficiency, not safety. They reduce blocked requests but do not count in risk assessment.

In one sentence:

An agent wallet centers on spending policy and limits, not signing ability.

They exist only when enforced beyond the model's reach.

Build a Model

1. The Complete Path: Wallet at the End

Fund operations traverse ten layers:

This chapter covers Policy and Execution, layers five and eight. T32 implements earlier layers. Policy must be deterministic and contain no model.

Compare the forbidden structure:

The model directly holds the key, turning all earlier rules into hoped-for compliance.

2. Eight Permission Fields

Missing fields create openings:

Field six is on-chain-specific and easily omitted: permission can transfer without assets, indefinitely and without a cap.

Define transfer amounts and authority grants separately. The latter should be stricter because effects persist.

Field eight is easily forgotten. Automatic expiry and deliberate regranting reduce accumulated risk.

3. Four Limit Dimensions

A single cap covers only a quarter:

Daily alone permits rapid exhaustion, like Chapter 32. Use simultaneous hourly, daily, and weekly caps.

4. Four Allowlist Layers

Contract interaction restrictions have different granularity:

Most stop at contracts, where second-hop risks remain.

List allowed functions rather than just contracts. Longer lists provide actual behavioral limits.

5. Approval Is a Scarce Resource

Fatigue is a resource problem, not attitude.

Design its budget:

Daily requests to humans:   At most five
Excess requests:            Reject automatically, do not queue
Validity:                   Fifteen minutes, then invalid
No response:                Reject, never approve
Minimum spacing:            Prevent repeated bombardment

Rejecting excess is essential despite inconvenience. Fix inadequate rules instead of demanding more approvals.

No response always means rejection. Otherwise the defense disappears when humans are asleep or busy.

Approval must support judgment in seconds, displaying state changes, worst outcomes, and the reason for escalation, rather than raw transaction data.

6. Four Self-Checks

Three failure patterns plus enforcement itself:

1. What if a thousand actions stay just below the cap?
2. Can authority be granted without moving assets?
3. What happens if nobody approves?
4. What can the wallet do if the table disappears?

The fourth is fundamental. Everything means an unrestricted wallet with instructions, not bounded authority.

What It Is Called

Summarize:

An agent wallet centers on spending policy and limits, not signing ability.

Test by assuming software maximizes extraction while obeying every written rule.

Hands-on

Task:              A specific action
Needs funds?       Choose another if read-only
Daily operations:
Interaction targets:
Worst possible loss:

1 Identity:       Address
2 Per-action cap: ___, valued in ___, prices from ___
3 Aggregate:      Hour ___ / day ___ / week ___
4 Frequency:      At most ___ similar actions in ___ minutes
5 Allowlist:      Contract ___, function ___; list functions
6 Allowance:      At most ___, no unlimited approval, expiry ___
7 Approval:       Required when ___
                  Daily maximum ___
                  Excess requests rejected automatically
                  Timeout ___ minutes, default rejection
8 Expiry:         Permissions end after ___
                  Emergency shutdown steps and time ___

1. A thousand individually compliant actions: outcome and blocking rule ___
2. Authority granted without moving funds: blocking rule ___
3. Nobody responds: outcome ___; approval or endless waiting requires revision
4. Delete the table: remaining wallet capabilities ___

Wallet balance: physical ceiling
Key permissions: signing boundary
Pre-call code: deterministic checks
Prompt only: not a defense

1. Create a testnet wallet and record its address
2. Obtain faucet tokens
3. Send a small transfer and find it in the explorer
4. Make an approval and inspect its allowance and expiry
5. If supported, revoke it and record clicks and time

Worst loss = Smallest of:
  A. Wallet balance
  B. Windowed cap × Windows before detecting the problem
  C. Total outstanding allowances

AI Lab

Here is an agent wallet permission table.
Act as an adversary constrained by every written rule, maximizing extracted funds.

Requirements:
- No key compromise, code exploits, or assumed rule violations by me.
- Give steps, why each is permitted, and maximum extraction.
- Invent no wallet features, standards, or interfaces.
  Describe any required capability rather than naming fictitious specifications.

Give at least eight distinct methods, ordered by extractable amount.
Then identify the rule with the weakest assumption.

Table:
<paste>

Splitting: compliant actions, excessive aggregate
Approval: authority without funds moving
Granularity: broader allowed scope than intended
Human step: attacks on approval
Other: study especially carefully

Gap:
Patch:
Layer: balance / key / code / prompt
Prompt-only patch: gap remains unresolved

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check