How to Add Spend Limits and Mandate Verification to x402 and AP2 Agent Payments

TL;DR

• The proposed integration adds a per-payment limit, a cumulative daily limit, and signed mandate verification at payment-authority release, before an approved payment reaches its rail.
• Native x402 (opens in a new tab) and AP2 (opens in a new tab) validation runs before policy normalization. A shared atomic ledger then reserves cumulative liability by logical payment, budget, asset, network, and accounting window.
• In wallet-backed x402, the gate controls signing. In other AP2 flows, it can control credential release or payment initiation.
• Inherence compiles the mandate’s formalized policy rules into an inline gate and produces a policy receipt containing a 128-byte compressed zero-knowledge proof.
• The protocol-agnostic layer works alongside x402 and AP2. The worked example covers wallet-backed, fixed-amount exact x402, including x402 authorized by AP2.

Why agent payments need spend limits and mandate checks

Native x402 and AP2 controls provide the foundation for agent payment policies. x402 offers pre-signing spend controls, including a per-payment cap and allowed assets. The AP2 authorization framework (opens in a new tab) requires deterministic mandate-chain validation, constraint evaluation, and failure on unknown constraints. AP2 can also authorize x402 payments, so implementations may process both protocols for one logical payment.

Per-payment controls do not independently impose a cumulative daily ceiling. A compromised agent could issue many fixed-amount x402 payments that each remain below the configured cap. If separate payment paths maintain separate counters, the agent could also consume the same intended budget through each path. A shared ledger must reserve maximum liability atomically before payment authority is released.

AP2 already defines cumulative budget evaluation. The Payment Mandate (opens in a new tab) requires the requested amount plus accumulated prior closed-mandate amounts to remain within the maximum, followed by an accumulated-total update after approval. A conforming verifier should reject replayed, expired, altered, or over-budget mandates. Exposure remains when an implementation skips native checks, races parallel approvals, or permits another release path to bypass the authoritative budget state.

Passive logs and post-settlement alerts identify violations after payment authority has produced an executable action. They cannot recover the preventive control that was absent before release. An escrow provides the appropriate model. It releases value only after defined conditions hold, and no covered path can bypass those conditions. The architecture described here applies that model at payment-authority release and represents a proposed integration pattern rather than a demonstrated adapter integration.

Implementing shared policy enforcement for x402 and AP2

x402 defines an HTTP-native payment handshake and several settlement schemes. Its buyer flow (opens in a new tab) applies built-in spend controls, including a per-payment cap and allowed assets, before custom policies and payload signing. Developers can add dynamic checks through on_before_payment_creation, then verify the resulting authorization under the selected scheme.

Settlement timing depends on the x402 scheme. The exact scheme covers fixed amounts, while upto authorizes a maximum liability and later settles actual usage. Batch settlement (opens in a new tab) verifies vouchers off-chain and redeems them later. A policy layer must reserve the maximum exercisable liability until unused authority expires or becomes unusable.

AP2 defines signed intent and mandate structures for agent-authorized payments. AP2 does not provide the underlying settlement rail or require every flow to use a wallet signer. Its authorization framework (opens in a new tab) requires deterministic processing of the SD-JWT mandate chain. Verifiers check unchanged claims and evaluate every open-mandate constraint against the closed mandate. Unknown constraints cause failure.

The AP2 Payment Mandate (opens in a new tab) supports payee restrictions, amount ranges, payment instruments, execution dates, recurrence rules, and budgets. Budget evaluation includes accumulated prior closed-mandate amounts and requires an update after approval. A custom daily window remains separate unless the signed policy defines its reset semantics.

A shared policy layer extends these native controls with authoritative cumulative accounting across covered payment paths. The integration must verify each native object before normalization. AP2 verification must preserve the compact SD-JWT, disclosures, key binding, delegation, source binding, and all constraints.

The control point is payment-authority release. Wallet-backed x402 gates payload signing, while other AP2 flows may gate credential release or payment initiation. When AP2 authorizes x402, both adapters must reference one logical payment and one atomic reservation. The payment-identifier extension (opens in a new tab) can provide idempotency when its identifier binds to a fingerprint covering the payment terms, route, and operation ID. This guide presents a proposed integration architecture rather than a demonstrated adapter integration.

Implementing shared policy enforcement for x402 and AP2

The proposed integration places a deterministic policy gate before payment-authority release. The worked path covers wallet-backed, fixed-amount exact x402 payments, including x402 payments authorized through AP2. It describes an integration architecture rather than a demonstrated adapter integration.

1. The agent issues a payment intent. The intent identifies one logical payment, the payer, recipient, amount, asset, network, and proposed operation. An AP2-authorized x402 request carries both native protocol objects through the same path because AP2 defines combined flows (opens in a new tab).
2. The policy engine verifies each native authorization before normalization. For AP2, deterministic validation processes the mandate chain, delegation, key binding, source binding, and every constraint. Unknown constraints cause failure under the AP2 authorization framework (opens in a new tab). For x402, the engine evaluates the unsigned scheme payload and existing authorization before any payment-authorizing signature exists. The engine then applies the mandate’s compiled formalized policy rules and atomically reserves maximum liability against the shared budget.
3. An approval releases payment authority. In wallet-backed x402, the wallet signer signs only the approved payload. Existing x402 tooling already places spend controls and custom checks before payload signing (opens in a new tab). In other AP2 flows, approval may release a payment credential or permit payment initiation rather than invoke a wallet signer. A retry with the same logical payment identifier and fingerprint returns the existing authorization. A changed fingerprint fails.
4. The underlying payment rail executes the approved payment. Settlement converts the active reservation into settled spend without deducting the amount twice. The reservation cannot be released while the authorization remains exercisable.

Inherence’s gate acts like escrow for payment authority. An agent cannot bypass the committed conditions on any action routed through the enforced path. Passive logs and post-settlement alerts can identify violations later, but they cannot prevent signing, credential release, or payment initiation.

After approval, Inherence produces a policy receipt containing a 128-byte compressed zero-knowledge proof. The receipt provides independently verifiable policy-evaluation evidence. Binding its action commitment to the payment authorization and settlement record connects the pre-execution decision with the executed payment.

Defining the mandate schema

Native authorization must pass protocol verification before an adapter normalizes any authenticated claim. For AP2, verification follows the agent authorization framework (opens in a new tab) across the mandate chain. The verifier preserves the original compact SD-JWT and its disclosures. Verification also covers unchanged claims, key binding, delegation, source binding, and every stated constraint. The policy engine rejects mandates containing unknown constraints.

The shared schema separates signed authorization from mutable budget state. Immutable fields identify the signer and signature, the validity window, permitted actions, approved counterparties, and the exact asset and network. Amount fields must use precise units. The signed policy also defines the per-payment limit, budget_id, window limit, window duration or reset rule, and the timestamp used to assign spend to a window. That timestamp may be authorization time or settlement time.

Mutable state tracks consumption without changing the signed mandate. A budget record stores current_window_id, settled_amount, active_reserved_amount, and accepted logical payment IDs. Remaining budget derives from those authoritative values. A shared budget_id lets one limit govern several mandates or payment paths.

Cross-asset budgets require additional signed rules. The policy must identify an explicit rate source and rounding method. It must also define how the engine calculates maximum liability before authorizing payment. Without those rules, amounts in different assets cannot safely consume one budget.

Protocol adapters map verified native data into this schema. An x402 adapter maps the authenticated request context and proposed payment details into the common action, counterparty, asset, network, and amount fields. An AP2 adapter maps the verified Payment Mandate (opens in a new tab) and its amount constraints into the same fields while retaining the original authorization material. One policy engine can then evaluate both protocols without treating normalization as proof of authenticity.

Enforcing per-payment and cumulative daily limits

x402 already provides pre-signing per-payment and asset controls, while an AP2 Payment Mandate (opens in a new tab) can define amount ranges and cumulative budgets. The policy layer connects these native controls to authoritative accounting across covered x402 and AP2 paths. It can also enforce application-specific daily windows when the native mandate does not define the required reset semantics.

The budget ledger calculates spendable capacity with one expression.

available = window_limit - settled_amount - active_reserved_amount

The gate rejects a payment when its maximum exercisable liability exceeds either the per-payment limit or the available budget. Before releasing payment authority, the ledger atomically adds that liability to active_reserved_amount. An exact x402 payment reserves its fixed amount. An upto authorization (opens in a new tab) reserves the authorized maximum because the facilitator may settle any amount within that bound.

Reservations must remain active until the authorization expires or otherwise becomes unable to settle. This requirement applies when a payment authorization can outlive the original request. For example, batch settlement (opens in a new tab) allows vouchers to be redeemed later. Releasing their reservations immediately would let later requests consume budget that the outstanding vouchers can still claim.

Atomic idempotency prevents concurrent requests and retries from spending the same capacity twice. The ledger should compare the limit, create the reservation, and record the logical payment identifier in one atomic operation. For x402, a payment identifier (opens in a new tab) should bind to a request fingerprint. A retry with the same identifier and fingerprint recovers the existing authorization. The gate rejects the identifier when the fingerprint changes.

Settlement moves liability from active_reserved_amount to settled_amount without deducting the amount again. A repeated settlement notification returns the recorded state instead of applying another transition. If accounting occurs only after settlement, concurrent requests can each observe the same available budget and receive signatures that collectively exceed the limit. Pre-execution reservation closes that race before the wallet signer releases authority.

Verifying signatures, expiry, and allowed actions

Each protocol’s native authorization must pass verification before the policy engine extracts or normalizes any claims. Otherwise, normalization could discard signed context or treat unverified data as authoritative.

For AP2, verification processes the full mandate chain under the agent authorization framework (opens in a new tab). The verifier preserves the original compact SD-JWT and its disclosures. Verification also covers key binding, delegation, source binding, and unchanged claims. The verifier must reject unknown constraints rather than ignore them.

Signature verification must establish that the signer controls the relevant account or holds delegated authority for the proposed action. The verifier then checks the authenticated validity window against the applicable authorization time. Expired mandates and mandates that are not yet valid receive a denial before any budget calculation occurs.

Allowed-action checks compare the proposed payment with authenticated mandate constraints. For AP2, those constraints come from the Payment Mandate (opens in a new tab), including permitted amounts, payment conditions, and relevant parties. Counterparty, asset, network, and action identifiers must match exactly where the mandate constrains them.

Wallet-backed x402 follows a different signing order. Before signing, the gate verifies the existing policy authorization and compares the proposed unsigned scheme payload with the x402 payment requirements. The comparison covers the requested action and any constrained payment properties. The selected x402 scheme verifies the resulting payment authorization after the wallet signs it. Implementations must not attempt to verify a new x402 payment signature before that signature exists.

Only authenticated and currently valid claims may enter the amount checks. The gate evaluates per-payment limits next, then performs the cumulative-budget check and atomic reservation. A failure at any earlier integrity check prevents the wallet signer from receiving an approvable payload.

Implementing shared policy enforcement for x402 and AP2

The proposed Inherence integration places an inline enforcement gate between the protocol adapter and payment-authority release. In wallet-backed x402, payment-authority release means signing the payment payload. In other AP2 flows, it may mean releasing a payment credential or initiating funds movement, as described in the AP2 implementation guidance (opens in a new tab). Approved payments then proceed through the underlying payment rail.

Inherence compiles the mandate’s formalized policy rules into an enforcement gate. The gate evaluates signer authority, delegation, validity windows, allowed actions, payees, asset and network requirements, payment limits, and cumulative budget state. Each evaluation runs before payment authority is released. Inherence also produces independently verifiable policy evidence for covered actions.

Protocol adapters must verify native authorization objects before converting their fields into a shared policy representation. For AP2, the adapter preserves and verifies the compact SD-JWT, disclosures, key binding, delegation, source binding, and every constraint. The AP2 authorization framework (opens in a new tab) requires deterministic processing, unchanged-claim checks, and rejection of unknown constraints. For x402, the adapter evaluates the existing policy authorization and proposed unsigned scheme payload before signing, then verifies the resulting authorization under the selected scheme.

Cumulative limits require mutable state outside the signed mandate. The signed policy defines the budget identifier, window, reset semantics, and limits. An atomic ledger records settled amounts and active reservations. A gate approval creates an idempotent reservation bound to the logical payment, request fingerprint, payer, asset, network, recipient, maximum liability, validity period, and accounting window.

When AP2 authorizes an x402 payment, both adapters must reference one logical payment and one atomic reservation. A retry with the same identifier and fingerprint returns the existing authorization. A changed fingerprint fails. Reservations remain active while the associated authorization can still settle.

The worked architecture covers wallet-backed, fixed-amount exact x402 payments, including x402 payments authorized through AP2. It describes a proposed integration architecture rather than a demonstrated adapter integration. Inherence covers actions routed through the defined enforcement path and evaluated against authenticated inputs. It does not establish the truth of every external input, authoritative settlement, or actions executed outside that path.

The zero-knowledge receipt: proving the mandate held

Inherence produces a policy receipt containing a 128-byte compressed zero-knowledge proof for each covered action that passes the pre-execution gate. The complete receipt also contains or references the public inputs and accepted verification configuration. Counterparties, auditors, protocols, and smart contracts can verify it without receiving designated private inputs.

The proof attests only to checks included in its defined proof statement. Checks performed outside that statement require authenticated evidence. Receipt privacy also applies only to designated private inputs. The verifier sees the public statement, while the payment system determines what other transaction information remains visible.

Proof validity alone does not establish approval. A valid proof may encode a rejected decision. Before accepting a receipt, the verifier must confirm the expected policy commitment and action commitment. The verifier must also check the APPROVED decision, accepted key and parameters, context, freshness, record association, and replay rules.

A proof over a budget value does not establish an authoritative and non-conflicting spending history. The atomic ledger establishes settled spend and active reservations across covered payment paths. The receipt proves policy evaluation against the inputs committed in the proof statement.

The receipt provides policy-evaluation evidence rather than settlement evidence. The payment integration must bind the receipt to the payment authorization and corresponding settlement record to connect evaluation with execution. Coverage remains limited to actions routed through the defined enforcement path.

Comparing enforcement points: agent, policy engine, wallet signer

The proposed integration places policy enforcement before payment-authority release. The table scopes wallet signing to fixed-amount exact x402 payments, including x402 payments authorized through AP2.

| Layer | What it sees | What it can block | Evidence it produces |
|---|---|---|---|
| Agent | The agent sees its intent, available credentials, and application state. | The agent can stop its own request, but a compromised agent can bypass voluntary checks. | The agent may produce an intent or mandate request. Its own record does not prove independent enforcement. |
| Policy engine | The engine sees the native authorization, proposed payment payload, applicable policy, and authoritative budget ledger. | The engine can reject invalid authority, expired authorization, unknown constraints, disallowed actions, mismatched assets, or insufficient budget. It can also reserve maximum liability atomically by logical payment ID and request fingerprint. | Inherence can produce a policy receipt containing a 128-byte compressed zero-knowledge proof. The atomic ledger remains authoritative for cumulative accounting. |
| Wallet signer | The signer sees an unsigned x402 payload and the policy authorization bound to that payload. | The signer can refuse to sign unless the protected policy path approves the exact payload. x402 spend controls (opens in a new tab) can also apply caps and asset restrictions before signing. | The signer produces payment authorization under the selected x402 scheme. |
| Settlement layer | The payment rail sees the submitted authorization and the data required by its scheme. | The rail can reject invalid or unusable payment authorization. It cannot reconstruct omitted application policy checks after payment-authority release. | The rail produces its settlement or redemption record. AP2 verifiers may separately return signed mandate receipts under the authorization framework (opens in a new tab). |

In non-wallet AP2 flows, the same control point gates credential release or payment initiation rather than wallet signing. Approved payments then proceed through the underlying payment rail.

FAQs

What happens when a payment exceeds the daily cumulative limit mid-sequence?

The payment-authority gate rejects the payment before releasing signing authority, credentials, or payment initiation. An atomic ledger calculates available funds as the window limit minus settled amounts and active reservations. The gate must retain each reservation until the authorization can no longer settle. AP2 already requires budget evaluation (opens in a new tab) against accumulated approved amounts, while a custom daily window requires explicit reset semantics in the signed policy.

Does this replace x402 or AP2?

The proposed architecture works alongside both protocols. x402 already provides pre-signing spend controls, while AP2 defines deterministic mandate processing (opens in a new tab) and can authorize x402 payments. Inherence adds protected payment-authority release, shared cumulative accounting across covered paths, application-specific policy, and independently verifiable policy evidence. A wallet-backed fixed-amount exact x402 integration gates payload signing. Other AP2 flows may gate credential release or payment initiation instead. The architecture describes a proposed integration rather than a demonstrated adapter.

Can a receipt be verified without trusting Inherence as an operator?

An independent verifier can check the policy receipt cryptographically. The receipt contains a 128-byte compressed zero-knowledge proof and contains or references its bound public inputs and accepted verification configuration. Verification must confirm the proof, policy commitment, action commitment, APPROVED decision, context, freshness, record association, and replay rules. The receipt proves only the checks encoded in its statement. The atomic ledger establishes authoritative cumulative state, and the payment rail establishes settlement.

Does enforcement require changing the wallet signer's key management?

Existing key custody can remain unchanged if the custody system requires every covered signing request to pass through the authorization gate. The signer must validate the approved authorization, bound payload digest, payer, asset, network, recipient, liability, and validity window. Any route that can use the key without that gate remains outside the enforced path.

Conclusion

Agent developers and wallet platforms shipping x402 payments, including payments authorized through AP2 (opens in a new tab), need one protected payment-authority path across every covered route. In wallet-backed x402, that path gates signing. In other AP2 flows, it can gate credential release or payment initiation.

A written spend policy becomes enforceable when deterministic checks and an atomic reservation ledger run before authority release. Inherence compiles the mandate’s formalized policy rules into that gate. A policy receipt then provides independently verifiable evidence of the covered evaluation. Binding the receipt to the payment authorization and settlement record connects policy evaluation with execution.

Developers can build these controls themselves or adopt a compiled policy layer. In either case, deterministic enforcement and verifiable evidence turn policy text into a bounded guarantee. The architecture described here remains a proposed integration, not a demonstrated adapter integration.