Risks and Open Problems

Agent finance fails differently from ordinary payments. The failure may begin as a prompt injection on a web page, continue as a mistaken tool call, pass through a real wallet or card authorization, and only become visible when treasury sees an unfamiliar merchant. That chain crosses model safety, application security, payment operations, and legal accountability.

The honest position is that no single protocol solves this. Wallets can protect keys. x402 can standardize resource payments. ACP can make checkout deterministic. AP2 can carry verifiable intent. Card networks can add identity and permissioning. Finance still needs policy, observability, reconciliation, and incident response.

Prompt injection becomes payment injection

Prompt injection is not only a content-security problem. If an agent can browse, interpret merchant pages, call payment tools, or summarize invoices, malicious text can try to redirect its financial behavior. The injection does not need to steal a key; it only needs to persuade the agent to invoke a legitimate payment tool under a false pretext.

Mitigations belong at the tool boundary: typed payment intents, merchant verification, destination allowlists, separate untrusted-content context, deterministic policy checks, and human review for new recipients or high-risk categories.

Runaway spend and retry loops

Agents can retry faster than humans notice. A failed API purchase, ambiguous 402 response, flaky merchant endpoint, or looped planning step can create repeated authorization attempts. Even if individual transactions are small, aggregate spend can exceed the task's value.

Period budgets are necessary but not sufficient. Systems also need velocity limits, duplicate detection, idempotency keys, task-level budgets, and alerts when the agent keeps attempting denied transactions.

Custody and law are not settled by SDK choice

A team can use a high-quality wallet SDK and still misunderstand its legal role. Is the agent spending company funds, customer funds, pooled funds, or value held for another party? Is the asset fiat, stablecoin, tokenized deposit, rewards credit, or something else? Is the operator merely providing software, or accepting and transmitting value?

FinCEN's CVC guidance is useful because it focuses on function, not labels. Technical architecture should make those functional roles visible: who controls value, who can revoke, who receives funds, who bears loss, and who owes reporting.

Merchant and resource spoofing

Agents need machine-readable seller identity. A domain, wallet address, product page, MCP tool, or x402 endpoint can be spoofed or imitated. Trust should not rest on the model's visual interpretation of a page or string similarity in a merchant name.

Practical controls include verified merchant registries, signed payment requirements, known facilitator lists, DNS and TLS checks, address books, allowlisted MCP servers, and order confirmation that comes from a separate channel.

Fragmented budgets across rails

The most serious finance gap is cross-rail aggregation. An agent may stay under its x402 budget, stay under its virtual-card budget, and stay under its wallet-transfer budget while exceeding the total task budget. Each rail can enforce its own rule while the organization loses the whole picture.

The budget source of truth should live above individual rails. Wallets, cards, facilitators, and checkout systems should receive scoped allowances from that source, not define independent financial authority.

Disputes, refunds, and accountability

Agent commerce needs crisp accountability. If an agent buys the wrong item, pays a spoofed endpoint, or misreads a user's constraints, who is responsible: the user, agent developer, wallet provider, merchant, facilitator, PSP, model provider, or orchestration layer? AP2 explicitly frames authorization, authenticity, and accountability as core questions.

Teams should design dispute evidence before launch: user mandate, agent trace summary, policy decision, payment payload, merchant response, fulfillment proof, refund route, and manual override history.

Open problems worth tracking

• Portable agent identity: how merchants recognize the same authorized agent across platforms.
• Cross-rail budget enforcement: one budget spanning cards, wallets, x402, and bank rails.
• Prompt-injection-resistant payment UX: approvals that show facts, not model summaries alone.
• Receipt standards: machine-readable proof of what an agent purchased and why.
• Refund and chargeback mapping: consistent reversals for agent-triggered transactions.
• Custody clarity: business-model-specific treatment for agent-controlled value.