DEV Community

iamthat
iamthat

Posted on Originally published at karta.rta.lat

Your agent can pay now. Here is the layer that decides whether it should.

#ai #webdev #security #crypto

Every payment rail for AI agents now answers one question: can this payment be verified?

x402 went to the Linux Foundation. AP2 to the FIDO Alliance. UCP and ACP cover checkout. EMVCo published a draft. Visa, Mastercard and Amex all have agent programmes.

None of them answers the other question: should this agent spend this money on this task, right now?

That gap is where money actually goes, and it is documented:

  • An agent paginating a paid API through a bug made 41 000 calls over one weekend. Every call was correctly signed and settled. A per-call limit never noticed — each call was legal. The budget was gone.
  • In a September 2026 preprint, hidden text in product descriptions made an AP2 shopping agent assemble a different cart than the one shown to the user in 56 % of trials. The mandate signed it faithfully.
  • Of 47 vendors checked in September, 11 publicly document a kill switch.

AP2's own security guidance assumes the agent may be compromised and calls prompt-injection prevention infeasible. That is the correct assumption — and it means the policy must live outside the model.

We measured the registry

I pulled the first 2 500 servers from the official MCP registry and split the ones that describe a payment, wallet or x402 function. 72 of them.

Of those 72: 11 mention a budget, 0 mention a limit or a cap, 0 mention a kill switch, 0 describe a per-task budget, 2 mention a receipt.

These are descriptions, not code — absence of a word is not absence of a feature. But it tells you what vendors consider worth a line, and the vocabulary of spending is present while the vocabulary of stopping is not. The script is nine lines of Python over a public API and you can re-run it (it is in the repository linked below).

The object that is missing

A task-bound spend envelope: budget, allowed payees, no subscriptions, expiry, owner, cost centre. Budget belongs to the task, not to the call — that is the whole difference between stopping a runaway loop and reading about it on Monday.

KARTA enforces it outside the model:

  • the gateway holds the key, the agent only asks;
  • the verdict is deterministic — ALLOW / HOLD / BLOCK with a rule id and a counterfactual;
  • a kill switch stops one agent in under two seconds, without stopping the fleet;
  • every allowed spend returns an Ed25519 receipt that a third party verifies offline, without trusting the vendor.

What you can check yourself

Three attacks, one command each, all refused:

python3 attacks/runaway_loop.py          # 41 000 payments -> stops at the task boundary
python3 attacks/prompt_injection_payee.py # new vendor from injected text -> BLOCK E03
python3 attacks/tool_poisoning_amount.py  # tool inflates price 1000x   -> BLOCK E04
Enter fullscreen mode Exit fullscreen mode

The invariant is tested, not asserted: 100 parallel spend requests against a 50 × $0.05 budget produce exactly 50 approvals, and a 1 000-call loop at $0.01 against a $5 budget produces exactly 500.

Honest state

Pre-revenue. No paying customers. 33 personalised letters to platforms, wallet providers and payment sellers — zero replies so far. The public MCP server is rated A by Glama (Healthy, six tools) and listed in the official registry. 413 automated tests.

Two limits I will not paper over: this is the decision layer, not a settlement rail, and mainnet payment execution is disabled by default. If you need a spend cap today, there are simpler tools; if you need to prove to an auditor that a payment was inside the task budget, that is the gap.

Why I am writing this

Because the number is checkable and the code runs in ten minutes. If you are building agents that pay, I would rather hear where this breaks than sell you a licence — five teams get 30 days free, with one honest paragraph in return.

Top comments (0)