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

What AP2 receipts prove

An AP2 Mandate Receipt records a signed authorization result for an identified mandate. A separate Payment Receipt records payment status. Neither receipt independently proves that an additional application policy was evaluated.

TL;DR

• AP2 verifies mandate chains, evaluates native constraints, issues signed Mandate Receipts, and supports cumulative budgets. x402 clients can apply spend controls before signing. The proposed Inherence integration would add a shared application-policy check before payment authority is released.
• In the proposed integration, native x402 (opens in a new tab) and AP2 (opens in a new tab) checks would precede claim normalization. A proposed shared service would reserve liability across covered payment paths.
• In a proposed wallet-backed x402 integration, the gate would control signing. In other proposed AP2 integrations, it could control credential release or payment initiation.
• The proposed Inherence integration would evaluate defined policy rules before authority release. Its policy receipt would use a compressed zero-knowledge proof as one component. Independent verification would also require access to bound public inputs and accepted verification configuration.
• The proposed layer would work alongside x402 and AP2. The wallet-backed, fixed-amount exact x402 path described here is an integration example, including when AP2 supplies authorization.

What native AP2 receipts prove

An AP2 Mandate Receipt records a verifier’s signed authorization result for an identified mandate. A separate Payment Receipt records payment status; neither receipt, by itself, proves that an additional application policy was evaluated. Its signature attests that the named verifier returned that result for the mandate identified by the hash. The Payment Receipt may include payment-service-provider or network confirmation identifiers.

AP2 supports deterministic mandate-chain verification, native constraints, signed Mandate Receipts, and cumulative budgets. Under the AP2 authorization framework (opens in a new tab), a verifier checks the full SD-JWT mandate chain and its delegation. The verifier checks bound claims and rejects unknown constraints. AP2’s native checks do not establish that a separate application policy engine evaluated the action.

Additional independently verifiable policy evidence must identify the policy, action, decision, and verification configuration used by that separate evaluation. It should also bind to the relevant authorization and settlement records when the verifier needs to connect policy evaluation with the payment that executed.

Why agent payments need spend limits and mandate checks

A payment can satisfy native x402 or AP2 authorization checks without being evaluated against an additional application policy. 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 an x402 payment. An implementation may therefore process both protocols for one logical payment.

Per-payment controls do not independently impose a cumulative daily ceiling. A client could authorize multiple fixed-amount x402 payments below a per-payment cap. If separate payment paths maintain separate counters, the agent could also consume the same intended budget through each path. A proposed shared budget service would need to 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 verifier must apply AP2’s applicable replay, validity, integrity, and budget checks before approving a mandate. An implementation must apply native checks and prevent parallel approvals or alternate release paths from bypassing authoritative budget state.

Passive logs and post-settlement alerts identify violations after payment authority has produced an executable action. An escrow illustrates the missing control because it releases value only after defined conditions hold. A payment-authority gate would need equivalent control over every path it claims to cover. The architecture described here applies that model at payment-authority release and represents a proposed integration pattern rather than a demonstrated adapter integration.

Proposed shared policy enforcement for x402 and AP2

The proposed Inherence x402 and AP2 adapters would place an application-policy check after native authorization verification and before payment-authority release. They are integration designs, not demonstrated deployments.

In the proposed integration, each adapter would verify native authorization before normalizing authenticated claims. AP2 verification processes the full SD-JWT mandate chain, key binding, delegation, source binding, unchanged claims, and every constraint under the AP2 authorization framework (opens in a new tab). Unknown constraints fail verification. An x402 client can apply its configured spend controls before signing. The documented buyer flow (opens in a new tab) describes spend limits and allowed assets; the selected scheme defines the payment authorization checks. The payment-identifier extension (opens in a new tab) documents behavior during payment creation. It does not, on its own, establish a general-purpose inspection or modification hook. Patrick must verify any claimed hook capability and timing before publication.

The proposed adapters would pass verified claims and the proposed payment into one policy gate. In wallet-backed x402, approval would control signer release. In other AP2 flows, approval could control payment-credential release or payment initiation. A combined AP2 and x402 flow would use one logical payment and one atomic reservation.

A proposed shared budget service would need authoritative, atomic reservations across covered paths. AP2’s native cumulative budget would remain subject to its mandate and verifier rules.

After approval, the proposed architecture would produce a policy receipt and bind it to the payment authorization. A settlement binding would connect that authorization to the resulting payment record. These bindings are integration responsibilities, not native x402 compliance-receipt behavior.

Defining the mandate schema

The proposed schema would retain authenticated authorization claims separately from mutable budget state. For AP2, that means checking the mandate chain and its constraints (opens in a new tab) while retaining the original authorization material for later verification.

Signed authorization would remain separate from mutable budget state. Signed authorization would identify the signer, validity window, permitted actions, counterparties, asset, and network. Amounts would use defined units. A signed policy would specify the per-payment limit, budget_id, window limit, and reset rule. It would also specify whether authorization or settlement time assigns spend to a window.

In the proposed design, authoritative state would track settled amounts and active reservations without changing a signed mandate. A shared budget_id would associate covered mandates or payment paths with one limit.

A proposed cross-asset budget would need authenticated conversion 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.

Proposed protocol adapters would 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 cumulative limits safely

AP2 already defines cumulative budgets in the Payment Mandate (opens in a new tab). A shared application budget can extend authoritative state across covered AP2 and x402 paths when those paths must consume one limit.

A proposed shared service would reserve maximum authorized liability atomically before payment-authority release. The reservation would bind one logical payment to its authorized payload, including across retries.

A proof can establish arithmetic over its bound inputs. It cannot establish a complete, non-conflicting spending history without an authoritative atomic state service.

Verifying signatures, expiry, and allowed actions

The policy engine must accept only claims that have passed native authorization verification. Normalizing unverified claims could discard signed context or treat unauthenticated data as authoritative.

For AP2, the verifier checks the full mandate chain, including signatures, delegation, bound claims, and every constraint under the agent authorization framework (opens in a new tab). Unknown constraints fail verification.

Authorization verification must establish the signer’s applicable authority for the proposed action. The verifier checks the authenticated validity window against the applicable authorization time before calculating available budget.

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. Where the mandate constrains a counterparty, asset, network, or action identifier, the verifier must compare the proposed payment against that constraint.

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. A proposed gate would next evaluate the per-payment limit and reserve cumulative liability atomically. A failure at any earlier integrity check prevents the wallet signer from receiving an approvable payload.

Proposed zero-knowledge policy receipt

For a covered action approved by its proposed pre-execution gate, the Inherence integration would produce a separate policy receipt. A compressed zero-knowledge proof would be one component, not the complete receipt. Independent verification would also require the bound public inputs and accepted verification configuration, either in the receipt or available by reference. Designated private inputs would not need to be disclosed.

The proof would establish only the checks encoded in its defined 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 cryptographically valid proof could still 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. A proposed authoritative budget service would track settled spend and active reservations across covered payment paths. In the proposed design, the proof would establish only the policy computation encoded in its statement against committed or attested inputs.

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. 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.

Comparing native AP2, native x402, and the proposed Inherence architecture

FAQs

What authorization frameworks exist for x402?

x402 does not define one named mandate framework equivalent to AP2. It uses scheme-specific authorization registered by network and asset, including documented exact and upto schemes. The documented x402 buyer flow (opens in a new tab) supports configurable client-side spend controls before signing. The payment-identifier extension (opens in a new tab) documents payment-creation behavior, but its precise hook capabilities and timing require technical confirmation. AP2 can separately authorize an x402 payment through its mandate framework.

How can AP2 transaction receipts be verified?

Verify the complete mandate chain under the AP2 authorization rules (opens in a new tab), including signer authority, delegation, bound claims, and every constraint. Reject unknown constraints. Check the Mandate Receipt’s signature and independently recompute its referenced mandate hash. Separately check the Payment Receipt’s reference to the closed Payment Mandate and its reported status. Confirm any PSP or network identifiers against the relevant provider or network records when independent payment confirmation is required.

Do portable x402 compliance receipts exist?

The cited x402 buyer documentation (opens in a new tab) does not specify a portable receipt for a separate application-policy evaluation. x402 payment authorization and settlement records prove properties defined by the selected payment scheme. The payment-identifier extension (opens in a new tab) supports idempotency and request deduplication. It is not a compliance receipt.

Which vendors or architectures can enforce policy before execution without requiring a vendor portal?

Pre-execution enforcement can sit in client payment controls, wallet or custody signing controls, smart contracts, or inline authorization gates. Portal-free verification is a separate requirement: the architecture must expose evidence that an independent verifier can check locally.

Newton is a relevant vendor to assess, but its pre-settlement enforcement and locally verifiable receipt capabilities are not established by a cited primary source here. Confirm those capabilities against Newton's technical documentation before making a product comparison. More generally, an operator-signed verdict can document a decision without letting a third party independently check the underlying policy computation.

The proposed Inherence architecture would combine an inline gate with a policy receipt that can be verified locally. This remains a proposed x402 and AP2 integration architecture unless implementation evidence is published.

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

In the proposed integration, a shared budget service would count settled amounts and active reservations. If the proposed payment exceeded the daily limit, the gate would reject it before releasing signing authority, credentials, or payment-initiation authority. 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. The proposed Inherence integration would add an application-policy gate before payment-authority release and independently verifiable evidence for covered evaluations. Its shared budget service would account for covered paths. A wallet-backed fixed-amount exact x402 example would gate signing; other AP2 flows could gate credential release or payment initiation.

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

Under the proposed architecture, an independent verifier could check the policy receipt cryptographically without using an Inherence portal. The proposed receipt would contain a compressed zero-knowledge proof and provide access to 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. Independent verification would still rely on authoritative budget state for cumulative spending and on payment-rail records for 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

A shared limit across x402 payments, including those authorized through AP2 (opens in a new tab), requires control over each payment-authority route the integration claims to cover.

The proposed Inherence integration would check application policy and reserve budget before releasing payment authority. A separate policy receipt would let an independent verifier check the covered evaluation. Proposed bindings to authorization and settlement records would associate that evaluation with a particular payment.

The proposed Inherence x402 and AP2 adapters are not demonstrated deployments. Patrick must review the technical descriptions, and Annie must review the editorial copy before publication.