Your AI Agent Tried Sending Money to the Wrong Wallet
Story type: reproducible demonstration, verified live against Payload production.
This did not happen to a customer. It is a controlled demonstration of a failure mode every agent operator should test before an agent receives payment access.
An agent can choose the right service, read the right price, and still prepare a payment with the wrong destination or an amount outside policy. If the payment system simply follows the agent's instructions, the mistake becomes a transaction.
The demonstration
Payload tested Veyline preflight with a genuine callx402 quote for a $0.10 diagnose action.
Three versions of the payment intent were checked:
- A valid intent to the designated rail payee returned a signed
ALLOW. The Ed25519 attestation signature was verified against the public key endpoint. - The same intent with the recipient changed to a dead address returned HTTP 403 with
UNAUTHORIZED_RECIPIENT. - An intent for $20.00 returned HTTP 403 with
TIER_SPEND_CAP_EXCEEDED, because the free test organization had a $10 per operation cap.
No payment was initiated or settled during the preflight test. The point was the decision before financial activity.
Why it matters
Agent instructions are not a control system. A model can copy an address incorrectly, follow stale configuration, or assemble an amount that no longer matches the quote. A separate policy check gives the operator a place to enforce facts that should not depend on the agent's memory or reasoning in that moment:
- the recipient must be authorized;
- the amount must match the quote;
- the amount must stay inside the applicable cap;
- the decision must expire quickly;
- the decision should be signed and reviewable where supported.
In the verified demonstration, the signed attestation had a 60 second lifetime. That short window limits how long a decision can be reused outside the context in which it was made.
The safer workflow
- Ask the payment service for a current quote.
- Build the payment intent from that quote, not from a cached price.
- Check recipient, amount, protocol, provider, and policy limits before payment.
- Treat a denial as useful evidence and stop rather than retrying with altered fields.
- Keep the authorization decision separate from the agent's own instructions.
Veyline does not remove the need for sound wallet controls or careful operations. Its role is narrower: check a proposed financial action against policy before the action proceeds.
Try the free version
The Veyline free sandbox gives an organization a free key and 1,000 operations per month. You can run the same preflight pattern with a valid intent, an unauthorized recipient, and an amount above the sandbox cap.
Start with the free evaluation at https://payloadhq.github.io/veyline.html and the service catalog at https://payloadhq.github.io/services.html.
The paid next step
Paid Veyline plans start with Developer at $99 per month for teams that need production governance around autonomous financial activity. Veyline is noncustodial. It does not hold customer funds, provide settlement, or guarantee protection against every attack or duplicate payment.
Evidence note: The ALLOW and denial results were verified live on October 15, 2026 and repeated in the corrected production battery on October 16, 2026.