When AI agents can pay, treat the loss as yours and limit what they may do

Ishween Kaur of SoFi said on the AI Engineer show that an AI agent does not need to be broken to lose money. WebPulse draws a wider argument from her examples, one she did not make herself: plan as if a paying agent's loss is yours, and limit what the agent may do.

What was said

Kaur explained x402, which lets agents pay for data and APIs with tiny payments over HTTP. A seller replies with a 402 status and a payment requirement in a header. A facilitator service then checks the signature and settles the payment.

Payment puts the agent beyond the point where a human approves its work. She said: "But agent doesn't have to be even broken to lose money."

She broke the flow 20 ways and described six. In one, the seller changed the price in the header. With no guard, her agent settled 50 cents for an item listed at 5 cents. A check of the two price fields blocked it, but not changes to the wallet or network.

The prompt-injection run was one test on a test network, so no real money was lost. The agent paid the listed 5 cents. The seller's reply then pointed to a premium summary, and the agent paid 50 cents more. "So what would have costed me 5 cents actually costed me 55 cents."

A seller's reply is text the agent reads and may act on. The second payment looked valid, yet the outcome was wrong. Kaur said: "the payment can look right, like most of the cases my payments look right, but I got the wrong outcome."

Filter words missed soft hints. A model-based check worked in most cases but not all. In her one test run, locking the plan to a single seller call blocked the second payment, bringing that attack to zero. The agent still chose to pay.

Why it matters

Our reading: a check that asks only whether each payment is well formed can pass the payments that hurt you. Limits on what the agent may do hold even when its choice is wrong. Cap each task, such as how many calls it makes. Kaur suggested testing 20 to 25 success and failure cases to decide where guards, alerts or blocks belong.

The other side

Kaur did not discuss liability, so who bears a real loss is WebPulse's argument, not hers. A one-call limit suits a task where one call is the goal. Agents that buy from many sellers or retry after a timeout may need looser rules, and she did not say how to set them. She offered a method, not a universal rule: "Should your agent just pay? Probably not."