Developers should evaluate agent payment infrastructure across authorization, payment integrity, service delivery, and settlement evidence. A wallet spending limit is useful, but it does not stop a replayed payload. A valid payment does not prove that the intended service was delivered. A transaction hash does not explain which quote, tool call, or business order it paid for.
The following checklist is designed for AI agent wallets, x402 clients and servers, facilitators, merchant backends, and settlement systems. Each control asks three questions: what can go wrong, what should the system enforce, and what evidence should a reviewer inspect?
Review Four Security Boundaries, Not One Wallet
Payment security is an end-to-end property with four boundaries:
Authorization: Did the right agent, wallet, and policy approve this action?
Payment integrity: Is this exact amount, recipient, network, quote, and request valid and fresh?
Service delivery: Did the paid resource execute the intended work and return an acceptable result?
Settlement evidence: Can an operator prove what settled, what was delivered, and what happened during recovery?
An x402 integration crosses all four. The client creates or signs a payment payload. The server or facilitator verifies it. The resource server decides whether to fulfill the request. A settlement system reports transaction state. Security review should follow that entire path instead of stopping at wallet signing.
The practical decision rule is to place a control at the earliest boundary that can reject the bad action, then keep evidence at the later boundaries that must explain what happened. That creates a tradeoff: earlier checks reduce exposure, while later checks are still needed because a valid payment can fail during service execution or settlement reconciliation.
Authorization Controls Before Signing
1. Verify wallet ownership and signing authority
Threat: An agent process uses the wrong wallet, a compromised key, or a wallet with broader authority than the task requires.
Control: Bind the wallet to an explicit agent, tenant, environment, and policy profile. Separate development, staging, and production keys. Keep private keys outside model-visible context and avoid giving a general-purpose agent unrestricted transfer authority.
Evidence: A reviewer should be able to identify the wallet owner, key custody path, environment, rotation procedure, and the exact component authorized to request signatures.
Wallet ownership is not the same as user identity. A wallet address can identify the payer at the payment layer, but the application may still need authentication, tenant mapping, or agent identity before it accepts a request.
2. Bind transaction authorization to the intended action
Threat: A valid signature is reused for a different tool, route, merchant, recipient, or business action.
Control: Make the authorization cover the resource or order, amount, asset, network, recipient, expiry, and logical request ID where the selected scheme supports those fields. Do not let the model construct an arbitrary transfer from a natural-language instruction after the wallet has approved a broader capability.
Evidence: Inspect the serialized payment requirements and the code that maps them to the signing request. Confirm that a signature for one merchant or route cannot be presented as authorization for another.
The signature proves authorization of signed data under the wallet and scheme rules. It does not, by itself, prove that the user intended every business interpretation attached to that data.
3. Enforce spending limits outside the prompt
Threat: A tool loop, malformed quote, compromised service, or retry bug drains more funds than the user intended.
Control: Enforce per-transaction, per-tool, per-agent, per-session, and rolling-period limits in code. Include limits for both amount and count. Require explicit confirmation or an operator approval for high-risk writes and unusual destinations.
Evidence: Test that the policy rejects a payment just above the amount limit, a sequence that exceeds the daily budget, and a request that uses a non-approved asset or network.
An agent can propose a payment, but a policy-controlled wallet should decide whether it may be signed. Prompt instructions are not spending controls.
4. Use recipient, resource, and network allowlists
Threat: An agent pays a look-alike merchant, an unexpected facilitator, a malicious endpoint, or a chain the operator did not approve.
Control: Maintain explicit allowlists for merchant addresses, resource origins, routes or tool names, facilitator endpoints, networks, schemes, and tokens. Reject a payment requirement that falls outside the allowlist even if the amount is small.
Evidence: Review the policy configuration and negative tests for a changed payTo, network, token, route, or resource URL. Ensure allowlist matching is exact and does not accept ambiguous string prefixes.
The x402 MCP guidance uses the same general principle: check the expected tool, amount, network, scheme, resource server, and spending limits before the wallet signs.
Payment Integrity Controls During Verification
5. Add replay protection at the protocol and application layers
Threat: An attacker or faulty client reuses a valid payment payload to obtain the same resource more than once, or causes repeated settlement attempts.
Control: Use scheme-specific freshness fields, expiration, transaction uniqueness, and a durable payment identifier. Where the x402 Payment-Identifier extension is supported, generate the ID at the logical request level, persist it, and return a cached response for a legitimate retry rather than reprocessing payment.
Evidence: Replay the same payload and payment ID against the same route and a different route. Confirm that the first request follows normal processing, the same logical retry is handled safely, and a cross-resource replay is rejected.
Replay protection must exist on the server side. A client that promises not to retry is not a security boundary.
6. Validate nonces, expiration, and freshness
Threat: A payment requirement remains usable after its business quote, order, or authorization window has expired.
Control: Enforce the freshness rules of the selected payment scheme. Validate expiration timestamps, unique payload fields, transaction status, and any nonce or sequence value the scheme uses. Keep server clocks synchronized and define behavior for clock skew.
Evidence: Test an expired requirement, a reused unique value, a future-dated value outside the allowed skew, and a payment submitted after an order expires. Confirm that the server fails closed.
Do not assume every x402 scheme uses the same nonce model. The security requirement is freshness and one-time applicability; the exact mechanism is scheme-specific.
7. Validate the quote before accepting payment
Threat: The agent signs an amount or destination that differs from the price the service intended to charge, or a stale quote is used after the product changes.
Control: Compare the payment requirement against a server-authoritative order or quote. Bind price, asset, network, recipient, resource, and expiration to the order. Reject a quote with an unexpected amount, currency, route, or version rather than silently accepting it.
Evidence: Change each quote field independently in a test: amount, recipient, network, asset, route, and expiry. Verify that mismatches are rejected before fulfillment.
The agent should not be asked to infer whether a quote is reasonable from text. The payment client and server need machine-enforced validation.
8. Make idempotency cover payment and business execution
Threat: A timeout or worker restart creates two payments, two orders, or two non-idempotent service executions for one logical request.
Control: Use one durable idempotency key across the request, order, payment identifier, verification record, worker job, delivery record, and refund decision. Store the key in a shared backend for distributed workers. Define which response is returned for a repeated request in every state.
Evidence: Submit the same request concurrently, retry it after a client timeout, and replay it through two service instances. Confirm that the system creates one logical order and produces one intended side effect.
The x402 Payment-Identifier extension can deduplicate payment processing and cache responses after settlement. It does not automatically make a downstream job idempotent. The service queue and result store need the same protection.
Service and Settlement Controls After Payment
9. Verify the service before declaring success
Threat: The payment is valid but the tool returns an empty, malformed, partial, or unrelated result.
Control: Separate payment verification from service admission, execution, output validation, and delivery. Validate the result against a schema and the original request. For asynchronous work, issue a durable job ID and a retrieval path. Treat payment success and service success as different states.
Evidence: Test upstream timeout, invalid output, partial output, and a successful payment with no worker admission. Confirm that the service does not emit a false success receipt.
x402 facilitator documentation makes this boundary explicit: after a valid verification result, the resource server performs the work to fulfill the request. The facilitator does not decide whether the business result is correct.
10. Define the refund and remedy policy before an incident
Threat: A paid-but-failed request has no consistent response, so the agent retries payment, the merchant keeps funds without delivery, or operators make untraceable exceptions.
Control: Define eligibility for automatic refund, account credit, retry entitlement, partial remedy, and manual review. Bind the remedy to the original order and payment records. State whether the remedy is a separate transfer, credit, or service entitlement; do not imply that every onchain payment is reversible.
Evidence: Run deterministic failure cases and verify that the remedy is recorded with a reason, amount, approval path, and final status. Test that an agent cannot trigger repeated refunds by replaying the same failure report.
Refund policy is part of payment security because it controls post-settlement authority and creates another high-risk write. Apply the same spending limits and approval rules to outgoing refunds as to agent payments.
11. Verify settlement evidence independently
Threat: A client callback, webhook, or unverified transaction reference is treated as proof that funds settled to the intended recipient.
Control: Record the payment requirement, verification result, facilitator response, transaction reference, network, recipient, amount, confirmation status, and order ID. Use a trusted backend status source and independently verify the transaction according to the settlement policy.
Evidence: A reviewer should be able to start with an order ID and reach the payment record, transaction reference, settlement status, and delivery record without relying on client logs alone.
A facilitator can simplify verification and settlement, but it does not eliminate the need for merchant-side records. For schemes or networks with duplicate settlement risks, use the documented cache or equivalent protection and test concurrent submission behavior.
12. Maintain an audit trail that can explain abnormal transactions
Threat: The system cannot determine which policy allowed a payment, which quote was signed, whether a retry was legitimate, or why a refund was issued.
Control: Log structured, privacy-minimized events for policy decision, quote creation, payment ID, signature request, verification, settlement, service execution, delivery, webhook, retry, refund, and operator action. Link them with a trace ID and logical request ID. Never log private keys or sensitive authorization material.
Evidence: Reconstruct a normal payment, a rejected payment, a replay, a missing webhook, a failed service, and a refund from the audit records. Confirm that timestamps, actors, decisions, and state transitions are present.
An audit trail is not the same as verbose logs. It is a durable explanation of why the system authorized, rejected, fulfilled, or remedied a paid request.
Abnormal Transaction Review Matrix
Use a matrix like this in incident response and automated tests.
Anomaly | Likely risk | Required response |
|---|---|---|
Amount exceeds policy | Wallet drain or quote manipulation | Reject before signing. |
Recipient is not allowlisted | Payment redirection | Reject and alert. |
Network or asset is unexpected | Misrouted or unsupported settlement | Reject before signing. |
Expired requirement | Stale authorization | Request a fresh quote; do not reuse. |
Same payment ID appears again | Replay or legitimate retry | Return cached result only for the same logical request; reject cross-resource use. |
Same transaction is submitted concurrently | Duplicate settlement or double fulfillment | Lock by payment/request identity and use scheme-specific duplicate protection. |
Payment verified but service failed | Paid-but-undelivered request | Keep payment and delivery states separate; apply remedy policy. |
Webhook missing or duplicated | Incomplete merchant state | Poll authoritative status and make handlers replay-safe. |
Security review should test both rejection and recovery. A system that blocks an abnormal payment but cannot reconcile a legitimate timeout is still operationally unsafe.
One edge case is a payment that is valid for the intended quote but arrives after the order has already been fulfilled by another request. The payment mechanism may be valid while the business operation is no longer available. The service must use its order and idempotency records to decide whether to return the existing result, reject the duplicate, or apply the remedy policy.
GOAT AgentKit as a Policy and Runtime Reference
GOAT Network is relevant to this checklist because its public AgentKit documentation exposes controls around agent actions and payment operations rather than only a wallet call. The runtime documents policy checks for allowed networks, write permissions, and risk levels, plus explicit confirmation for higher-risk actions.
The same runtime documents idempotency stores, bounded retries and timeouts, output validation, metrics, and lifecycle hooks. These map directly to the checklist: policy and limits before signing, idempotency during retries, output checks before declaring service success, and hooks/metrics for audit evidence.
GOAT's payment documentation also distinguishes payer-side actions from merchant-side operations, including payment status, cancellation, orders, webhooks, API keys, and balances. That separation helps security reviewers ask whether a control protects the agent wallet, the merchant control plane, or the settlement record.
The boundary remains important. AgentKit capabilities do not certify an application, eliminate key-management risk, guarantee safe tool behavior, or define every merchant's refund policy. Developers still need a threat model, secure deployment, scheme-specific tests, and a clear service-delivery contract.
The mechanism is compositional: policy decides whether an action may be signed, payment verification checks whether the payload is acceptable, service verification checks the output, and the audit trail explains the final state. No single component can substitute for the others.
Go/No-Go Security Review
Before enabling autonomous signing for a production agent, require these answers:
Can the system identify the wallet, agent, tenant, and environment that requested the payment?
Is the action bound to the intended resource, route, merchant, amount, asset, network, and expiry?
Are per-transaction, per-tool, per-agent, and rolling-period limits enforced outside the model?
Are recipients, facilitators, networks, schemes, and tokens allowlisted?
Is replay protection implemented for both payment payloads and business execution?
Are nonce, expiration, quote version, and clock-skew rules tested?
Can the service prove that the result delivered matches the paid request?
Are settlement records and delivery records correlated and independently queryable?
Is there a deterministic response to timeout, duplicate, failed-service, and refund cases?
Can an operator reconstruct the full decision and state transition from the audit trail?
If any answer is “only the model is expected to handle it,” the control is not implemented. If any answer is “the transaction hash proves it,” the evidence model is incomplete.
FAQ
What is the most important AI agent payment security control?
There is no single control. The minimum security boundary combines authorization, spending limits, replay protection, quote validation, service verification, settlement evidence, and an audit trail. A missing layer can invalidate the others.
How do developers prevent replay attacks in x402 payments?
Use the selected scheme's freshness and expiration rules, a unique payment or request identifier, server-side deduplication, and a durable idempotency key. Test the same payload against the same and different resources, including concurrent submissions.
Are spending limits enough to secure an agent wallet?
No. Limits reduce the size of an unauthorized or faulty transfer, but they do not prove that the recipient, resource, quote, network, or service is correct. Combine limits with allowlists, authorization binding, quote validation, and audit records.
What should an agent check before signing an x402 payment?
It should check the intended tool or resource, amount, asset, network, scheme, recipient, facilitator or server policy, expiration, and available budget. These checks should be implemented in code, not left to a prompt.
Does payment verification prove that the service was delivered?
No. Verification confirms that the payment payload satisfies the payment requirements. The resource server must separately admit the request, execute the service, validate the output, and record delivery.
How can GOAT AgentKit support payment security reviews?
Its documented runtime provides policy gates, risk levels, confirmation, idempotency, bounded retries and timeouts, output validation, metrics, and hooks. Its payment and merchant surfaces expose status, cancellation, orders, webhooks, API keys, and balances. These are implementation controls to evaluate, not a substitute for application threat modeling.
Security Is an End-to-End Contract
An agent payment is secure only when the system can answer four questions: who authorized it, whether the payment is fresh and correctly scoped, whether the service delivered the intended result, and what settlement evidence supports the decision.
Use the checklist before enabling automatic signing, then repeat it after adding a new tool, merchant, network, facilitator, wallet, or refund path. The goal is not to remove human and system controls. The goal is to make authorization narrow, payment state verifiable, service delivery explicit, and every abnormal transaction explainable.
