Author: Nick Sawinyh, Head of Product & GTM, Veodyn

Agentic payments look like an open question, and they are not one. The question worth asking is not whether autonomous software will be given authority to move money. In one corner of finance it has had that authority for years, and the results are already on the record. The lesson from that corner is unglamorous. Nearly all of the safety lives in the scope of the authority you issued. By contrast, almost none of it lives in the agent’s judgment.

I spent 2020 to 2024 co-founding DexGuru, a DeFi trading and analytics platform. Before that I ran product and marketing at bZx, a DeFi lending protocol, which included running communications through exploit events. Afterwards I did business development at Sablier, where payments run as streams that release continuously without anyone pressing send, across a protocol that has served hundreds of thousands of users. In all of it, money moved under programmatic authority, at machine speed, with no human in the loop at the moment of execution. That is the deployment fintech is now building as agentic payments, and it is worth knowing how it fails before you build it.

The agentic payments failure that really cost people money

The pattern that did the most damage I watched was not a clever exploit. It was the unlimited approval.

To let a contract move your tokens, you grant it an allowance. The convenient default was to approve an unbounded amount once, so the user never had to approve again. Months later, when that contract turned out to have a flaw, the loss was not bounded by the transaction the user had intended. It was bounded by the allowance they had granted and forgotten about.

bZx is the case I watched from inside. In November 2021, an attacker compromised a developer credential, took over the Polygon and BSC deployments, and drained not only the protocol but every wallet still holding an unlimited approval to it. Losses ran into the tens of millions. The users who lost money had made one decision, months earlier, about convenience.

Nothing in that story requires a bad model, a bad prompt, or an adversary inside your context window. Substitute agent for contract and you have the agentic payments architecture most companies are shipping right now. A long-lived credential, with a scope nobody re-examines, handed to a component whose behavior is governed by instructions.

Three agentic payments guardrails that hold up

Scope the credential, not the behavior. An instruction in a system prompt is a suggestion competing with every other token in the context. An issued credential is a fact enforced elsewhere. Payments infrastructure already has the right primitives for agentic payments. In fact it has had them for years. Think virtual card numbers, mandates with per-payee and per-amount limits, single-use tokens, and expiry. The mistake is inventing a new control layer in the prompt while handing the agent a general-purpose credential underneath. Instead, use the rail’s own primitives, and issue the narrowest one that lets the task complete.

Separate what proposes from what executes. If the process that decides to pay also holds the credential that pays, there is no control, just a well-written intention. The autonomous cloud-operations agent I built cannot call the destructive API at all. It can only request execution. Moreover the request has to carry an approval binding three things together. Those three are the specific resource, the specific action, and proof a human reviewed it. A separate executor with its own credentials verifies all three before anything runs. Crucially, the agent has no way to satisfy that check without a real approval having happened.

That maps onto agentic payments without much translation. Bind the payee, the amount, and the artifact that justified the payment, meaning the invoice itself rather than a summary of it. Then check them at execution, in a component the agent cannot write to.

Put the ceiling outside the model, and make it about totals. Money has a property that makes it different from other destructive actions. It aggregates. A few hundred individually reasonable payments, each one passing a per-transaction check, still add up to a bad quarter. So the limit that matters is velocity and cumulative spend over a window, enforced by the rail, where no amount of confident reasoning can raise it. Otherwise, per-transaction limits alone give you agentic payments that can be wrong at scale, one correct-looking payment at a time.

The agentic payments input nobody budgets for

An agent’s payment decisions come out of its memory and context. Which means the security question is not only whether it can pay. It is where the thing it believes came from.

I built a harness called RecallFence specifically to break cross-tenant agent memory. The fix that survived was pushing the tenant boundary down into the database with row-level security. So a bug in application code fails closed, rather than serving one customer’s context to another customer’s agent. In a chatbot, that class of bug is a privacy incident. In agentic payments it is the input to a transfer, and the resulting payment will be entirely valid. Correctly signed, within limits, wrong.

Where agentic payments accountability lands

Set the legal question aside, because operationally it resolves before the lawyers arrive. The counterparty has the money. The customer has the loss. And the entity whose credential moved it has to make the customer whole, then argue about it afterwards. The agent decided is not a category anyone downstream of you recognizes, and it will not be one this year either.

For agentic payments, the practical consequence is about evidence. Your incident review has to reconstruct why the payment happened, not just that it happened, and a chat transcript is not evidence. What you need is the authorization record. Which credential, what scope, what artifact justified the decision, which component executed it, and whether the state that justified it was still true at execution. If your logs can only prove a payment occurred, your postmortem is an opinion.

I should concede the part of this I got wrong myself. Working fast with agent tooling this year, I approved generated code I would have questioned coming from a person. Because it was fluent, and it was mine to review, and I was moving. Reviewer fatigue, not model failure, is what breaks most human-in-the-loop designs. If you gate everything, people approve everything, and you have built an expensive machine for producing rubber stamps. So gate what spends money and let the rest run.

The limits of what I am claiming about agentic payments

I have not operated an agent with production payment authority inside a bank. Nor should anything here be read as if I had. What I have built are the adjacent systems. Before that, I worked on rails where programmatic authority over money was already normal. That was years ahead of the current wave of AI in financial services. Those are the source of these lessons and the reason to test them against your own stack rather than adopt them.

Here is a test worth running. Assume the model is fully compromised. Now it wants to move as much money as it can. The ceiling is whatever permissions you have already granted. Write down the maximum it can move before something outside the model stops it, and how long that takes. Treat agentic payments the way you would treat any other adversarial threat model.

That number is your real agentic payments limit. Your policy document is a description of the limit you intended.

Nick Sawinyh is a product and engineering leader. Over a decade he has taken technically complex products to market across DeFi, AI tooling, and government technology. He co-founded DexGuru, a DeFi trading and analytics platform, and founded the DeFi discovery site DeFiPrime. Today he builds agent systems and data infrastructure.

Fintechbits covers agentic payments, AI infrastructure, and payments security. Nothing here constitutes financial or investment advice. All analysis represents the editorial views of the author and Fintechbits.