AI agents are entering bank accounts. Where should permission stop?

By Thunkle · Reporting and technical sources checked 22 October 2026

“Help me manage this account” should not give an AI agent the same authority as the account owner. Reading a balance, suggesting a payment and sending money need different permissions.

That distinction is easy to understand in a conversation. It is harder to preserve when a product gives an agent a browser session, a large tool catalogue and a broad instruction to finish a task.

The problem is not confined to banking. An agent that can change an invoice, issue a refund, export customer records or alter production settings also needs a boundary between what it can suggest and what it can execute.

For a founder building those workflows, that boundary belongs in the application, not only in a prompt. Thunkle's developer-led security audits can review agreed authorization paths, privileged backend operations and the evidence that sensitive actions require the right approval.

What the bank-access report says

In a 22 October Axios report, Madison Mills described banks encountering third-party agents in customer accounts. Sources described both customer-permitted logins that conflicted with bank rules and activity that appeared independent of user instructions.

Those are different situations. A customer sharing access does not establish provider authorization. A reported concern about agent behavior is not proof of a confirmed breach at a named bank. Axios also included Morgan Stanley's statement that it had not observed rogue agents accessing its platforms, and Chase's warning against sharing login credentials.

The design question remains useful without declaring a banking catastrophe: how does your application establish that a particular user authorized this particular operation?

Separate reading, recommending and acting

Start with three distinct capabilities.

Read: retrieve information the user is allowed to access. For a budgeting assistant, that might be a limited transaction history from a supported connection.

Recommend: use that information to suggest something. The result should remain a proposal. A recommendation to move funds must not quietly become an instruction to a payment tool.

Act: submit an operation that changes state, shares information or creates an obligation. This needs its own authorization policy and, for sensitive operations, an explicit approval bound to what will happen.

These capabilities should map to different backend permissions and tool access. Hiding a button in the interface does not stop a direct request to the same endpoint. Nor does asking the model to be careful stop a tool it is already authorized to call.

A particularly risky shortcut is giving a read-only feature a full account session because it was quicker than integrating a supported, scoped access route. The permission boundary has then become the assistant's behavior, rather than a restriction the service enforces.

Use provider-supported delegated access where available, with the scopes and account selection the task requires. If a provider does not support the needed capability, that is a product constraint to resolve, not permission to work around its restrictions using stored customer passwords.

An action-approval matrix you can adapt

This is a conservative starting policy for an application design review. It is not a description of the features any bank or API supports, and it does not grant permission to connect to an account.

A product that only needs the first two rows should not ship credentials capable of performing the last five.

Make the approval specific enough to mean something

A generic “Allow” prompt is weak evidence. The person needs to see the operation being authorized, through a trusted application interface rather than a description the model can freely rewrite.

For a hypothetical payment workflow, a useful approval record would identify:

These are illustrative design fields, not a complete payment protocol. Keep secrets and unnecessary account data out of logs. Retain only the evidence needed for the operation, investigation and applicable obligations.

If the destination, amount or other significant detail changes, require a new approval. Do not accept a model-generated user_confirmed: true field as proof. The execution component needs to verify the approval belongs to this user and this operation, and that it is still usable.

OWASP's transaction authorization guidance explains why server-side checks, visible transaction details, expiry and protection against replay matter. Its AI agent security guidance likewise separates agent proposals from independently authorized execution.

An invoice is input, not permission

Consider a hypothetical assistant that reads an invoice before proposing a payment. Text inside the invoice says to use a new account, skip confirmation and mark the payment urgent.

The invoice may contain information relevant to the task. It is not an instruction from the account owner, and it cannot grant payment authority. That distinction must survive retrieval, summarization and the final tool call.

The same problem appears in emails, uploaded documents and API responses. A useful review follows an external input all the way to the sensitive operation. Where is the recipient validated? Which component checks the current user's permission? Can imported text supply an approval flag? What happens if the model requests a tool the product did not intend this feature to use?

A prompt can tell the model how to behave. It cannot replace an authorization rule enforced independently of that model.

Read-only access still needs a data boundary

Preventing transfers does not make financial data harmless. A read-only connection can still expose information through an export, a model request, a support log or a different user's conversation.

Decide which fields the feature actually needs and where those fields travel. A monthly spending summary may not require sending full account identifiers or retaining raw transactions indefinitely. Check tenant isolation in stored records, retrieval and conversation history, not only in the initial database query.

Review the failure paths too. A provider error should not dump an access token into a support response. A debugging feature should not make an otherwise private transaction history available to an ordinary user.

These are application-security questions. They remain relevant whether the agent was built with a coding assistant, an agent framework or entirely handwritten code.

“Disconnect” needs a testable meaning

Revocation is more than removing a connection from the settings screen.

Identify what your application can stop immediately, what the external provider must revoke and what has already been submitted. Review stored tokens, active sessions, scheduled work and queued actions according to the provider's behavior.

For example, a queued job should not continue retrieving data because it copied a token before the user disconnected. Conversely, disconnecting an agent must not be described as reversing a payment that the provider already accepted. Show an accurate state and a clear escalation route rather than guessing the outcome.

The support team also needs a way to trace an action without obtaining the customer's password or copying production tokens into chat.

Test the denied actions with a mock provider

Before connecting real financial accounts, use a mock provider, synthetic records and dummy recipients. The following is a proposed test set, not a report of live banking tests:

• A user with read access requests a write operation. The backend denies it even if the model asks confidently.
• A document contains instructions to change the recipient or bypass approval. It cannot authorize either action.
• A valid approval is reused or arrives through two concurrent requests. It cannot create duplicate execution.
• The recipient changes after approval. The previous approval cannot authorize the revised request.
• An approval expires, or the user disconnects before a queued action executes. The service rechecks the applicable permission and stops unauthorized work.
• A provider times out after submission. The application reconciles the status instead of blindly submitting again.
• One customer's request references another customer's account or approval. The service rejects it without exposing the other customer's details.

Record the expected result and the backend evidence, not just the final chat message. “The assistant refused” and “the server would not execute it” are different assurances.

Have the permission model reviewed before adding more autonomy

An impressive demo can hide a broad credential, a missing ownership check or an approval screen that the execution path never verifies. Adding more agent instructions does not reliably fix those problems.

Thunkle can review the agreed code paths, account boundaries and sensitive workflows, then give you evidence-backed findings and remediation guidance. Our paid security audit includes a free re-review of agreed fixes. Hardening and implementation are scoped separately through our development service.

Request a security audit quote. Describe what the agent can read, what it can change and which approval steps already exist. That is enough to start a scoping conversation without sharing customer financial records or credentials.

This article concerns application security design. It is not financial, legal or regulatory compliance advice. Financial integrations also need provider approval and appropriately qualified advice for the product and jurisdiction involved.