· 11 min read
How to Test AI Agent Payment Guardrails Before Launch
A prelaunch test plan for AI agent payment guardrails, covering budget races, retries, bypass attempts, and evidence a counterparty can verify.
TL;DR
- Payment infrastructure developers and risk leads can use this prelaunch plan to test AI agent payment guardrails under concurrency, retries, and bypass attempts.
- Each test specifies the setup, injected failure, expected rejection stage, and evidence an independent counterparty can check.
- Budget tests distinguish AP2’s native mandate and cumulative-budget checks from x402’s configurable client spend controls.
- Passing tests cover actions routed through the defined enforcement path and evaluated against committed or attested inputs. They do not establish the truth of every external input or cover actions outside that path.
- Inherence’s AP2 and x402 adapters and shared atomic budget service remain proposed architecture. The implementation guide (opens in a new tab), protocol comparison (opens in a new tab), and receipt explainer (opens in a new tab) provide background.
Why prelaunch testing has to target concurrency, retries, and bypass
A payment guardrail can pass a single-payment test and still authorize spending beyond a shared limit. Two simultaneous payments may each fit the remaining budget when checked separately, even though their combined amount exceeds it. A retry may create a second executable authorization if the payment path treats it as a new request. Prelaunch tests must show that an atomic reservation prevents overspending and that a retry cannot create a second executable authorization.
Prelaunch tests must also attempt payment authorization through routes that bypass the policy gate. An alternate signer or credential-release path could authorize a payment without the intended policy check. A post-settlement alert can identify that payment, but it cannot prevent its execution. Each test should record where the attempted payment was blocked and preserve evidence that a counterparty can check, rather than relying on an internal pass/fail result.
Inherence provides evidence for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. Such evidence does not establish the truth of every external input or cover payments executed outside that path. Prelaunch testing should record uncovered paths separately. A passing guardrail test cannot establish control over them.
How to structure each test case
Each test case needs a baseline, an injected failure, an expected rejection stage, and checkable evidence.
- Baseline setup. Record the authorized payment, mandate, policy version, budget identity, and covered execution path. Identify the inputs the control will evaluate.
- Injected failure. Change one condition at a time, such as the amount or payment route. Keep other conditions fixed so the cause of a rejection stays clear.
- Expected block or rejection stage. Name native mandate verification, the proposed pre-signing policy gate, receipt acceptance, or settlement reconciliation. The protocol comparison (opens in a new tab) distinguishes native checks from separate policy controls.
- Independently checkable evidence. Specify the authorization, reservation record, receipt, or settlement record a counterparty must inspect. The receipt explainer (opens in a new tab) sets out receipt acceptance checks.
Mark whether the test must prevent authority before execution or detect a mismatched record afterward. Receipt rejection cannot substitute for a failed pre-execution block. The implementation guide (opens in a new tab) describes the pre-signing gate as proposed integration architecture, not a deployed control.
Budget and concurrency test cases
AP2 requires mandate-chain verification and a cumulative budget check (opens in a new tab) for applicable mandates. The test setup must identify which mandate amounts count toward that budget. The specification does not prescribe how an implementation makes concurrent budget updates atomic. By contrast, x402 offers configurable client spend controls (opens in a new tab), not a shared cross-rail budget. The tests below treat Inherence’s AP2/x402 adapters and shared atomic budget service as proposed architecture, not deployed integrations.
Test | Authorized setup | Injected failure | Expected stage and checkable evidence |
|---|---|---|---|
Concurrent AP2 mandates | Set an AP2 budget of 100 and establish that 90 counts against it. | Present two otherwise valid Payment Mandates for 8 at the same time. | AP2 mandate verification must reject any mandate that exceeds the applicable cumulative limit. The proposed reservation gate must admit at most one before authority release. A counterparty can compare the mandate chain, accepted authorizations, and ordered reservation records. |
Concurrent covered paths | Give one budget owner 100 of available capacity across AP2 and x402. | Submit an AP2 payment for 60 and an x402 payment for 60 simultaneously. | The proposed shared gate must reject one before payment authority becomes executable. A counterparty can check both decisions against one ordered reservation history. Separate per-path counters would not pass this test. |
Usage-based liability | Leave 120 available and prepare an x402 Upto authorization (opens in a new tab) with a signed maximum of 80. | Request another covered payment for 50 before the first authorization settles for 10. | The proposed gate must reserve 80 and block the second payment. A counterparty can check the signed maximum, reservation, settlement amount, and release record. Unused capacity returns only when the remaining authority can no longer be exercised. |
Retry and payload change | Create one approved logical payment and retain its reservation. | Retry after a timeout, send a simultaneous duplicate, then reuse the logical identifier with a changed recipient or amount. | The proposed gate must allow at most one executable authorization against the reservation. A changed payload must fail or receive a fresh policy decision. A counterparty can compare payload bindings, reservation transitions, and authorization records. Repeat the test after identifier expiry to ensure old authority cannot produce an additional payment. |
Shared-budget identity | Bind an AP2 mandate and an x402 payer credential to the same budget owner and logical purchase. | Present the purchase through both rails under different identifiers. | The proposed gate must use one owner budget and prevent a second executable authorization for the purchase. A counterparty can check the authenticated owner mapping, purchase binding, authorization records, and reservation history. |
Batch funding | Configure an x402 batch route and a client spend cap. | Raise the deposit request or retry a voucher after the initial authorization. | The proposed gate must account for exercisable authority before release. A counterparty can inspect the deposit and cumulative voucher records (opens in a new tab) alongside reservation and refund transitions. A per-request cap alone does not prove the deposit fits a shared budget. |
These checks establish budget continuity only for covered actions and authoritative committed or attested state. A valid policy receipt cannot, by itself, establish a complete spending history.
Authority and binding test cases
Authority tests check whether an altered approval or bypass route can produce executable payment authority. Inherence’s AP2 and x402 adapters, including a gate before signing or credential release, remain proposed architecture. Each test specifies the baseline, attempted failure, rejection point, and checkable evidence.
Baseline setup | Injected failure | Expected stage | Checkable evidence |
|---|---|---|---|
Record an AP2 mandate version and the separate policy version used to approve a checkout. | In separate runs, present an unsupported AP2 version or change the policy while retaining its old approval. | Native verification must reject the unsupported AP2 version. The proposed policy gate must reject an approval bound to the wrong policy version before authority release. | Preserve the mandate, both version bindings, and the relevant rejection record. AP2 requires an exact version-string match (opens in a new tab) for its mandate version. |
An AP2 open mandate contains known constraints and closes against a specific transaction. | In separate runs, add an unknown constraint, change an open-mandate claim in the closed content, or bind the Key Binding JWT to another transaction. | Native mandate verification must reject each altered chain before payment authority is released. | Retain the received mandate chain, verification result, and signed Mandate Receipt where one exists. The AP2 verification rules (opens in a new tab) require unchanged claims and failure on unknown constraints. |
A proposed gate approves one unsigned x402 payment payload. | Change the recipient or amount before signing. | The gate must require a new decision or block signing. | Compare the approved payload commitment with the signed authorization. For an x402 Upto payment (opens in a new tab), check the signed maximum rather than only the eventual charge. |
An approved payment uses a defined signer or credential-release route. | In separate runs, submit it through an alternate signer, AP2 credential provider, or delegated x402 voucher signer. | Each covered authority route must refuse release without a valid approval bound to that route and action. | Retain denial or release records and inspect authorization records for each attempted route. x402 batch settlement (opens in a new tab) permits a delegated voucher signer and commits a receiver authorizer to the channel. |
A policy decision uses an attested screening result with an accepted timestamp. | Reuse an expired result or substitute an unattested result. | The proposed gate must block authority release when the policy requires fresh, attested screening. | Check the input attestation, timestamp, policy version, and rejection record. The evidence cannot establish whether the screening provider’s underlying data was true. |
A policy receipt belongs to one approved payment. | Present that receipt for another authorization or submit it again after use. | Receipt acceptance must reject the mismatch or replay. A rejection at this stage cannot undo an already executed payment. | Check the receipt’s bound action, authorization reference, freshness rule, and prior acceptance record. |
These tests establish coverage only for actions routed through the defined enforcement path and evaluated against committed or attested inputs. Technical assertions and test outcomes require Patrick’s review. Annie reviews the editorial copy before publication.
Reconciliation test cases
Reconciliation tests compare a proposed policy receipt with native authorization and settlement records for the same covered payment. Run these tests against authorization and settlement records to detect mismatches that pre-execution checks did not prevent. An independent verifier should apply the receipt acceptance checks (opens in a new tab), including action binding and freshness. The verifier should also check replay status, record association, and authorization-to-settlement linkage.
Swapped AP2 receipt. Start with a valid closed Payment Mandate and its Payment Receipt. Replace the receipt with one whose reference points to another mandate. Reconciliation must reject the pair. A counterparty can recompute the mandate hash and check it against the receipt reference, as required by the AP2 verification rules (opens in a new tab).
Wrong policy association. Start with a proposed policy receipt bound to one action and policy version. Attach it to a different authorized payment or replace it with an older receipt. Receipt acceptance must fail even if the native payment authorization remains valid. A counterparty can compare the receipt’s action commitment, policy version, and freshness evidence with the authorization record.
Settlement mismatch. Start with one authorized payment, its accepted policy receipt, and a settlement record. Substitute a settlement record for another payment or one that exceeds the signed ceiling in an x402 upto payment (opens in a new tab). Reconciliation must flag the mismatch. A counterparty can compare payment identifiers, authorized amounts, settled amounts, and the records that link them.
A reconciliation passes only when the policy receipt, native authorization, and settlement record identify the same covered action. The settled amount must also stay within the authorized limit. A failed reconciliation detects a discrepancy after the fact. It does not retroactively block a payment that already executed.
What the tests can and cannot prove
A valid policy receipt can show that a covered action satisfied the committed policy for the inputs encoded in the proof. It does not establish whether those inputs were true. An independent verifier can check the proof against the accepted verification key and public statement. The verifier must separately check that the receipt belongs to the expected action, matches the native authorization, and corresponds to the settlement record. A valid proof does not establish that an external screening result was accurate or that payments outside the enforcement path were governed.
A receipt rejected after payment can reveal a mismatch, but it cannot prevent an authorization that already occurred. Prelaunch tests must show that off-mandate attempts fail before the covered path releases executable payment authority. The relevant enforcement point may be signing, credential release, or payment initiation. Budget tests also depend on an authoritative atomic ledger to establish which reservations were accepted.
AP2 specifies mandate-chain verification and cumulative-budget checks for applicable mandates. x402 supports configurable client-side spend controls. Inherence’s AP2 and x402 adapters and shared atomic budget service remain proposed integration architecture, not deployed integrations. The implementation guide (opens in a new tab) and protocol comparison (opens in a new tab) explain the underlying mechanics.
Prelaunch test matrix at a glance
The matrix summarizes tests for covered payment actions. A shared atomic budget service and policy gate are proposed Inherence architecture, not deployed integrations.
Test | Setup | Injected failure | Expected stage | Checkable evidence |
|---|---|---|---|---|
Concurrent payments | One shared budget | Simultaneous requests exceed it | Pre-signing gate | Reservation log |
Atomic reservation | One remaining allowance | Two paths claim it | Pre-signing gate | One accepted reservation |
Maximum liability | Usage-based authorization | Signed ceiling exceeds allowance | Pre-signing gate | Signed ceiling and reservation |
Retry | Approved request with a retained reservation | Repeat the request, then reuse its identifier with changed payment fields | Pre-signing gate | At most one executable authorization for the original request; a new decision or rejection for changed fields |
Shared identity | Two payment paths | Use separate identifiers for one payer | Pre-signing gate | Identity mapping and budget ledger |
Policy version | Committed policy | Present an older version | Pre-signing gate | Version-bound decision |
Payload binding | Approved action | Alter unsigned payment fields | Pre-signing gate | Payload commitment and rejection |
Alternate route | Covered signer or credential provider | Attempt payment without a bound approval | Signer or credential release | Denial record and audit of authority released through that route |
Screening freshness | Policy requiring a fresh, attested screening result | Reuse an expired result | Pre-signing gate | Attestation, accepted freshness rule, and rejection record |
Receipt replay | Accepted receipt | Present it for another action | Receipt acceptance | Rejection and action reference |
Reconciliation | Matching payment records | Change a receipt or settlement reference | Settlement reconciliation | Linked records and mismatch report |
FAQs
Do the tests cover offchain payment legs?
An offchain payment leg is covered only if it passes through a defined enforcement point before execution. The test should attempt credential release or payment initiation without a bound policy decision. The enforcement point must refuse the attempt and retain a checkable denial record.
What happens on an unsupported payment path?
A path without an enforcement point cannot be treated as covered. The coverage review should record the path as unsupported and identify any authority the integration can withhold. If the path can execute payment outside the enforcement point, its actions remain outside the evidence claim. Actions executed outside that path remain outside the evidence claim.
Are Inherence’s AP2 and x402 adapters deployed integrations?
The cited implementation guide (opens in a new tab) does not establish that the adapters or shared atomic budget service are deployed. The guide presents them as proposed architecture. A launch review needs implementation-specific test results before claiming those controls operate in production.
When should the matrix be rerun?
Rerun affected tests after a policy change, protocol upgrade, or new payment path. Repeat concurrency and retry tests whenever a change alters shared-budget identity, reservation behavior, or authorization handling.
Conclusion
A launch decision should require evidence that concurrent payments respect shared budgets, retries do not create extra authority, and covered routes reject bypass attempts before execution. Reconciliation tests should separately detect mismatches among receipts, authorizations, and settlement records. Results apply only to covered actions routed through the defined enforcement path and evaluated against committed or attested inputs.
Patrick should review protocol and implementation claims and the resulting test evidence before publication. Annie should review the editorial copy.