An AI agent should not receive a broad mandate to “manage the money.” Its authority should be divided into four levels: viewing financial information, preparing an action, executing with human approval and executing autonomously within narrow boundaries. For many small businesses, the prudent default is to begin with the first two levels and expand authority only when they can detect errors, stop activity quickly and establish who authorized each transaction.
This question is becoming less theoretical. Stripe has announced Treasury for agents, describing workflows in which AI agents can check balances, pay invoices, transfer funds and convert currencies. Stripe says permissions and approval rules determine whether an action can proceed autonomously or must be escalated to a person.
Those are announced platform capabilities, not evidence that unattended treasury is appropriate for every company. Eligibility and onboarding requirements, regional availability, regulatory obligations and integration details may affect whether a business can use them. Stripe is also not a bank; banking services associated with Treasury are provided through partner institutions. Founders therefore need controls that extend beyond the agent’s interface to the underlying financial account, accounting records and internal approval process.
Define authority by action, not by job title
Calling an agent a “finance assistant” reveals little about what it can actually do. A useful permission register instead lists each action, the data it requires, the maximum financial exposure and the person responsible for reviewing the result.
The following four levels are Make Business recommendations derived from the risks involved. They are not a description of a single Stripe configuration, and businesses should verify which controls their financial platform and integration can enforce.
Level 1: Read-only access
At this level, the agent may retrieve information such as an available balance, invoice status or transaction history. It cannot create a payment instruction, change account details or move funds.
Read-only access is lower risk, but not harmless. Balance information, customer payments and supplier records are sensitive business data. Grant access only to the accounts and fields required for a defined task. An agent producing a daily cash summary, for example, may not need customer contact details or every historical transaction.
- Define the purpose: Specify the report, alert or question the access supports.
- Minimize scope: Restrict accounts, data fields and historical periods where the integration permits it.
- Protect credentials: Use dedicated connections rather than shared human credentials, and include them in a recurring AI agent access-control audit.
- Log access: Retain enough information to determine what the agent retrieved and when.
Level 2: Draft or recommendation
The agent may prepare an invoice, propose a transfer, identify a bill for payment or recommend a currency conversion, but it cannot submit the transaction. This can reduce administrative work without transferring final authority.
A draft should expose the evidence behind it: payee, amount, due date, account details, invoice reference and the source record used. The reviewer should not have to approve a vague message such as “pay the usual supplier.” They need a complete instruction that can be checked against the invoice and vendor master data.
Changes to bank details deserve separate treatment. A legitimate invoice from a known supplier does not validate newly supplied payment instructions. Require independent verification through an established contact channel before changing a beneficiary. The agent may flag the change, but it should not treat text in an email or attachment as sufficient authorization.
Level 3: Execution requiring human approval
Here, the agent can initiate or submit an action only after a named person approves it. Stripe and Anthropic have demonstrated this type of boundary in Claude Duet purchasing workflows, where an agent can prepare a purchase but owner approval is required before completion.
Approval must be more than a button placed at the end of the agent’s own conversation. The approver should see the beneficiary, amount, currency, funding account, purpose and any relevant exception. For higher-risk transactions, use a second channel or the financial platform’s authenticated approval flow.
Set approval thresholds according to potential loss and recoverability rather than convenience alone. A payment to a new overseas beneficiary may deserve review even when its value is modest. A recurring domestic payment to an established supplier may be less risky, although duplicate invoices and compromised vendor accounts remain possible.
Separation of duties also matters. Ideally, the person who changes vendor details is not the only person who approves the first payment to those details. A very small company may not have enough staff for complete separation. In that case, compensate with independent confirmation, delayed execution for unusual changes and prompt review by the founder or external bookkeeper.
Level 4: Narrowly bounded autonomous execution
Autonomous execution should be an exception for repetitive, predictable and low-exposure actions whose errors can be detected quickly. It should not be a general permission to transfer money whenever the model judges a payment reasonable.
A bounded policy can combine several controls:
- a maximum value per transaction and a cumulative daily limit;
- an allowlist of verified vendors and destination accounts;
- permitted currencies, funding accounts and transaction types;
- defined operating hours or frequency limits;
- automatic escalation for new beneficiaries, changed bank details, duplicates or unusual amounts;
- a prohibition on the agent changing its own limits, permissions or approval rules.
Not every integration will technically enforce every control. Before relying on a limit, test whether it is enforced by the financial platform, by an independent policy layer or merely expressed in the agent’s prompt. Prompt instructions alone should not be treated as a hard financial control. Where a platform lacks an enforceable boundary, keep the action at the approval-required level.
Controls that must surround every authority level
Reconciliation: Compare completed transactions with approved instructions and accounting records. The process should identify duplicates, altered amounts, unexpected fees, failed transactions and payments posted to the wrong ledger account. An agent can assist with matching, but exceptions need accountable human ownership.
Audit logs: Preserve the request, source data, agent output, approval event and final platform response. Logs should make it possible to reconstruct who or what proposed the transaction, which rule allowed it and whether the executed details matched the approved details.
Emergency revocation: Document how to disable the agent’s connection, revoke its credentials, suspend pending transactions where supported and contact the financial provider. Where staffing permits, at least two people should know the procedure. A sole founder should keep an accessible copy and identify an external contact who can assist. Test revocation before the agent receives execution authority; discovering during an incident that a token remains active is too late.
Independent review: The system that initiates payments should not be the sole source used to verify them. Bank or platform statements, accounting records and vendor documentation provide separate evidence. This principle is part of introducing AI decision-making without surrendering financial control.
A staged pilot for a small finance team
- Choose one narrow workflow. Start with a frequent, low-value process whose correct outcome is easy to verify, rather than payroll, tax payments, refunds or unrestricted supplier payments.
- Run in observation mode. Give the agent only the access needed to produce reports or alerts. Confirm that its source data is complete and timely.
- Compare recommendations with human decisions. Have the agent draft actions without submitting them. Record omissions, false matches, duplicate proposals and cases requiring clarification.
- Add authenticated approval. Permit initiation only after a human reviews the full transaction details. Reconcile every completed action during the pilot.
- Consider limited autonomy only after meeting predefined acceptance criteria. Restrict it to allowlisted parties and enforceable limits. Expand one variable at a time so any increase in errors or exceptions can be traced.
Before launch, assign an owner for the pilot, define which exceptions stop it and schedule a review date. Success should mean more than time saved. It should include accurate execution, complete records, manageable exception volume and the ability to reverse course without interrupting essential payments.
Rollback checklist
- Disable the agent or integration and revoke its credentials.
- Cancel or suspend pending instructions where the provider permits it.
- Review all activity since the last confirmed reconciliation.
- Notify the financial provider and, where applicable, the banking partner if unauthorized movement is suspected.
- Rotate affected credentials and inspect connected systems.
- Return the workflow to manual or draft-only operation.
- Preserve logs and document the trigger, exposure and corrective action.
- Restore authority only after the control failure has been understood and independently checked.
The practical dividing line is not whether an AI agent appears capable of completing a payment. It is whether the business can constrain that payment before execution, verify it afterward and stop the system when assumptions fail. Until those controls are real and tested, the agent should prepare financial work, not control the company’s money.
