As of February 2026
The agent did not get hacked. It paid twice. An invoice agent spotted an overdue bill, initiated a payment, hit a transient timeout, and retried - and two payments cleared to the same vendor.
The model called it success. Ops called it a week of cleanup. This is the trap with AI agents in treasury: most designs stop at spend limits and roles. That is necessary, and it is not delegated payment authority. It is a speed bump.
Delegation object
Not a credential
who delegated, what purpose, which counterparties and rails, and when it expires.
Policy per attempt
Evaluated live
limits are a result of policy and context on every attempt, not a number stored in a UI.
Idempotency
Ledger-bound
bind the key to delegation, invoice, and amount so a retry cannot create a second payment.
The blueprint that holds up
Start with a delegation object, not a shared credential: who delegated, for what purpose, to which counterparties and rails, and when it expires. Evaluate policy on every attempt, so a limit is the output of policy and context rather than a number sitting in a settings screen. Then bind idempotency to the ledger - key it to the delegation ID, the invoice ID, and the amount - so a retry cannot mint a second payment.
What makes it defensible
Sign every intent with a nonce and a short expiry, so a replayed request dies at the edge instead of clearing. Keep a kill switch and an audit trail that reads like a case file: if you cannot reconstruct why an action was allowed, you cannot defend it after the fact. Delegating payments to software is old. Delegating them to autonomous software is what changes the governance bar.
If your platform cannot revoke an agent instantly, you are not delegating authority. You are delegating liability.
