Should AI Agents Move Money? Permissions, Approvals and Audit Trails

01 / The story

Should an AI agent be allowed to move money?

Only within authority your business can define, enforce and review outside the model. An agent may help match invoices, prepare a payment or flag an unusual refund without having permission to release funds. For high-impact transactions, Qlauson recommends a separate human approval gate tied to the exact payment, not a broad instruction to “handle the bills.” This applies established OWASP guidance to finance workflows. [1] [2]

The key question is not whether the assistant sounds trustworthy. It is whether the payment system will reject a request that lacks valid authority. A useful agent can still misread an invoice, repeat an action after a timeout or follow misleading outside content. Malicious interference and ordinary errors are different causes, but both can produce an unwanted payment.

This analysis focuses on business payments, refunds and treasury operations, not investment advice or a claim that any named bank has adopted these controls. The practical goal is to separate useful preparation from permission to spend.

02 / The story

A login is not approval for a particular transaction

Authentication checks who is signing in. Transaction authorization checks whether a specific action may proceed. OWASP explicitly distinguishes those processes and says users should be able to recognize significant transaction details when approving them. A signed-in session is not a substitute for a clear payment decision. [1]

For an agent-assisted workflow, split access into reading, proposing and executing. A balance reader needs no transfer permission. An invoice assistant may create a draft while remaining unable to change the supplier’s bank details. A payment executor should accept only requests that satisfy the business’s approval policy.

Keep these distinctions in the connected service, not just in the prompt. OWASP identifies excessive functionality, permissions and autonomy as sources of excessive agency. It recommends limiting available functions and privileges and enforcing authorization in downstream systems. A model’s promise to ask first is not an access control. [2]

03 / The story

Make approval refer to the payment that will actually happen

A useful approval screen shows the recipient, verified destination, amount, currency, source account and purpose. That is Qlauson’s suggested finance-specific record, based on OWASP’s requirement to identify and acknowledge significant transaction data. A short model-written summary should not replace those underlying details. [1]

If the recipient, amount or other significant details change after review, require fresh approval. OWASP describes protecting transaction data from modification, enforcing a valid sequence of steps and placing a final authorization check immediately before execution. This closes the gap between what a person approved and what a tool later submits. [1]

For higher-risk work, separate the requester from the approver. An agent that drafts a payment should not also possess the ability to grant its own exception. NIST SP 800-53 provides a broader, customizable security and privacy control catalog; it is useful governance context, not a ready-made rulebook for agent payments. The specific workflow here is an editorial recommendation, not a claimed NIST mandate. [3]

Approval also has to remain usable. If every small action triggers an urgent alert, reviewers may stop paying attention. Group low-risk preparation work for review, but make high-impact release decisions clear and specific. Do not turn one approval into an open-ended spending session.

04 / The story

Set limits the model cannot raise

Define which accounts, recipients and transaction types are allowed before a pilot begins. Set per-payment and total spending limits, approval expiry and conditions that stop execution. Qlauson recommends treating a new destination, a supplier bank-detail change or a policy exception as a separate review event, even when the proposed payment is small.

These are finance-specific applications of least privilege and rate limits, not universal thresholds prescribed by OWASP. The right limits depend on the business, its payment rails and its ability to detect and respond to errors. OWASP recommends reducing permissions, requiring approval for high-impact actions, and limiting action rates to improve the chance of intervention. [2]

Keep execution credentials in the controlled service rather than in prompts or invoice attachments. Separate the ability to use a narrow payment function from the ability to change its credentials, approval rules or logging settings. Restrict read access too: a read-only agent can still expose sensitive balances or customer records through another connected tool. [2]

05 / The story

A concise threat and control map

This table describes possible failure paths, not a list of observed financial losses. The controls apply OWASP transaction authorization and excessive-agency guidance; the retry example also uses Stripe documentation. None removes all risk. [1] [2] [4]

06 / The story

Retries need both technical protection and reconciliation

A timeout does not prove that a payment failed. Before an agent tries again, the workflow needs a reliable way to identify the original request and determine its status. Otherwise, an apparently helpful retry may become another instruction to pay.

Stripe documents idempotency keys: identifiers that let its server recognize retries of the same request. Its API v1 saves the first response after execution begins, while API v2 has different retry behavior. Teams must follow the documentation for their actual service and API version rather than assuming every payment tool behaves alike. [4]

Idempotency is not authorization. It does not decide whether the recipient is legitimate or whether the business approved the amount. Qlauson recommends linking each proposed obligation to its payment request, provider result and settlement record. When the result is uncertain, hold further execution for reconciliation rather than letting the agent guess.

07 / The story

Keep an audit trail that can explain a disputed payment

A chat transcript alone is a weak financial record. Preserve the initiating person or business process, agent identity, proposed payment details, relevant evidence, policy decision, approver identity, approval time and expiry, execution result and provider reference. This is Qlauson’s suggested record design; OWASP supports logging and monitoring agent extensions and downstream actions. [2]

Connect those events with a shared reference so reviewers can follow one obligation from draft to settlement. Record rejection and cancellation as well as success. Preserve enough version information to explain which tool and policy were in use, without storing unnecessary personal data or secrets.

Protect the records from alteration by the same identity that initiates payments. Give finance and security teams clear review duties, retention rules and escalation routes. Logging is evidence for investigation and reconciliation; it is not a promise that a payment can be reversed. Confirm recovery options with the actual provider before relying on them.

08 / The story

What documented attacker use does—and does not—establish

On November 13, 2025, Anthropic published an incident account concerning activity detected in mid-September 2025. The company said attackers used Claude Code in attempts against roughly thirty targets and succeeded in a small number of cases. It assessed the actor as Chinese state-sponsored with high confidence. Those are Anthropic’s findings and attribution, not conclusions independently verified by Qlauson. [5]

This is a vendor account of real-world activity, not a controlled demonstration. It is also not public, independently established proof of every reported compromise. Anthropic describes human target selection and important human decisions, and says the model sometimes invented credentials or overstated results. “AI-assisted” should not be read as “no human involvement.” [5]

The account does not establish that an agent moved customer money or bypassed a bank’s transaction controls. It supports taking attacker use seriously, but not inventing a financial incident. Separately, OWASP’s excessive-agency examples are illustrative attack scenarios; they should not be counted as confirmed compromises. [2] [5]

09 / The story

Start with a finance pilot that can stop

Begin with invoice matching, reconciliation suggestions or payment drafting while people retain release authority. Use synthetic or appropriately protected test data. Test changed destinations, expired approvals, duplicate requests, unavailable providers and incomplete settlement records. These are proposed defensive acceptance tests, not claims about observed attacks.

Assign an owner for payment policy, another for technical enforcement and a named person who can suspend execution. Test whether revocation blocks pending work as intended, and confirm what happens to requests already accepted by the provider. Stopping new requests is not the same as recalling a completed transfer.

Expand authority only when review shows that the workflow reliably enforces its limits and produces usable evidence. A pilot that saves drafting time but creates unresolved reconciliation work may not be an improvement. Human approval also has a cost, so measure reviewer workload alongside speed.

The business decision is not simply “autonomous or not.” It is which tasks to delegate, under what limits, with whose approval and with what recovery process. Keep the broader prompt-injection discussion in our existing AI agent security guide; for money movement, the distinct test is whether the transaction remains authorized even when the model is wrong.