AI agents are changing how people interact with financial services. But when an autonomous agent can access an account, interpret instructions and initiate transactions, a new cybersecurity question emerges: can a bank trust an action simply because it came from an authenticated user session?
Imagine waking up one morning to discover that your AI assistant has paid the wrong bill, transferred money to an unintended recipient or changed your account settings.
You did not ask it to do any of those things. You simply instructed it to manage your finances.
The agent had your credentials. It accessed your account successfully. The bank's authentication mechanisms worked as designed.
So, what went wrong?
Perhaps the AI misunderstood your instructions. Perhaps malicious content manipulated its behaviour. Or perhaps the agent was granted more authority than it needed in the first place.
Now consider the same scenario involving thousands of customers, multiple financial institutions and AI agents operating automatically around the clock.
This is where AI convenience becomes a banking cybersecurity challenge.
When banks begin questioning AI agents
Recent reporting about major US financial institutions, including JPMorgan Chase, Bank of America and Wells Fargo, has highlighted growing concerns about third-party AI agents accessing customer banking accounts. The reported restrictions reflect a wider debate over agent access, customer authorization and responsibility for automated financial actions.
These developments do not mean that AI agents have successfully breached these banks or caused confirmed financial losses. Rather, they illustrate an important security concern: financial institutions need to understand and control what autonomous software is allowed to do on behalf of customers.
For banks, the question is no longer limited to whether a user can authenticate successfully. It is also whether the software acting for that user has legitimate authority to perform each requested action.
Traditional online banking security was largely designed around human interaction. A customer logs in, reviews information, selects an operation and confirms a transaction.
AI agents introduce a different operating model. They may interpret natural-language instructions, interact with several applications, call APIs and execute multistep workflows with limited human intervention.
The convenience is obvious. The security implications are less straightforward.
The difference between authentication and authorization
Consider a customer who tells an AI agent:
"Review my monthly expenses and pay my outstanding bills, but do not transfer more than $200 without asking me first."
The agent accesses the banking platform using a legitimate session. It identifies outstanding payments and begins processing them.
Everything appears normal until the agent misinterprets a payment instruction and attempts to transfer $800.
The bank has authenticated the session. But has the agent respected the customer's intended authorization?
This distinction matters.
Authentication establishes an identity. Authorization determines what that identity is permitted to do. Neither, by itself, guarantees that an action reflects the customer's actual intention.
An AI agent can be authenticated correctly and still make an unsafe decision. It can also operate within technically valid permissions while exceeding the authority the customer intended to delegate.
For security practitioners, this creates a fundamental challenge: a valid session does not make every action performed through that session legitimate.
Six ways AI agents can introduce banking risk
1. Excessive permissions: when access becomes authority
Suppose an AI assistant needs read-only access to account balances and transaction histories to prepare a monthly financial report.
Instead, it receives broad access that also permits payments, beneficiary changes and account modifications.
The agent may never intend to misuse these capabilities. However, a software defect, compromised component or manipulated instruction could trigger actions beyond its original purpose.
This is a familiar security problem expressed in a new form: excessive privilege.
Banks should apply least-privilege principles to AI agents, just as they do to employees, service accounts and applications. Read access, payment initiation and beneficiary management should be separate permissions, not an unrestricted package.
2. Prompt injection: the instruction the customer never gave
AI agents often process information from emails, documents, websites and other external sources.
Imagine an agent reviewing an email containing an invoice. Hidden or misleading instructions within the content attempt to convince the agent to disregard its original task and send payment details to an attacker.
The agent may interpret the malicious content as an instruction rather than untrusted data.
This is a form of prompt injection.
Traditional security tools may detect malware, suspicious network traffic or unauthorized login attempts. However, a prompt-injection attack can exploit the way an AI system interprets information and selects actions.
The challenge is especially serious when the agent can use privileged tools to access banking APIs or initiate transactions.
Banks and AI developers must therefore ensure that external content cannot independently grant permissions, override trusted policies or authorize financial operations.
3. Credential and token exposure
Some AI workflows rely on stored credentials, session cookies, API keys or access tokens.
If these secrets are exposed through insecure storage, application logs, a compromised endpoint or a vulnerable integration, an attacker may be able to impersonate the agent or reuse its access.
The risk increases when tokens are long-lived, permissions are broad or multiple services share the same credentials.
A stronger approach uses short-lived, narrowly scoped credentials, secure secret management, token revocation and clear separation between agent identities and human identities.
An AI agent should not need unrestricted access to a customer's banking credentials simply to complete a routine task.
4. The confused-deputy problem
An AI agent may have legitimate privileges that exceed those of the person or process requesting an action.
For example, a financial assistant might be authorized to access several accounts to consolidate expenses. An untrusted instruction could persuade it to use those privileges for a different purpose.
The agent becomes a kind of confused deputy: a privileged component manipulated into using its authority inappropriately.
This risk is not unique to artificial intelligence. However, agents that interpret ambiguous instructions and dynamically select tools can make the problem harder to anticipate.
Every sensitive operation should therefore be checked against the requesting user's permissions, the agent's delegated authority and the specific transaction being requested.
5. Automated mistakes at machine speed
A human may notice a suspicious payment before approving it. An autonomous agent may execute multiple actions before anyone recognizes the problem.
Consider an agent that repeatedly retries a failed payment, submits duplicate requests or misinterprets a merchant's billing information.
Depending on the banking system and its safeguards, the consequences could include duplicate transactions, customer complaints, reconciliation problems and operational disruption.
Transaction limits, idempotency controls, anomaly detection, rate limits and human approval gates can reduce these risks.
The objective is not to eliminate automation. It is to prevent one mistaken decision from becoming hundreds of consequential actions.
6. Accountability becomes complicated
When a fraudulent or unauthorized transaction occurs, investigators need to establish what happened and who or what initiated it.
Was the customer deceived? Did the agent misunderstand the instruction? Was an external service compromised? Did a developer grant excessive permissions? Did the bank's controls fail to recognize a suspicious operation?
Without reliable evidence, these questions become difficult to answer.
Banks should maintain auditable records of the agent's identity, delegated permissions, instructions, tool calls, policy decisions, approvals and resulting transactions, while protecting sensitive customer data.
These records are essential for incident response, dispute resolution, regulatory investigations and improving controls.
What should a bank's security team do differently?
The solution is not simply to block every AI agent. Nor should banks assume that an agent is trustworthy because it uses a legitimate API or authenticated session.
A practical security strategy should address the entire agent lifecycle.
1. Establish an AI agent inventory.
Identify which agents are permitted to interact with banking systems, who owns them, which services they access and what actions they can perform. Include third-party agents and internally developed automation.
2. Give each agent a distinct identity.
Avoid treating an autonomous agent as an ordinary employee or allowing multiple agents to share one service account. Distinct identities improve attribution, monitoring and access revocation.
3. Enforce least privilege and delegated authorization.
An agent should receive only the permissions necessary for its assigned task. Its authority should be limited by the customer's permissions and the scope of the delegation.
4. Require stronger controls for high-risk transactions.
Reading a transaction history should not require the same approval process as transferring funds or adding a new beneficiary. Apply transaction limits, risk-based verification and explicit confirmation for sensitive actions.
5. Monitor behaviour, not just logins.
Security monitoring should consider what an agent does after authentication. Unusual beneficiaries, abnormal transaction patterns, unexpected API calls, repeated failures and attempts to exceed delegated permissions may be important indicators.
6. Prepare for agent-specific incidents.
Incident-response playbooks should cover compromised agent credentials, prompt injection, unauthorized tool use, excessive transaction activity and third-party integration failures. Teams should be able to suspend an agent, revoke its tokens and preserve evidence quickly.
7. Test the complete workflow.
Security assessments should examine not only the AI model but also its tools, APIs, identity controls, external data sources, approval mechanisms and downstream systems. A well-behaved model cannot compensate for an insecure execution environment.
How can SOC teams detect suspicious agent activity?
For a security operations centre, AI agents create an opportunity to extend behavioural monitoring beyond conventional user and endpoint activity.
Consider a dedicated agent identity that normally performs read-only account queries but suddenly attempts beneficiary changes or high-value transfers.
A well-designed monitoring system could correlate:
- The agent's identity and delegated permissions.
- The requested operation and the applicable authorization policy.
- API gateway logs and authentication events.
- Transaction amount, destination and behavioural deviations.
- Approval records and the outcome of the operation.
A detection rule could flag an attempt by a read-only agent to initiate a payment, even if the request originates from an otherwise legitimate session.
Another rule could identify a burst of repeated transactions or a sudden change in the agent's usual API behaviour.
Where supported, these events can be integrated into SIEM and SOAR workflows. Automated containment should be carefully scoped: suspending a suspicious agent or revoking its token may be appropriate, while automatically blocking legitimate customer transactions without adequate context could create its own operational problems.
The key lesson for SOC teams is that monitoring successful authentication alone is insufficient. They must also monitor whether an agent's actions remain within its authorized purpose.
A governance question, not just a technical problem
The emergence of autonomous agents also raises questions about accountability.
If a customer authorizes an AI agent to manage payments, who is responsible when it performs an unintended transaction? How should responsibility be allocated if the agent provider, financial institution and customer each control different parts of the workflow?
The answers depend on applicable law, contracts, the facts of the incident and the relevant payment protections. They should not be assumed in advance.
Financial institutions should define clear responsibilities for agent approval, third-party risk management, customer consent, transaction authorization, auditability and incident handling.
Frameworks such as the NIST Cybersecurity Framework and NIST AI Risk Management Framework can help organize security and AI risk management. Existing access-control, identity, payment-security and operational-risk controls remain essential; agent-specific governance should complement rather than replace them.
What does this mean for Nepalese banks?
Although the reported developments involve US financial institutions, the underlying challenge is relevant to Nepal's banking sector as AI adoption expands.
Banking applications increasingly depend on APIs, digital payment infrastructure, third-party integrations and automated workflows. As AI assistants begin interacting with these services, banks will need to consider not only whether the integrations are secure but also whether the agent is authorized to perform each action.
For Nepalese banks, a sensible starting point would be to:
- Include AI agents in third-party risk assessments and technology inventories.
- Align agent access controls with existing identity and access management policies.
- Monitor privileged actions, API activity and transaction anomalies through existing security operations.
- Require clear authorization and appropriate confirmation for sensitive financial operations.
- Establish procedures for investigating and containing compromised or misbehaving agents.
- Review these controls against applicable Nepal Rastra Bank requirements and the bank's existing information security obligations.
The goal is not to discourage responsible AI adoption. It is to ensure that new automation does not create a gap between a customer's intentions and the financial actions a system can execute.
Related reading:
The real question: can your bank trust an AI agent?
AI agents may eventually become routine intermediaries between customers and financial institutions. They could help people manage expenses, reconcile accounts, identify suspicious transactions and automate administrative work.
But the more authority an agent receives, the greater the consequences of a mistake, manipulation or compromise.
Banks cannot rely exclusively on passwords, multifactor authentication or the assumption that an authenticated session represents a trustworthy decision. They need to verify the identity of the agent, constrain its authority, monitor its actions and maintain sufficient evidence to investigate failures.
The fundamental principles of banking security have not disappeared. Least privilege, separation of duties, transaction controls, audit trails and accountability remain as important as ever.
What has changed is the actor performing the work.
Yesterday, security teams primarily asked whether a human user was authorized to access a system. Today, they must increasingly ask whether an autonomous system is authorized to make a particular decision and execute it.
Because when an AI agent moves money, the critical security question is not simply whether it can access the account. It is whether the bank can prove that the action it took was authorized.
References and further reading
- Reuters — [Search for Reuters reporting on US banks restricting third-party AI agents](https://www.reuters.com/site-search/?query=AI%20agents%20banks).
- NIST — [Artificial Intelligence Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework).
- NIST — [Cybersecurity Framework](https://www.nist.gov/cyberframework).
- OWASP — [Top 10 for Large Language Model Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/).
- OWASP — [Agentic AI security resources](https://genai.owasp.org/).
