When AI Agents Gain Access to Business Money

In the week of 21 October 2026 two companies announced products that let software agents act with a business's or a person's financial and credential infrastructure. On 21 October Stripe announced Treasury for agents, which lets agents connected to a business's Treasury account check balances, pay invoices, move funds between accounts and convert currencies. On 22 October 1Password announced 1Password for Agents, which lets a personal agent request a login from the user's vault, with the user approving each request, so that the agent can sign in without being given the password.

The two products are different in kind. One routes financial actions through a payments platform. The other brokers access to the credentials that sit in front of every other service. Taken together they mark a transition that earlier notes in this programme treated as prospective: agents are being given the means to reach money, not merely to advise about it.

The question this note asks is institutional. When an agent can reach a business's money, which of the things a business normally relies on to control its money are actually in place? The note separates seven of them — agent identity, access permission, financial authority, human approval, legal delegation, mandate and liability — and asks, for each, what the two announcements show, what is live, what is in preview, what is merely announced, and what is not addressed in the sources read.

The central proposition is the programme's own and is not a claim made by either vendor:

Permission to reach money is not a mandate to spend it. The October 2026 announcements supply the first, in increasingly careful form, and leave the second to be supplied elsewhere.

The note is deliberately modest about what it can show. It rests on three vendor documents. It does not show that either product fails, that agents have misused either product, or that any customer has suffered a loss. It shows which questions the published material answers and which it does not.

[FACT] On 21 October 2026 Stripe announced Stripe Treasury for agents, described in the release as aimed at startups. The release says business finances "can now be executed by agents from inside the tools they use". It states that agents "can check balances, pay invoices, transfer funds between accounts, and convert currencies."

[FACT] The release describes two things as not yet available. "Businesses will soon be able to use agents for more tasks, including creating cards." And businesses will "be able to set spending limits for their agents in the coming weeks."

[FACT] On controls, the release says that startups using the product choose "which accounts and data agents can access", "whether they can read information or take action, and when money movement requires human approval." It states that "Stripe is not a bank" and that checking accounts are provided exclusively by Fifth Third Bank, National Association, Member FDIC. It also says that the product includes "various distinct Stripe products" and refers the reader to the applicable product terms.

[FACT] The release's illustrative customer is a business whose founder uses his own agent to check the business's balances, subscriptions, failed payments and refunds each morning, among other things, a use described in the present tense. The same release says that he "plans to use" the product to let the agent transfer money between the business's accounts, with "all payments approved" by him, and that he will be able to ask the agent to prepare financial actions and "approve them before any money moves." The money-moving use in the featured example is therefore described as a plan.

[FACT] The product documentation adds detail that the release does not. Stripe's model context protocol server supports two authentication methods: OAuth, "when a client accesses Stripe on behalf of your Stripe user account", and agent API keys, "when an AI application needs independent, persistent access to Stripe." Permissions are set per capability, access can be granted to live-mode accounts or sandboxes separately, authorised sessions can be listed and revoked, and an administrator can enable or disable this access for a whole team. The documentation gives setup instructions for several agent clients, among them Claude, ChatGPT and Codex. It lists five Treasury-specific tools — a balance summary, currency conversion, sending money to a recipient, setting up a recipient, and transferring money between supported Stripe balances — and labels each of them "Public preview". It states: "By default, you need to review and approve any action that your agent takes that results in live money movement."

[INFERENCE] The release and the documentation can be reconciled but they are not the same statement. The release speaks in the present tense about what agents "can" do and what finances "can now" be executed. The documentation, as read on 27 October 2026, labels the individual tools as public preview. A reader who read only the release might reasonably conclude that the capability is generally available. A reader who read the documentation would conclude that it is available as a preview. Neither source, as read, describes it as generally available.

The table classifies each capability by the strongest statement the sources make about it. Available means the announcement describes it as available now. Preview means the vendor's documentation labels it "Public preview". Forthcoming means the source says "soon", "in the coming weeks" or "coming soon". Plan means a customer's stated intention. Not stated means the sources read do not say.

[INFERENCE] Read at its strongest, the evidence supports the following. As of 27 October 2026 a business could, according to the vendor's own documentation and subject to availability and eligibility conditions that were not examined, give an agent preview access to a defined set of Treasury operations with human approval by default. Cards and spending limits were not described as available. A person could use a credential broker with a personal 1Password account, but the page does not establish that any particular agent could yet use it. Nothing in the sources shows what happens when the controls fail.

The two products delegate differently, and the difference matters for what can go wrong.

Stripe routes actions through the platform that operates the account. The agent calls defined operations. Each operation has a named permission in the documentation. [INFERENCE] The platform can therefore refuse an operation that the granted permission does not cover. The unit of control is the operation.

1Password brokers entry to a service, whether or not that service holds money. The agent asks to use a login; the vault fills it in. The unit of control, as described, is the credential.

[INFERENCE] A credential is a coarse instrument. A password to a bank or a supplier portal normally carries the full authority of the account it opens, not a subset of it. The page describes approval of the request to use a credential. It does not describe a constraint on what the agent may do once the session is open. Approving a login is an approval of access, not of any later action. The page is silent on whether any further control exists, and the destination service may provide one. This is a statement about what the page describes, not about what 1Password or the destination services can do.

[INFERENCE] For the same reason the destination service will usually see an authenticated session belonging to the person, not an agent. Whether services can or will distinguish agents from their principals is the identity question in its simplest form, and the 1Password page does not address it.

[INFERENCE] The Stripe model has an advantage the credential model lacks: the platform that moves the money is also the party that defines and enforces the operations. That concentrates the controls, and also concentrates the evidence. The documentation as read describes sessions that can be revoked but does not describe a record of what an agent did, and the release does not mention one. Whether such a record exists is not established here.

[INFERENCE] A real deployment may combine both products with a model from a third vendor. The business would then hold permission from one firm, credential custody with another and the reasoning agent from a third. No one of the three holds a view of the whole delegation, and none is described as being responsible for the mandate. The programme's recurring concern — that authority in agentic systems is assembled from parts supplied by different parties, and that nobody holds its provenance — is here a description of an ordinary product combination, not a speculation.

The consequences below follow from the structure of the products, not from observed outcomes. Each is labelled accordingly.

[INFERENCE] Delegated spending becomes a distinct class of transaction. A payment initiated by an agent under a human's standing approval differs from one a person initiates, in who decided, on what information and at what speed. The sources describe no mechanism by which a counterparty or a bank could tell the two apart.

[INFERENCE] The small business is the primary user and has the fewest internal controls. The release frames the product as for startups. A start-up may have one person who instructs, approves and reconciles. The control the products offer, human approval, is the control such a business is least able to separate from the agent's own instructions.

[HYPOTHESIS] Attacks will target what the agent reads, not what it holds. An agent that pays invoices reads invoices. If a fraudulent or altered invoice can be made to look ordinary to the agent, the permission and the approval may both be exercised correctly against a bad input. The programme has no evidence of this occurring with either product. It is stated because the controls described address who may act and not whether the input was genuine.

[INFERENCE] Evidence becomes the contested resource. When a payment is disputed, the question is who decided and under what authority. The sources describe controls that prevent actions. They do not describe records that reconstruct decisions. Research Note No. 1 identified this asymmetry in one enterprise agent-governance platform: controls that confer authority were specified in more detail than records that allow its exercise to be contested. The two October announcements, as far as they were read, fit that pattern and do not establish it.

[INFERENCE] Authority is assembled across firms. See Section 7. The institutional significance is that the arrangements which allocate loss when authority fails are, as far as the sources show, bilateral terms between each vendor and the business. The sources describe no arrangement that covers the combination.

[NORMATIVE] The programme proposes, as a research instrument and not as a standard, a seven-layer authority audit: for any deployment in which an agent can reach business money, record for each layer in Section 6 who supplies it, what evidence shows it is in place, and its status in the vocabulary of Section 5. A deployment that cannot answer for layers 5, 6 and 7 has not thereby failed; it has located the question that remains. The instrument has not been applied to any real deployment, has not been tested and has not been validated.

Internal critique

C1 — The note rests on vendor statements. Conceded. Three documents were read and none is independent. The note's claims about status are claims about what the vendors say.

C2 — The terms were not read. Conceded, and it is the largest limitation. The liability and delegation questions may be answered in documents this note did not examine. The note does not claim they are not.

C3 — Existing law may already cover agents. Possible and unaddressed. Established principles of agency and authorised signatories might resolve much of what the note calls unresolved. The note therefore states open questions as questions and not as gaps in the law. This is the objection the programme could least answer.

C4 — The seven layers may be over-divided. Partly conceded. Layers 3 and 6 are close. They are separated because a spending limit can exist without a purpose, and the products show exactly that.

C5 — Approval by default may be adequate. Not refuted. The Stripe default is a serious control. The note's point is narrower: approval does not supply identity, mandate or liability.

C6 — The note did not use the products. Conceded. Behaviour in practice may differ from the documents.

Falsification conditions

The note's central proposition would be weakened by any of the following.

• Product terms, read in full, that allocate liability for agent-initiated actions, and that are consistent across the vendors a business would combine.

• A documented control that binds an agent to a stated purpose and refuses actions outside it, in production and not in preview.

• Documented, retained records of what an approver was shown and what was executed.

• Evidence that counterparties can distinguish agent-initiated payments from others.
• Independent testing showing that approval by default is effective in practice at scale.

Primary sources. All read on 27 October 2026.

1. Stripe, "Introducing Stripe Treasury for agents", newsroom release, 21 October 2026. https://stripe.com/en-ee/newsroom/news/treasury-for-agents

2. Stripe, "Treasury for agents", product documentation, as it stood on 27 October 2026. https://docs.stripe.com/treasury/agents

3. John Torrey, "Introducing 1Password for Agents", 1Password blog, 22 October 2026. https://1password.com/blog/1password-for-ai-agents

Programme documents. Research Note No. 1 v0.1, When 10,000 Agents Act (12 October 2026); Research Note No. 2 v0.1, When the System Becomes Its Own Judge (13 October 2026); Revision & Evidence Ledger v0.3 with Supplement S; Working Paper No. 1 v0.3-RC1 (private review candidate).

No other literature is cited. The programme does not cite works it has not read.