An agent that can pay for an API call has crossed an important line. It is no longer only choosing atool. It is exercising financial authority. Existing payment rails and payment APIs make it possible forsoftware to move value, but they do not answer the buyer-side question that matters before money moves:should this agent be allowed to pay this recipient, this amount, on this route, under this policy, rightnow? This paper defines policy-constrained financial execution: a buyer-side control model that separatesagent payment requests from payment-execution authority. The model evaluates operator-defined policythrough a controlled path before execution, with explicit payment intent state, authorization binding,budget reservation, deterministic retry identity, trust-gated decisions, conservative handling of ambiguousexternal outcomes, and local audit reconstruction. OmniClaw is used as the implementation artifact.The recorded evidence exercises configured policy and guard checks, hash-based message authenticationcode (HMAC)-boundauthorization snapshots, terminal-state enforcement, memory and Redis reservationbehavior under tested concurrency workloads, trust-policy decisions, unknown-outcome replay blockingin the tested intent path, and local audit reconstruction. The evidence is bounded: it does not proveexactly-once external payment effects, universal payment finality, external payment-service correctness,regulatory compliance, deployment-wide crash safety, or independently tamper-evident audit storage.
Abiola Adeshina (Fri,) studied this question.