"Your agent's wallet needs a policy, not just a signer"

Give an AI agent a wallet and it can pay for APIs. That part works today. The x402 flow is simple: the server answers 402 with payment requirements, the agent signs, the payment settles, the resource arrives.

The problem is what the agent signs. The reference x402 clients pay whatever a 402 asks for — there is no checkpoint between "the server named a price" and "the wallet paid it." A signer, by design, answers one question: can this key produce a valid signature? It has no opinion on whether the payment should happen. Every loss mode below happens with a perfectly valid signature, produced by an agent doing exactly what it was told.

That is why the control point for agent payments is not the signer. It is a policy decision made before signing: ALLOW, DENY, or ESCALATE to a human. This article is about the four failure modes that decision exists to catch, and what a preflight check actually evaluates.

The four ways an agent loses money while working correctly

1. The infinite payment loop. An endpoint keeps returning 402, or the agent retries a failing paid call in a loop. Each attempt is small, valid, and authorized by the same logic that authorized the first one. The loss is not one bad payment; it is the same payment, hundreds of times, at machine speed. A signer sees nothing wrong. A policy layer sees a frequency problem.

2. Prompt injection via a malicious endpoint. The agent is directed — by a poisoned tool result, a compromised page, a manipulated instruction — to pay an endpoint it has never dealt with. The payment itself is well-formed. What is wrong is the counterparty and the context, and neither of those is visible to a signing function. They are visible to a check that asks: is this recipient within policy for this agent, this action, this amount?

3. Amount hallucination. The model misreads a requirement, misplaces a decimal, converts units loosely, and signs for a hundred times the intended price. Signature valid. Balance sufficient. Payment settled. The check that catches this is not cryptographic; it is a per-transaction cap that the amount is compared against before signing, by something that is not the model.

4. Frequency-based drainage. No single payment is remarkable. The aggregate is: thousands of small, in-policy-looking payments to the same counterparty across a day, draining the wallet below any per-transaction limit. This is why a per-tx cap alone is not a policy. The daily aggregate and the rate have to be evaluated too, against state that persists across calls.

Notice the pattern: in all four, nothing about the signature is wrong. If your only control is at the signer, you have no control at the point where these failures occur.

What a preflight check actually evaluates

A preflight authorization check takes the proposed payment — agent, action, counterparty, amount, and the payment intent it answers — and evaluates it against a policy before any signature exists. The checks that matter map one-to-one onto the failure modes:

• Limits per transaction and per day. The amount is compared to a per-action cap and an aggregate daily cap. Amount hallucination dies at the per-tx cap; frequency drainage dies at the daily aggregate — but only if the check tracks what the agent has already spent today, which means the policy layer keeps state, not just rules.
• Counterparty. Is this recipient an endpoint this agent is permitted to pay at all? Allowlist policy turns the injected-endpoint case into a deny instead of a settlement.
• Intent binding. The authorization is bound to a specific intent — this payment, for this action, against this requirement — with nonce and replay protection, so an authorization issued for one payment cannot be replayed to authorize another, and a retry cannot silently become a second payment for the same intent.
• Frequency. Rate and repetition are evaluated as part of the decision, which is what separates a loop from a legitimate repeated purchase.

Then the check returns one of three verdicts:

• ALLOW — the payment is within policy on every axis. It proceeds.
• DENY — it violates a hard limit: over cap, counterparty not permitted, replay detected. It does not proceed, and the denial is recorded.
• ESCALATE — it is not clearly forbidden, and it is not clearly routine: above a threshold you set for human review, or a pattern the policy flags as ambiguous. The agent pauses and submits the proposed payment for a human to approve or deny. This is the verdict that makes autonomy usable: the agent acts alone inside the envelope you defined, and a human decides at the envelope's edge — not after the money moved.

Every verdict — allow, deny, escalate — goes into an audit trail. When an operator later asks "why did the agent pay this, or try to," the answer is a decision record, not a reconstruction from transaction hashes.

Where Veyline fits — and exactly what is live

Veyline (by Payload) is that authorization layer for x402 agent payments: non-custodial transaction authorization that returns ALLOW / DENY / ESCALATE against spending caps, per-action limits, counterparty and intent checks, with nonce/replay protection and an audit trail for every decision. The first fact about it is the custody fact: Veyline never holds your funds and never holds your keys. It authorizes customer transactions; it does not custody or move money. An authorization service that needed your keys to protect your wallet would be solving the problem by becoming it.

Now the status, stated as plainly as the capability — because in this category the gap between the pitch and the provable surface is where buyers get hurt:

• Provable today: Veyline has executed real, non-custodial pilot settlements on Base — two $0.01 USDC transactions, run deliberately under tight pilot limits ($0.01 per transaction, $0.05 per day), both settled successfully with the transactions recorded on-chain. Small numbers on purpose: they are the shape of the product working as designed — capped, authorized, recorded.
• Callable today: the preflight decision is exposed for evaluation — veyline_preflight is available via MCP, alongside read-only MCP/A2A interfaces, so you can test what a policy check returns without integrating anything.
• Not live: managed execution. The KMS-backed signing path is fail-closed and has not passed its separate mainnet acceptance, and the commercial rollout of managed execution is not available today. If a payment of yours needs executing right now, Veyline's honest answer is that the authorization and preflight layer is what exists — not a turnkey execution service. We would rather publish that sentence than let you discover it in integration.

The checklist

Before an agent under your control signs its next payment, you should be able to answer all five:

1. What is the largest single payment this agent can make without a human seeing it first — and is that number enforced somewhere that is not the model?
2. What is its daily ceiling, and does anything track the aggregate across calls?
3. Which counterparties may it pay? If the answer is "any endpoint that returns a 402," that is the injected-endpoint failure with a roadmap.
4. Is each authorization bound to one intent, with replay protection — or can a retry become a second payment?
5. When the agent is denied or escalated, where is that recorded, and can you read the decision later?

If you cannot answer these, your agent does not have a payment policy. It has a signer and a hope. The signer is doing its job. It was just never the job that needed doing.