When AI agents meet banking: The emerging boundaries of trust, access and accountability
Anil Prasad ( Co-founder and CEO)
As artificial intelligence evolves from answering questions to executing tasks, financial institutions face a fundamental challenge: how can they enable intelligent automation without surrendering control over sensitive financial decisions?
The next frontier of AI is not intelligence. It is authority.
Artificial intelligence is entering a new phase. For years, digital assistants primarily helped people search for information, summarise documents, analyse data, and make recommendations. The emergence of agentic AI changes this relationship. These systems can increasingly navigate applications, coordinate workflows, interact with external services, and execute tasks on a user’s behalf.
In personal finance, the possibilities are compelling. An AI agent could analyse spending patterns, identify unnecessary subscriptions, compare savings options, monitor upcoming payments, and help a user manage cash more efficiently. With appropriate permissions, it might eventually move beyond recommendations to execute selected financial transactions.
Yet this transition raises a question that is considerably more consequential than whether an AI model can complete a task accurately:
Who should have the authority to act on a person’s money, under what conditions, and who bears responsibility when something goes wrong?
Developments across the US financial sector in October 2026 have brought this question into sharp focus. Several major institutions have drawn boundaries around third-party AI agents accessing customer accounts, particularly when access involves customer credentials, automated browser interactions, or the ability to initiate transactions.
These decisions do not necessarily signal a rejection of agentic AI. Rather, they highlight the gap between what intelligent software can technically accomplish and what financial institutions are prepared to authorise.
1. A changing relationship between banks and AI agents
The recent debate gained momentum following Meta’s introduction of Muse on September 8, 2026. The personal AI agent was launched with financial account connectivity powered by Plaid, enabling users to connect accounts and obtain personalised financial insights. Meta describes Muse as an assistant designed to carry out tasks across applications, rather than simply respond to prompts. (Meta’s Muse announcement; Plaid’s announcement of its Muse integration).
The implications extend beyond another AI product launch. A financial assistant that can access account information may help users understand their finances. An agent capable of acting across applications could eventually influence where money is held, when payments are made, and how financial decisions are implemented.
That distinction has prompted a series of responses from financial institutions.
In October, JPMorgan Chase CEO Jamie Dimon publicly expressed concern about allowing unapproved external agents to access customer accounts using banking credentials. The bank has maintained a distinction between such access and customer-authorised data sharing through approved open-banking providers. (Fortune’s report on JPMorgan Chase).
Other institutions have expressed related concerns. Coverage by the Financial Times describes restrictions being introduced by major US banks, including Citigroup and Bank of America, amid questions about unauthorised transactions, security, and responsibility for AI-driven actions. (Financial Times coverage).
The common thread is not that AI agents cannot be useful. It is that access to financial infrastructure must be governed by more than an agent’s ability to log in and perform a task.
2. Reading financial information is not the same as controlling money
One of the most important distinctions in this debate is the difference between data access and transactional authority.
Consider three levels of interaction between an AI agent and a bank.
Level 1: Read and understand. The agent retrieves authorised information, such as balances, transaction histories, or investment holdings. It can categorise expenditure, identify trends, and explain financial activity.
Level 2: Recommend and prepare. The agent compares financial products, suggests a transfer, prepares a payment instruction, or develops a cash-management plan. The user remains responsible for deciding whether to proceed.
Level 3: Execute and manage. The agent initiates a transfer, pays a bill, changes an investment allocation, or carries out another financial action within a defined mandate.
Each step introduces a different level of risk.
Read-only access can still expose highly sensitive information, so it requires strong privacy and security controls. However, transactional access introduces an additional concern: an agent’s misunderstanding, compromised session, manipulated instruction, or unintended action could directly affect a person’s finances.
This is why authorised data-sharing mechanisms matter. A service such as Plaid can facilitate account connectivity without making every connected application equivalent to a bank-authorised payment interface. The specific permissions available depend on the institution, product, and connection.
The design principle should be straightforward: permission to observe must not automatically imply permission to act.
An agent authorised to analyse spending should not, by default, have the ability to transfer funds. An agent allowed to prepare a payment should not automatically be allowed to approve and execute it.
The permissions should reflect the task, the financial risk, and the user’s explicit intent.
3. The real challenge is accountability
Traditional digital banking generally operates within a defined relationship between the customer, the bank, and the bank’s approved channels. Agentic AI introduces additional parties: the agent developer, the model provider, the integration platform, and potentially other applications or intermediaries.
When an AI agent initiates an unexpected transaction, several questions arise:
Did the customer authorise the specific transaction, or only grant general access to the agent?
Did the agent interpret the user’s instructions correctly?
Was the agent operating within its permitted scope?
Was the transaction initiated through an approved interface?
Did a security failure, manipulated input, or software defect contribute to the outcome?
Which party is responsible for investigating the incident and absorbing the loss?
These questions become particularly difficult when a user’s broad instruction is translated into a sequence of autonomous actions.
For example, consider a user who tells an agent to optimise idle cash. The agent identifies a higher-yield account and initiates a transfer. The action may be consistent with its interpretation of the instruction, yet the user may not have intended to move the entire balance, use that particular destination, or transfer funds immediately.
The technical task may have succeeded while the financial outcome was wrong.
This is the difference between task completion and authorised intent. A reliable agent must do more than execute a plausible interpretation of a request. It must operate within clearly defined limits and establish when additional confirmation is necessary.
The contractual dimension
Wells Fargo’s published Online Access Agreement, scheduled to take effect on November 24, 2026, explicitly addresses third-party AI agents. The proposed terms state that, where customers permit such agents to access accounts or act on their behalf, certain agent instructions and transactions may be treated as customer-authorised, subject to applicable law and the agreement’s terms. They also place substantial responsibility on customers to supervise agents and manage their authorisations. (Wells Fargo’s upcoming Online Access Agreement).
This is an important development because it shows how AI agents are beginning to enter the contractual framework of digital banking.
However, contractual wording should not be confused with a universal determination of legal liability. The outcome of an actual dispute would depend on applicable law, the facts, the relevant agreements, and the circumstances of the transaction.
The broader lesson is that responsibility must be addressed before agents are granted consequential permissions—not left entirely to a dispute after a loss occurs.
4. Why browser automation and shared credentials are problematic
A major source of friction is the way some third-party agents interact with existing digital services.
An agent may use a browser to navigate a website, interpret its contents, and click through the same screens that a person would use. Another approach may involve a user providing login credentials or allowing software to operate within an authenticated session.
These methods can be convenient, but they create difficulties for high-security environments.
First, the institution may have limited visibility into the identity and behaviour of the agent. A browser session designed for human interaction may not provide a reliable way to distinguish an authorised AI agent from a malicious automation tool.
Second, credentials and sessions can carry permissions beyond those required for the immediate task. An agent intended to inspect transactions might gain access to functionality that was never necessary for its purpose.
Third, conventional interfaces are not necessarily designed to communicate the boundaries of an agent’s authority. A changed screen, unexpected prompt, or ambiguous confirmation could alter the sequence of actions.
Finally, when an agent operates through a customer’s authenticated session, reconstructing what happened can be difficult. Investigators may need to distinguish between the user’s original instruction, the agent’s interpretation, subsequent model-generated decisions, and the final transaction.
These concerns help explain why financial institutions may favour approved integrations and controlled access mechanisms over unrestricted browser automation.
The goal should not be to eliminate automation. It should be to ensure that automated actions are identifiable, authorised, constrained, and auditable.
5. From credentials to capability-based permissions
A more sustainable approach is to move away from treating access as an all-or-nothing decision.
Instead of granting an agent a customer’s full authenticated session, financial systems can expose narrowly defined capabilities.
For example, an agent might be permitted to:
Retrieve the balance of a specified account.
Read transactions for an agreed period.
Prepare a payment instruction without submitting it.
Initiate a transfer only to a previously approved beneficiary.
Execute payments below a defined threshold, where the bank and customer explicitly permit this.
Request additional approval whenever a transaction exceeds its authority.
These permissions should be enforced by the financial service or an independently controlled authorisation layer, not merely described in a prompt to the AI model.
A model instruction such as “never transfer more than ₹10,000” is not an adequate security control by itself. The underlying system must reject transactions that exceed the limit, regardless of what the model decides.
This is a fundamental principle of secure agentic system design: the model may propose an action, but a separate control layer must determine whether that action is permitted.
A capability-based architecture can also make access easier to revoke. If an agent is compromised or a user changes their mind, its permissions can be withdrawn without necessarily resetting every credential or disabling unrelated services.
6. Human approval should be risk-based, not universal
A common response to AI risk is to require a human to approve every action. This provides an important safeguard, but applying it indiscriminately can undermine the benefits of automation.
If every low-risk operation requires the same level of confirmation as a large financial transfer, users may experience excessive friction and become habituated to approving prompts without careful review.
A better approach is to classify actions according to their potential impact.
The exact thresholds will vary by institution, customer, transaction type, and regulatory requirements.
The principle is that autonomy should be earned through demonstrable reliability and constrained by the consequences of failure.
A trusted agent might eventually automate routine, low-value tasks within a carefully defined mandate while requiring explicit confirmation for unusual or high-impact transactions.
Importantly, a human approval screen is meaningful only if the person can understand what is being authorised. It should display the recipient, amount, source and destination accounts, timing, and any material fees—not simply ask whether the user wishes to continue.
7. The missing layer: an AI agent governance architecture
For financial institutions and technology providers, the response should go beyond blocking access or adding a confirmation dialog. Agentic AI requires a governance layer that connects identity, permissions, policy enforcement, monitoring, and accountability.
A practical architecture would include six components.
i) Agent identity
Every participating agent should have a verifiable identity. The institution should be able to distinguish an approved agent, an individual user, and an unauthorised automated process.
ii) Explicit authorisation
Permissions should be specific to the account, operation, transaction limits, beneficiary, and duration of access. The system should not assume that consent to read data also grants consent to transact.
iii) Policy enforcement
A separate policy engine should validate proposed actions against the user’s permissions, the institution’s controls, applicable restrictions, and transaction-specific requirements.
iv) Independent confirmation
Sensitive operations should trigger the appropriate authentication or confirmation process. High-impact actions should not rely solely on the same AI agent that proposed them.
v) Monitoring and auditability
The system should maintain a traceable record of the original instruction, the agent’s proposed action, policy decisions, user approvals, execution results, and any exceptions. Sensitive information should be protected through appropriate access controls and retention policies.
vi) Revocation and incident response
Users and institutions need a reliable mechanism to suspend an agent, revoke its access, stop pending operations where possible, and investigate suspicious activity. Revocation should apply to active permissions, not merely prevent future logins.
Together, these capabilities create a foundation for controlled autonomy.
The architecture should also address prompt injection, manipulated external content, compromised integrations, replayed requests, duplicate payments, and unexpected changes in agent behaviour. For financial transactions, idempotency controls, transaction limits, anomaly detection, and reconciliation are particularly important.
None of these measures eliminates risk. Their purpose is to ensure that a failure in one component does not automatically become an uncontrolled financial event.
8. The opportunity for open standards and interoperable systems
A further challenge is that the agent ecosystem is fragmented. Banks, AI developers, payment networks, identity providers, and integration platforms may each implement different ways of identifying agents and expressing permissions.
Without common conventions, an institution must make difficult decisions about each external agent and each integration. Users may also struggle to understand what they have authorised and how to revoke it.
Open standards and interoperable interfaces could help address this problem.
The development of structured APIs, delegated authorisation, machine-readable permissions, and verifiable agent identities can provide a more reliable alternative to sharing passwords or relying on visual browser interaction.
Relevant initiatives and technical foundations include:
OpenID Foundation: Standards for identity, authentication, and delegated authorisation.
OAuth 2.0: A widely used framework for granting limited access to protected resources without sharing the account owner’s password with every connected application.
Financial Data Exchange (FDX): An industry initiative focused on interoperable, consumer-permissioned financial data sharing.
FAPI — Financial-grade API: Security profiles designed for high-security API environments, including financial services.
NIST AI Risk Management Framework: Guidance for identifying, assessing, and managing AI-related risks.
OWASP Top 10 for Large Language Model Applications: A resource covering security risks relevant to LLM-powered applications, including prompt injection and excessive agency.
These initiatives address different parts of the problem; none should be interpreted as a complete, universally adopted standard for autonomous financial transactions. Their value lies in helping the industry build interoperable controls rather than relying on informal trust between applications.
9. What this means for banks, fintechs, and AI developers
The immediate restrictions create practical challenges for developers building personal finance agents. An integration that works through a browser today may be blocked tomorrow. A service that can retrieve data may not be permitted to initiate a transaction.
For technology providers, this changes the product-development question.
It is no longer sufficient to demonstrate that an agent can navigate a website, interpret account information, or complete a sequence of actions. Developers must also demonstrate that the agent respects permissions, operates within defined limits, and provides evidence of what it has done.
Banks, in turn, face a strategic choice. They can develop their own assistants, provide controlled interfaces to external agents, or adopt a hybrid approach. Regardless of the route chosen, their long-term challenge will be to enable useful automation without compromising customer trust.
Fintechs may have an opportunity to become trusted intermediaries that translate user intent into authorised financial operations. To do so, they will need to demonstrate more than a capable AI model. Their systems must incorporate secure integrations, robust identity management, transaction controls, auditability, and clear responsibility for failures.
There is also a commercial dimension. Agents that help customers compare financial products and move funds more efficiently could change customer behaviour and increase competition for deposits. This is one possible factor behind the tension between autonomous financial assistants and established institutions. However, commercial incentives should not be confused with the security rationale: protecting customers from unauthorised access and transactions remains a legitimate concern irrespective of competitive effects.
For all participants, the opportunity is to build systems in which security and user autonomy reinforce one another.
10. A perspective for India and emerging digital financial ecosystems
These developments are particularly relevant to markets such as India, where digital payments, account aggregation, mobile banking, and AI adoption are evolving together.
India’s financial ecosystem already offers important building blocks for controlled digital interactions. The Account Aggregator ecosystem is designed around consent-based sharing of financial information, while the Reserve Bank of India’s official website provides the regulatory context for banking and payment systems.
However, consent to share financial information should not be treated as equivalent to authority to initiate payments. Data access, payment initiation, authentication, and liability are distinct questions that require their own controls and legal foundations.
As AI agents become more capable, Indian financial institutions and technology providers will need to determine how these existing frameworks interact with autonomous software acting on behalf of individuals and businesses.
Potential applications extend beyond personal banking. Businesses could use agents to reconcile accounts, prepare supplier payments, monitor receivables, manage expenses, and support treasury operations. In these environments, delegated authority may need to reflect corporate approval hierarchies, separation of duties, transaction limits, and audit requirements.
A well-designed agentic financial system should therefore accommodate both individual consent and institutional governance. It should be possible to automate routine work without bypassing the controls that make financial operations accountable.
Conclusion: Trust must be engineered into autonomy
The recent response from major financial institutions illustrates a defining tension in the evolution of agentic AI. The technology is advancing towards systems that can act independently, but financial infrastructure cannot rely on capability alone as a basis for trust.
Blocking unapproved agents may be a reasonable immediate safeguard. It is not, by itself, a complete long-term architecture for an agent-driven economy.
The more durable path lies in establishing clear agent identities, narrowly scoped permissions, independent policy enforcement, risk-based approvals, reliable audit trails, and effective revocation mechanisms. It also requires contractual and regulatory clarity about responsibility when autonomous systems act incorrectly or outside their intended scope.
The objective should not be to prevent AI agents from participating in financial services. It should be to make their participation safe, transparent, and accountable.
Ultimately, the most valuable financial AI agent will not be the one with the broadest access or the greatest degree of autonomy. It will be the one that can demonstrate that every consequential action is justified by the user’s intent, permitted by the governing rules, and traceable after execution.
The future of agentic finance will depend not only on how intelligently systems can act, but on how reliably they know when they are allowed to act.
Suggested references for publication
These are useful links to retain at the end of the blog or hyperlink within the article.
Meta — Introducing Muse: Official announcement, September 8, 2026
Plaid — Plaid powers Meta’s new AI agent, Muse: Financial account connectivity and Muse
Fortune — JPMorgan’s restrictions on third-party AI agents: October 2026 reporting
Financial Times — Citi and other banks restrict third-party AI agents: Industry response and concerns
Wells Fargo — Upcoming Online Access Agreement: Official agreement effective November 24, 2026
Financial Data Exchange: Consumer-permissioned financial data sharing
OpenID Foundation: Identity and authorisation standards
Sahamati: India’s Account Aggregator ecosystem
Comments