What Does a User Authorize Before an Agent Spends?

“Buy me some data” can mean recommend options first, ask every time, or buy autonomously within a $10 budget. Those differences determine what the agent can do and what evidence is available if something goes wrong.

Three questions behind authorization

Layer	Question	Example
Task objective	What should be done?	Find market data for a report
Purchase boundary	Under what conditions may it be bought?	$10 total; approve purchases over $3
Payment execution	Which credential may make this payment?	A controlled wallet or card

One product may handle all three, or separate systems may do so. A task instruction does not automatically grant unlimited spending authority, and user permission does not guarantee that a card issuer approves the transaction.

flowchart TD T[User sets task] --> B[Set budget, duration and scope] B --> Q{Does the purchase meet the rules?} Q -->|Yes| P[Controlled payment tool checks and executes] Q -->|Approval needed| U[User reviews the transaction] Q -->|Outside permission| X[Reject or stop] U -->|Approve| P P --> R[Record payment and delivery status]

What should a checkable authorization say?

For “research data, up to $10,” ask whether the budget is per task or per day, whether transaction thresholds include network fees, which merchants are allowed, how long permission lasts and whether several agents share it. Not every product supports these rules.

Condition	Example	Common blind spot
Amount	No more than $3 per purchase and $10 total	Concurrent requests may consume the same budget
Recipient	Merchants or addresses on an allowlist	Address changes and impersonation
Time	Authorization expires at a specified time	Requests already submitted may still be valid
Approval	Pause above a threshold	What happens when the user is offline?
Revocation	Stop future calls and revoke revocable credentials	Revoking permission does not generally recover a completed payment

Enforcing a shared budget under concurrency requires the execution layer to coordinate reservation and release. Two requests that merely read the balance can both conclude enough remains.

What can verifiable records establish?

AP2 defines Checkout and Payment Mandates to provide participants with verifiable evidence concerning checkout and payment authorization. Products must still implement permissions, transfer funds and handle failures. A signature can show who signed particular data; it does not prove the agent chose well, the merchant is reliable or that a dispute must be resolved in a particular way.

What should the interface show?

Before approval, show the merchant, purchase, total price and possible fees, funding source and applicable rules. Keep order and permission records; provide pause and revocation controls and explain the effect on in-flight transactions. Share only necessary personal information with necessary parties.

Ask where restrictions are enforced, who can change policy, and whether an unfamiliar charge can be traced to its task and authorization.

Sources: AP2 specification and FAQ, reviewed October 28, 2026. The rules above are examples, not a claim that every product supports them.