As of February 2026
A payment bot did not go rogue. The architecture did. One Friday evening a timeout in the payment service produced two valid-looking instructions for the same supplier payout.
The first was in review. The second was a retry from a downstream worker that had never been told the one click was already in progress. The model did nothing wrong. The runtime control did, because there was none.
Most payment teams optimize where the rules are defined, not where the error actually happens. Policy goes in config files, and everyone hopes retries with no idempotency and rail-specific quirks all behave the same way. In payments they do not. Mandate-based authorization protocols like Google’s AP2 give an agent a signed mandate to act, but a mandate is permission to start, not a guarantee the execution layer will finish it exactly once.
Identity lock
Immutable hash
the payment object hash stays immutable once policy evaluation starts.
Replay guard
One-time token
each execution path gets a one-time intent token, not a reusable request ID.
Rail-aware policy
Per rail
ACH, RTP, FedNow, and wire do not share one risk tolerance.
Where the error really happens
Not in the prompt, and not in the config file. It happens at execution time, when a retry, a worker restart, or a rail-specific quirk turns one intent into two movements.
A runtime control plane with state discipline
Separate execution into explicit checkpoints. An identity lock keeps the payment object hash immutable once policy evaluation begins, so nothing mutates mid-flight. A replay guard issues a one-time intent token per execution path instead of a reusable request ID, so the second instruction has nothing valid to ride. Rail-aware policy applies the right risk tolerance for ACH, RTP, FedNow, or wire rather than one shared rule. And an evidence chain logs every decision from API ingress to settlement outcome, so the whole thing can be replayed for audit.
