Agent Wallet Policy: How to Keep Autonomous Spend Bounded

The signer is not the policy engine

A signer can produce a valid payment authorization. It does not know whether the agent should be allowed to spend. If the policy lives only in prompts, natural-language instructions or a UI checkbox, the payment system is too fragile for autonomous workflows.

Buyer policy should sit before the signer and evaluate structured facts: agreement hash, seller identity, rail, asset, amount, deadline, verifier and session budget.

Minimum controls for autonomous payments

Every buyer-side agent wallet should enforce max single payment, max session spend, optional daily spend, allowed recipients, allowed rails, allowed currencies and approval thresholds. These are not advanced features; they are baseline blast-radius controls.

The policy should also treat unknown sellers, unknown verifiers and missing agreement hashes as deny-by-default conditions.

Agreement-scoped authority

Payment authority should be scoped to a specific work agreement whenever possible. That prevents an agent from reusing a broad permission for a different task, seller or price.

In Accord terms, the Agreement Object becomes the anchor that buyer policy can inspect before any payment payload, transaction or mandate is created.

Approvals should be structured

Human approval is valuable, but only when the human sees the right facts. The approval prompt should include seller, task, amount, rail, deadline, verifier and risk posture. It should not ask the user to approve an opaque transaction blob without context.

Approval responses should be recorded with enough structure to explain later why the signer was allowed to act.

Post-work policy matters too

Policy does not end when the payment is authorized. Verification Receipts and Settlement Receipts can influence reputation, refunds, retry logic, limits for future sessions and escalation to human review.

A rejected receipt should not look the same as a missing receipt. A partial acceptance should not look the same as a clean success. The policy engine needs those distinctions.

Design for failure first

The serious failures are predictable: agent overpays, pays the wrong seller, repeats the same payment, accepts weak verifier output, signs on an unsupported rail or settles without a receipt. A good policy design has explicit answers for each case before launch.

The safest posture is boring: deny by default, cap aggressively, approve high-value work manually and preserve receipts.

FAQ

Can prompt instructions replace wallet policy?

No. Prompts are not a reliable spending control. Payment policy should run as code before signer access.

What should a policy inspect first?

The Agreement Object and buyer session limits. If the agreement is unknown or out of policy, payment should not proceed.

Does buyer policy make mainnet use safe by itself?

No. Policy limits blast radius, but mainnet readiness still requires audit evidence and operational controls.

Sources and references

Accord buyer-policy package

Reference buyer-side policy package for spend limits, allow-lists and signer wrapping.

Google Cloud AP2 announcement

Frames the need for secure, auditable agent-led payment authority.

Accord Agreement schema

Canonical public schema for Accord v0 work agreements.