Long-running financial agents need authority that expires, narrows, and can be revoked without dismantling the workflow.
The AI Operator | August 7, 2026
AI agents are beginning to stay on the case. A financial workflow may now stretch across days or weeks: collecting a payment, working an insurance claim, helping refinance a loan, or reconnecting a customer to an account at the moment a decision is needed.
That persistence is useful. It also breaks a quiet assumption in most financial controls: that permission and action happen close enough together to be treated as one event.
The operating question is no longer simply whether an agent can connect to an account. It is whether the authority granted on Monday should still be valid on Thursday after the balance, counterparty, policy, price, risk score, or customer intent has changed.
What's Happening This Week
Plaid describes an integration with Sierra in which customers can connect bank accounts inside agents built to pursue outcomes over days or weeks. The examples include collecting an overdue payment, refinancing a loan, settling an insurance claim, verifying finances, and making payments without leaving the conversation.
Checkout.com's agentic-commerce research says 42% of merchants are already testing the model. The Secure Technology Alliance has launched an Agentic Trust and Commerce Forum to work on trust, interoperability, and governance as assistants become transaction initiators. In parallel, bank-industry comments on payment-stablecoin rules underline that sanctions, compliance, and implementation obligations remain interdependent even when the underlying money movement gets easier.
These are different signals, not one finished system. Together they show the same architectural turn: financial capability is moving inside software that can remain active after the original moment of consent.
Why This Is a CFO Problem
Most access controls answer a static question: can this identity use this account or tool? A persistent agent creates a dynamic question: may this software continue pursuing this specific outcome under today's conditions?
A login session is not a business mandate. An account connection is not payment approval. A spending limit does not explain purpose. A consent captured at the beginning of a workflow does not prove that the customer or company still wants the same outcome after material facts change.
That gap will appear in ordinary ways. A collections agent negotiates after the invoice was disputed. A procurement agent continues after the budget was frozen. A claim agent prepares a payment after new evidence changes eligibility. A treasury workflow acts after liquidity falls below the threshold that made the original instruction sensible.
Nothing needs to be hacked. The agent can be authenticated, the tool can work as designed, and the payment can be technically valid. The failure is that authority outlived its context.
Finance leaders should therefore treat agent authority as a lease, not a credential. The workflow may persist, but permission should expire, narrow, pause, or require renewal when time passes or material conditions change.
The Operator's Log
Running scheduled AI workflows has made this distinction rather concrete for me. A recurring job may have a durable purpose, but that does not mean every run inherits unlimited authority from the day it was created.
The safer pattern is a bounded contract for each action: what the job may read, what it may draft, what it may stage, what requires a separate worker, what status must be present, and what preflight must pass. The schedule can continue. The authority is re-earned through current evidence.
That is why I am wary of controls expressed only as prose. “Do not pay without approval” is an instruction. A transaction path that cannot proceed without a current approval receipt is a control. “Stop if conditions change” is a wish. A lease that expires when price, amount, counterparty, policy, or risk crosses a threshold is an operating mechanism.
The practical design goal is not to make long-running agents timid. It is to let them retain context and momentum without letting yesterday's permission quietly become tomorrow's power.
Money Move
Before connecting a persistent agent to a financial workflow, write a one-page authority lease with seven fields:
- Purpose: the business outcome the agent may pursue.
- Allowed actions: observe, recommend, draft, stage, or execute-approved.
- Limits: amount, frequency, counterparty, account, geography, and tool boundaries.
- Expiry: the time or event that ends authority automatically.
- Revocation triggers: policy change, dispute, balance threshold, risk signal, contradictory evidence, or human stop.
- Evidence: the current approval, source data, and decision record required before action.
- Renewal owner: the named human who can extend or alter the lease.
Then test one awkward scenario: the agent is legitimate and still running, but the facts that justified its permission are no longer true. Can the system pause the financial action without destroying the agent's work, losing the evidence trail, or forcing three teams to reconstruct what happened?
If not, the workflow is persistent, but the control model is stale.
I would like to hear from operators building long-running agents in payments, finance, insurance, procurement, or collections. Where do you make authority expire, and which change in context forces a human back into the loop?
-dg