Put a spending check in the API so the Agent gets an understandable rejection before preparing an unusable operation. Put the enforceable spending rule in the execution path that moves the funds. Review both against the same asset units and policy identity.
Agent Wallet Guard offers a concrete local example. Its historical demonstration rejected a request for 101 MockUSDC against a 100 MockUSDC single-payment limit during API preparation. Balances, Guard spending and the nonce were reported unchanged. That demonstration establishes an API rejection. A separate reading of the current contract shows per-payment and daily budget checks, which need their own execution evidence.
Identify the actual authority
The local product uses an independent Node runner as the Agent. The Owner authorizes a public session-key address under an existing policy. The runner signs and submits payment operations, while the Owner retains the ability to revoke the session. This scope does not include autonomous LLM purchasing decisions or a hosted Agent service.
The API's local payment check reads the configured asset, policy and session state. It checks recipient eligibility and paused state before comparing the requested amount with the single-payment limit and cumulative daily spend. This gives the caller a useful early result, including a specific limit error.
A request can bypass a particular frontend or API. The account and Guard therefore remain the relevant places to inspect for execution constraints. ERC-4337 describes bundlers packaging UserOperations for an EntryPoint and account-defined validation. Merely using that architecture does not supply an application's spending policy; the actual account and Guard behavior must implement it.
Define what the daily number measures
The Guard's budget key includes the account, Agent, policy, token and day. Its implementation uses UTC day buckets. The single-payment comparison permits equality with the limit, and the cumulative comparison rejects an amount that would exceed the daily budget. Accepted spending is recorded in the same bucket used by the check.
These details determine what a dashboard may honestly say. A number scoped to one policy is not automatically a wallet-wide budget. A UTC calendar day has a reset boundary that differs from a rolling 24-hour period. A token amount also needs its raw unit; a displayed 100 without an asset and decimals is incomplete policy information.
The current local policy demonstrates 100 MockUSDC per payment and 1,000 per day. Those are demonstration settings. A new deployment needs an agreed budget scope and a review of how creating or replacing policies affects that scope.
| Boundary | Current source behavior | Evidence still needed for a deployment |
|---|---|---|
| API preparation | Reads chain policy and rejects excess amount | Direct API rejection with unchanged state |
| Guard execution | Checks per-payment and cumulative budget | Operation submitted past the API boundary |
| Budget identity | Account, Agent, policy, token and day | Cross-session and policy-change cases |
| Time window | UTC calendar-day bucket | Cases immediately around the boundary |
| Owner revocation | Session authorization can be revoked | Prepared operation submitted after revocation |
Exercise concurrent requests
Two requests can both pass an API read of the remaining allowance before either executes. A proposed review should prepare two payments whose combined amount exceeds the remaining daily budget, then submit both through the supported execution path. Compare the resulting transfers and cumulative spend with the policy limit.
The contract source checks and records spending during execution. That is a stronger place to enforce the total than an earlier API snapshot. This source inspection is not a reported concurrency test result. The downloadable matrix leaves the case unrun and asks for transaction evidence from the deployment being assessed.
Keep failed and successful operations distinguishable in the evidence. Capture the relevant budget bucket before and after, the recipient balance and the account nonce. If gas costs matter to the business limit, define a separate rule for them. A token-transfer cap does not describe a gas budget unless the implementation explicitly accounts for it.
Report the layer that rejected the request
The historical local demonstration also records revocation followed by two rejection paths. The API refused further preparation, and a previously prepared, correctly signed operation submitted directly to Alto was rejected at Guard validation. That supports a revocation claim at the execution boundary. It does not turn the separate 101 MockUSDC API case into an onchain limit test.
Use the same precision in acceptance reports. Name the checked layer, requested raw amount and observed state changes. The worksheet includes equality, one raw unit above the limit, combined concurrent spending and the UTC reset boundary. All cases are marked Not run.
Download the spending boundary review matrix.
Agent Wallet Guard is a local prototype using MockUSDC. Production permissions, new policy creation flows and deployment security review require separately agreed work.
