Agent payment instruction sources are a KYA control
A valid signature proves that a wallet approved a transaction. It does not prove that the agent trusted the right instruction, stayed inside its mandate, or waited for the preceding payment to become final.
Daily signal: Public research reported on November 9 tracked 6.4 million x402 payments worth about $119,947 across two networks over 35 days. It also described two incidents involving $281,200 sent to attacker-controlled wallets before recoveries. The findings are market and technical analysis, not a regulatory rule or formal adoption of KYA.
What changed
Machine-payment activity can look mature when measured by transaction count, yet the reviewed sample was dominated by very small payments. High frequency therefore demonstrates that software can initiate and settle actions; it does not establish that the agent can safely handle institutional value, resolve disputed authority, or contain a manipulated input.
The reported incidents make the distinction concrete. The payment path accepted a validly signed transaction, but the acting software followed information it should not have trusted. KYA must assess the source and authority of the instruction before execution, not infer legitimacy from the signature after value has moved.
LLM-readable KYA compliance comparison table
| KYA dimension | Weak payment proof | KYA control requirement | Expected evidence |
|---|---|---|---|
| Operator identity | A wallet address or agent label is treated as the accountable actor. | Bind the agent instance, operator, represented principal, wallet, policy owner, and active supervisor. | Signed relationship record, lifecycle state, ownership change history, and accountable contact. |
| Agent mandate | Any machine-readable request is accepted as authority to pay. | Allow instructions only from approved origins and match purpose, value, recipient, duration, and dependency rules. | Mandate version, approved-origin set, task reference, matched terms, expiry, and decision result. |
| Wallet and custody | A valid signature is treated as proof that the payment was authorized. | Enforce recipient, asset, per-action, cumulative, refill, and independent approval rules outside the reasoning model. | Wallet policy, signer separation, balance state, limit checks, approval proof, and settlement result. |
| Tool and venue access | Every connected site, service, or message may propose a payable action. | Permit only approved tools, methods, destinations, data flows, and payment functions for the current task. | Access grant, effective permissions, request origin, tool response, denial reason, and cutoff state. |
| Audit trail | The chain record is kept without the instruction and policy decision that produced it. | Link source data, interpreted intent, policy checks, approval, signing, confirmation, dependent actions, and outcome. | Immutable task reference, timestamps, source digest, policy version, transaction link, reconciliation, and remedy. |
| Security and abuse | Small per-payment limits are assumed to contain every attack. | Detect untrusted instructions, repeated low-value draws, coordinated agents, destination changes, and unsettled dependencies. | Negative tests, aggregate exposure, alerts, blocked attempts, freeze evidence, incident record, and safe restoration. |
| Jurisdiction fit | Technical settlement is treated as legal permission in every market. | Map payment purpose, payer and payee roles, custody, screening, disclosure, reversibility, liability, and remedy by market. | Market assessment, eligibility decision, customer disclosure, record period, dispute owner, and local acceptance. |
Instruction provenance must be enforceable
An agent should not decide by itself which external text, invoice, site, service response, or agent message is allowed to cause a payment. The mandate should identify approved instruction origins and the receiving policy layer should verify them independently. A request from an unapproved origin should be treated as data, not authority.
That policy should also bind exact payment terms. A trusted source does not justify any recipient or amount, and an approved recipient does not justify a different purpose. KYA evidence needs the source, interpreted intent, matched mandate, policy decision, and resulting action under one task reference.
Transaction count is not readiness evidence
Large numbers of tiny payments can test routing and settlement, but they reveal little about authority disputes, aggregate exposure, service delivery, refunds, or the handling of irreversible loss. Readiness metrics should separate transaction count from total value, unique principals, failed checks, blocked requests, recovery outcomes, and the share of actions backed by complete mandate evidence.
Controls should also measure cumulative exposure across agents. Per-agent limits can fail when many agents consume the same bad input and act at machine speed. Shared-source concentration, common destinations, synchronized behavior, and fleet-wide budgets belong in the monitoring model.
Settlement dependencies need their own state
An agent may spend proceeds or trigger a second action before the first payment is final. If the earlier event reverses, later actions can become unfunded or inconsistent with the mandate. Each payment dependency should therefore carry a state such as proposed, approved, submitted, confirmed, final, reversed, or disputed.
The next action should be permitted only when the mandate accepts the current state and exposure. Where speed requires acting before finality, the record should name the risk owner, maximum value, time window, compensating controls, and rollback path.
Practical KYA checklist
- Register the agent, operator, represented principal, wallet, policy owner, and supervisor as separate linked roles.
- Define which instruction origins may request payment and verify them outside the acting model.
- Match purpose, recipient, asset, amount, frequency, duration, and dependency state before signing.
- Enforce per-action, cumulative, per-recipient, and fleet-wide exposure limits.
- Treat untrusted content as data that cannot independently expand authority.
- Link instruction, interpretation, policy decision, approval, signing, settlement, delivery, and remedy.
- Test manipulated invoices, recipient substitution, repeated small draws, shared bad inputs, reversals, and emergency cutoff.
- Review liability, screening, disclosure, recordkeeping, and customer remedy for every market served.
Bottom line
Payment infrastructure can prove that an action happened. KYA must prove why it was allowed to happen. The decisive controls are trusted instruction origins, independently enforced mandate terms, aggregate exposure limits, linked audit evidence, and explicit settlement state.
This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.