How to Enforce One AI Agent Spending Mandate Across Payment Systems

TL;DR

• One mandate can govern covered payments across tools, wallets, and rails only if every enforcement point uses one authoritative budget state. Separate local spending limits cannot maintain a shared tally.
• The proposed design gives each mandate one budget identity. Atomic reservations prevent concurrent approvals from exceeding the available budget. Retries must reuse the same reservation.
• Each executable authorization must bind its reservation to the exact payment payload. Independently verifiable policy evidence can support a counterparty’s review. The counterparty must still check authorization, freshness, and replay protection.
• These controls govern only actions routed through the defined enforcement path. Evidence evaluated against committed or attested inputs does not establish the truth of every external input or cover payments made outside that path.

Why one mandate breaks down across tools, wallets, and rails

A single spending mandate can exceed its ceiling when separate payment systems approve requests against separate balances. Suppose an agent has $100 remaining under one mandate. A wallet and a second payment path each approve a $70 payment before either sees the other’s authorization. Both checks pass locally, but the agent has committed $140 against a $100 limit.

AP2 requires a verifier to check the mandate chain and its constraints, including whether a payment fits within the cumulative budget. AP2 does not prescribe how separate payment paths must store that total or coordinate concurrent approvals. Inherence’s AP2 versus x402 payment policy guide (opens in a new tab) identifies the need for a shared atomic reservation across x402 and other covered paths.

An x402 client can apply spend controls before signing, but a limit held by that client cannot account for payments another wallet authorizes. Copying the same mandate into each tool copies its rules, not a shared record of committed spending. Multiple valid local approvals can collectively exceed the mandate ceiling.

Comparing where spending controls live today

Each layer can enforce a meaningful control within its scope. None of these layers, by itself, establishes one authoritative budget across unrelated payment paths. A cross-system spending limit therefore needs an accounting state that every covered enforcement point updates, including when an AP2-authorized payment executes through x402.

What "one authoritative budget" actually requires

One authoritative budget requires a single mutable spending state for each mandate budget identity. Every covered payment path must use that state. Signed policy rules define the ceiling, permitted payments, and policy version. A signature does not update the live spending tally. Separate wallet tallies can each approve a payment against the same remaining balance.

Before releasing an authorization, each path must atomically check committed spending plus outstanding reservations against the ceiling. The path then reserves the payment’s maximum liability in the same operation. Under a $100 limit, a $70 reservation leaves only $30 available to a simultaneous request through another tool. The atomic operation prevents both requests from reading the original $100 balance.

Each reservation needs a stable logical payment ID. A retry must reuse that reservation. The enforcement path must also prevent a retry from creating a second executable authorization for the same payment. A payment authorized through AP2 and executed through x402 should count once against the shared budget.

Each executable authorization must also bind to its reservation and the exact payload the enforcement point releases. A changed payee, asset, amount, or other authorized term must fail that check rather than reuse the reservation. The reservation must record the policy version used for its decision. When a payment executes, the accounting state moves its amount from reserved to committed spending. Any unused liability remains reserved until the authorization expires, is reliably revoked, or otherwise cannot execute.

Tracing one logical payment across AP2 and x402

In a proposed AP2-to-x402 integration, one logical payment should consume one shared-budget reservation. For example, an agent with a $100 mandate might use an AP2 authorization to buy a $40 resource through x402. The shared budget should record one $40 liability, not one charge for the AP2 authorization and another for the x402 execution.

Each protocol must complete its own checks before a shared policy service treats its claims as a payment intent. The AP2 verifier (opens in a new tab) checks the mandate chain, evaluates its constraints, and applies its cumulative-budget rules. The x402 client then inspects the unsigned payment terms under the selected scheme and network before signing. The proposed enforcement path can associate authenticated AP2 claims and x402 terms with one logical payment ID after completing the applicable native checks. A normalized record cannot replace either protocol’s native verification.

Before the client signs, the shared budget service should atomically reserve the payment’s maximum executable liability. The reservation must bind to the exact payment terms, including the payee, asset, scheme, network, and authorized amount. A retry with the same logical payment ID must reuse that reservation rather than create another executable authorization. AP2’s running total and the shared reservation also need coordinated failure handling. A failed attempt must not release liability while its authorization can still execute.

For a fixed-amount x402 payment, the reserved liability is the authorized amount. An x402 usage-based scheme (opens in a new tab) can authorize spending up to a maximum, so the shared service must reserve that maximum until unused authorization expires or otherwise becomes unexercisable. After execution, the service reconciles the reservation against confirmed settlement. These accounting steps describe a proposed cross-system design, not a demonstrated AP2-to-x402 integration.

Authenticated claims and counterparty policy

A proposed shared policy service can use identity, payee, and risk claims only when the payment path supplies an attributable, checkable source for each claim. For example, a payment service might attest that a payee passed screening. The policy gate can verify who supplied that claim and whether it applies to the proposed payment. The gate cannot independently establish that the screening result was accurate.

The counterparty must apply its own acceptance rules alongside the agent’s spending mandate. A merchant may reject a payment that fits the agent’s budget if the merchant cannot accept its payment method or verify the payee information it requires. The mandate authorizes the agent’s side of the transaction. It does not require the counterparty to accept it.

Both sets of rules need to evaluate the same payment terms. Before releasing payment credentials or signing authority, a proposed enforcement path should bind the authenticated claims and policy decision to the specific payee, amount, and authorization. Otherwise, a valid decision for one payment could be presented with different terms.

What independent policy evidence establishes

An independently verifiable policy proof can establish that a defined budget check held over inputs bound to its statement, using an accepted verification key. The proof does not establish that the budget ledger recorded every payment or handled concurrent reservations atomically. It also does not establish that a payment settled.

A counterparty must check conditions outside proof validity before accepting a payment.

• The counterparty must confirm that the policy authority approved the policy version and its verification key.
• The counterparty must match the proof’s public statement to the intended payment payload and its native authorization.
• The counterparty must check the source of any authenticated or attested inputs used in the decision.
• The counterparty must check expiry and freshness, then reject a payment identifier or authorization that has already been used.
• The counterparty must match the executed payment to the relevant settlement record when settlement evidence is required.

Inherence provides evidence for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish the truth of every external input or cover actions executed outside that path. A counterparty must still rely on accepted input sources, the authoritative spending record, and controls that keep execution on the enforced path.

Where this architecture stands today

Inherence’s proposed cross-system payment design would pair pre-execution policy enforcement for covered actions with independently verifiable policy evidence. Its AP2 and x402 integration remains under technical review and is not a shipped integration. The material available for this guide does not demonstrate working AP2 or x402 adapters, a shared reservation ledger, or bindings between policy evidence and settlement records.

The AP2 versus x402 guide (opens in a new tab) covers protocol mechanics in more detail. The agent payment mandate explainer (opens in a new tab) covers mandate enforcement and compliance-timing cases.

Conclusion

Cross-system mandate enforcement requires shared spending state and a defined enforcement path. A vendor or protocol choice alone cannot establish either requirement. A buyer evaluating any provider, including Inherence, should ask whether every covered payment uses the same authoritative budget and how concurrent payments reserve funds against it. The buyer should ask what a counterparty can verify independently and which acceptance checks remain its responsibility. The provider should also identify any payment path that the mandate does not cover.