Field notes
AI ·

Agentic payments under human policy

Agentic payments are payments initiated by software rather than by a person at a checkout. An AI agent holds credentials, decides that a purchase should happen, and moves the money itself — it pays an invoice, renews a subscription, books a charter — without a human tapping the final button. The distinguishing fact is the initiator. A person clicking buy is an ordinary card payment with a chatbot in front of it; an agentic payment is software doing the deciding, the authorizing, and the settling at the moment money actually moves. Everything hard about the category follows from that one property: the thing spending is not a person, and it does not get tired, suspicious, or nervous the way a person would before wiring money to a stranger.

Which is why the interesting question was never whether agents will spend money — they already can. The question is who sets the rules they spend under, and whether those rules are enforced by the platform or merely promised by the agent.

The failure mode is obvious, and that is the point

Give an agent a live payment credential and no ceiling, and you have built a wire-fraud incident that has not happened yet. The way it goes wrong is not exotic. A prompt injection hidden in a web page tells the agent to pay an attacker. A malformed tool description points a legitimate purchase at the wrong recipient. A retry loop attempts the same charge a thousand times because the success signal never came back. None of these require a clever adversary — they are the ordinary bugs of autonomous software, except the output is money leaving your account.

The tempting fix is to make the agent more careful: a better system prompt, a sterner instruction, a model that reasons harder about spending. That puts the control in the least trustworthy place in the system — the agent's own reasoning, the exact thing that can be talked out of it. A budget an agent can argue past is not a budget. The control has to live somewhere the agent cannot reach, which means outside the agent entirely.

Policy is the product, not the prompt

The containment model is a policy that the platform enforces before money moves, not after the agent has decided. Each agent gets a per-transaction cap and a daily limit — €150.00 a payment, €500.00 a day in our demo policy — with a monthly ceiling of €6,000.00 above that. These are hard walls checked by the platform, not promises kept by the agent. When the demo's travel bot tried to charter for €640.00, the payment was denied on the spot: over-cap, before a cent moved. An agent that behaves perfectly every single day still cannot drift past what the month allows.

A budget says how much; an allowlist says where. Agents pay only merchants you named in advance. The demo Ops Agent knows exactly four, and a €180.00 attempt at an unlisted vendor was refused as not-listed. Together the two draw a box: this much money, only to these recipients. Inside the box the agent runs at full speed and never has to ask; the box is the thing a human owns.

The question is never whether an AI agent will spend money. It is who wrote the rules it spends under — and the answer should always be a human, in advance, in writing.
— Protocore · Agents engineering

A human above the line

Some decisions are too big to leave to a box. So policy carries a threshold: a stated amount above which a human must approve before the payment goes through. In the demo the line sits at €100.00. When the Ops Agent flagged invoice #088 from Nord Logistics — €120.00, comfortably inside its €500.00 daily budget but above the approval line — it did not pay. It paused, put the proposal in front of a person, and waited. A one-line reply cleared it; the payment settled as reference 9F21-0716 and hit the audit log at 09:41. Below the line the agent moves on its own; above it, a person answers first.

The approval is not a checkbox that evaporates. It records who approved, on which device, at what time, with a signature attached — approved in app, phone key, 09:41:12. When someone later asks why a payment happened, the answer is a named person and a timestamp, not a shrug.

A kill-switch and a log that cannot be quietly edited

Even inside good walls, agents misbehave and policies turn out wrong. Two controls handle that. The first is a kill-switch: one tap pauses an agent and halts every payment it might initiate, instantly. Keys stay valid so nothing else breaks — the agent simply cannot spend until a human turns it back on, and its pending proposals freeze in place rather than vanishing. In the demo fleet the travel bot sits paused at €0.00 spent, its queue intact.

The second is an append-only audit log. Every decision is on the record: what the agent tried, which policy check passed or failed, who approved what, down to key rotations. One record reconstructs a whole payment — decision DEC-4471 shows the request, each policy check with its result (allowlist pass, cap pass, threshold escalate), the human signature, and the settled amount with its rail and reference. Each entry carries its own hash, the previous entry's hash, and its position in the chain — #4,471 in the demo — so editing any field breaks every record after it. The log exports as JSON, hash included: it is yours to hand an auditor, not ours to keep.

Keep settlement boring; keep novelty in authorization

There is a temptation to make agentic payments new all the way down — a new rail, a new instrument, a new way for money to travel. Resist it. The genuinely new part is authorization: how an agent proves it is allowed to pay, under whose policy, with what approval. Once a payment clears that gate it should settle on rails that have been boring for years. In the demo, an approved €120.00 proposal becomes an ordinary SEPA credit transfer — settled by SEPA Instant minutes after approval — indistinguishable downstream from a payment a person made. The bank does not know or care that an agent started it.

This split is deliberate. Boring rails are predictable, reversible where the scheme allows, and understood by every treasury and auditor you will ever deal with. Putting the novelty in policy and the payment on a settled rail means the risky, fast-moving part is the part you fully control, and the part that touches other people's banks is the part nobody has to relearn. Agents spend from the same core the rest of the payment family runs on — described at /products/pay — not from a parallel universe built for robots.

The protocol landscape is not settled — build for that

How an agent should present its identity and its mandate to a merchant is an open question. Several proposals compete over how an agent proves who it is, what it is authorized to buy, and how a merchant checks that before accepting the money. None has won, and betting the house on any single one today would be premature. The defensive posture is to treat the authorization protocol as swappable and keep everything behind it stable: the policy engine, the audit model, the settlement rail do not change when the wire format on the front does.

In practice that means a small, boring integration surface. Agents connect over MCP at mcp.protocore.io/agents; any framework that speaks the protocol can hold a wallet. The interface is deliberately narrow — propose a payment, receive a decision — because the interesting logic lives on the platform, not in the prompt. When the industry settles on how agents prove themselves to merchants, the front changes and the walls behind it stay exactly where they were.

Where this sits

Agentic payments are not a bet that autonomous software should spend without limit. They are the opposite: a bet that software will spend, so the limits had better be real, external, and legible. Budgets and allowlists draw the box, a threshold routes the big calls to a person, a kill-switch stops everything, and an append-only log means every payment can be reconstructed later. The product page at /products/agents walks the whole loop on the demo data used here — create an agent, set its policy, watch a payment escalate and settle — and /products/pay is the core those payments run on. The autonomy is real; so is the leash, and a human holds it.

Have a system to build?

Tell us the problem. We'll come back with an architecture and a plan.

Contact us