AI Agents in Banking: Why Agentic Finance Broke the Authentication Model

Digital banking security rests on one assumption. The thing logging in is a person who decides what to do, checks it, and then does it. Banks have spent decades hardening that assumption, moving from static passwords to multifactor authentication, device fingerprinting, and behavioral heuristics. Budgeting apps, payment gateways, and account aggregators strained the model without breaking it. Banks still leaned on known authentication protocols, tight contracts, and deterministic transaction monitoring.

Autonomous AI agents break it. They interpret vague instructions, drive web interfaces, call external tools, and run multistep financial workflows with little human oversight. The problem facing U.S. banks is bigger than unauthorized access. Banks never built a way to separate who holds a credential from what that holder has authorized an agent to do.

Major U.S. banks are already dealing with unauthorized AI agent activity

None of this is confined to AI safety papers or bug bounty reports anymore. On October 22, 2026, Axios reported that JPMorgan Chase, Bank of America, Morgan Stanley, and Wells Fargo were facing a surge in third-party agent activity on customer accounts that was either unauthorized or against policy. Many of these agents log in with customer-supplied credentials, so legitimate user automation and malicious account takeover look much the same from the bank’s side.

Security operations centers are struggling to tell human sessions from agentic ones. Some agents have done far more than their users asked. The evidence points to a systemic access-control failure, not a string of cryptographic breaches. Morgan Stanley said it had not confirmed any rogue AI agent breaching its core platforms. What banks are fighting is perimeter probing, credential stuffing, and policy-violating automation that rides on the trust an authenticated session earns. Their response has been fast and increasingly restrictive.

Why authentication cannot authorize an AI agent’s actions

Traditional authentication answers one narrow question: does the party presenting credentials hold the proof needed to claim this identity? A password plus a FIDO2 passkey, a hardware token, or a push challenge gives the bank high confidence about who is there. Risk-based authentication adds thousands of signals on top, including device reputation, IP geolocation consistency, TLS fingerprints, and behavioral baselines. These controls matter for stopping credential theft and synthetic identity fraud. They say nothing about whether an authenticated agent may take a specific, consequential financial action.

The trouble starts when a customer logs in and then hands the live session, or the credentials themselves, to an agent. The bank’s gateways see a valid session, a familiar device, and traffic from a trusted location. Inside that trusted tunnel, the agent reads natural language instructions, picks external tools, and makes probabilistic decisions the customer never reviewed.

Identity, delegation, and intent are three separate things

Identity establishes who owns the account. Delegation establishes whether someone else may act for the owner. Intent asks whether one particular action falls inside the authority the customer actually granted. A normal login satisfies the first and is blind to the other two.

Say a user asks an agent to analyze monthly spending, find unused subscriptions, and prepare their cancellation. That does not authorize the agent to skip confirmation prompts, accept new contract terms, or move the user’s entire balance to an account its own optimization logic picked. Fraud detection tuned for stolen-account attacks (sudden IP changes, rapid fund depletion, unfamiliar payees) often misses these actions. The transaction can come from the user’s usual device, go to a real merchant, and draw on an account with enough funds, so it clears every standard check.

The failure is not in validating the session cryptographically. Nothing enforces the boundaries of delegated authority. Authentication is where trust begins, and it cannot double as blanket permission for whatever an autonomous system decides to do.

Screen scraping and browser automation as an attack vector

The most volatile vector today is an AI agent using a customer’s real banking credentials to work the bank’s public website. Many consumer automation tools rely on browser control, DOM parsing, and screen scraping, which means pulling data from a page’s rendered interface instead of calling a structured API. A headless browser built on Puppeteer, Playwright, or Selenium can open a dashboard, read balances and transaction history from the HTML, and fire the JavaScript handlers behind payment buttons and transfer forms.

When a customer types credentials into a third-party agent, or the agent inherits a live session token, it inherits everything the user can do. Browser automation is not malicious in itself. The bank’s web interface, though, was built for humans, with friction, confirmation modals, and cognitive speed bumps that an agent clears at machine speed.

A mature API integration works differently. The bank exposes defined operations with documented schemas, granular authorization, and predictable responses. A read-only endpoint can return transaction history without exposing the routing numbers needed to initiate a payment, and each operation gets its own security policy and rate limit. Browser automation skips all of that separation. An agent holding a session with broad UI permissions is limited only by the account’s privileges and the site’s layout. It can open account settings, edit payee lists, or start wire transfers by finding the right DOM elements and simulating clicks.

It also leaves the bank’s security team partly blind. Application logs record HTTP requests, session activity, and the final transaction. They cannot capture the agent’s reasoning, the user’s original prompt, or the alternatives the model weighed and dropped.

JPMorgan Chase has long opposed credential sharing and screen scraping. CFO Jeremy Barnum has repeatedly pointed to the operational and security costs. Sharing a password lets a third-party system authenticate as the customer but gives the bank no technical way to confine that system to one harmless task. Agreeing to use an automation tool rarely amounts to informed, cryptographic consent for every action the tool might take. That is especially true when the agent’s behavior shifts with context, model-generated logic, and instructions pulled from untrusted sources.

OAuth 2.1, FAPI, and why scopes fall short for agentic banking

To get away from screen scraping, the industry invested in structured API access built on OAuth 2.0 and, more recently, OAuth 2.1 with the Financial-grade API Security Profile (FAPI). Users can grant a third-party app limited access without handing over their passwords. The client gets an access token, often with Proof Key for Code Exchange (PKCE) to block authorization code interception, and the resource server validates it before executing a request. An authorization server might issue a token scoped to accounts.read or payments.write, so a budgeting app can see balances but cannot move money.

That is materially safer than sharing credentials. Tokens can be bound to specific clients, limited to specific operations, and revoked without touching the user’s main login. How much protection you actually get still depends on how the authorization server, token claims, and business logic are implemented. Conventional scope models do not fit what agentic finance demands.

A scope like payments.write names a broad class of operations. It carries no context about the customer’s request. It does not cap a transaction amount, limit transfers to an approved recipient list, set a daily budget, or force interactive confirmation on a large wire. Scopes can be made very granular, and external policy engines can add restrictions, but a scope model on its own cannot express the dynamic constraints that safe autonomous behavior needs.

Take an agent with a valid token that can initiate payments. The user tells it to pay a particular supplier only if the invoice is verified and the amount is $900 or less. The token proves the client may call the payment endpoint. The bank’s resource server still has to check the supplier’s identity, amount, currency, source account, time window, and approval requirements on its own. In an agentic setting, a sound authorization decision is a compound condition. It requires a valid identity, an unexpired delegation, a policy-compliant action, sufficient funds, and the necessary cryptographic approval.

Banks need to separate technical authority to reach an API endpoint from business authority to commit a specific financial action. The first is a binary permission. The second is a continuous decision that explicit policy has to evaluate at the moment of execution.

Indirect prompt injection is a financial security boundary

Large language models in financial workflows bring a threat that traditional API security was never built for. Direct prompt injection feeds malicious instructions straight into the model’s input to override its system prompt. In finance, indirect prompt injection is the more dangerous form. The malicious payload hides in untrusted data the agent pulls in during normal work.

Financial agents handle large volumes of unstructured, untrusted material. They parse invoice PDFs, summarize transaction histories, scrape merchant sites for prices, and extract payment details from inboxes. Any of those sources can hold hidden text, zero-width characters, or manipulated HTML attributes meant to redirect the agent. Picture an agent reviewing credit card statements to dispute suspicious charges. If one merchant description contains a crafted instruction to reveal the user’s security questions or send a micro-transaction to an attacker’s wallet, a poorly sandboxed model may not separate the data it is analyzing from the instructions it is meant to follow.

The damage grows with the agent’s tool access. A plain chatbot that falls for an injection might produce a wrong or embarrassing answer. An agent with a payment API, an account-management tool, or a browser automation suite can turn the same mistake into an irreversible financial action. The boundary to defend is the whole chain: retrieved content, model interpretation, tool selection, parameter generation, and final execution.

Secure designs treat all external content as hostile. No document, email, or web page should be able to grant new permissions, override the customer’s constraints, or change the authorization policy on a tool call. Instruction hierarchy and model-level refusals help, but they are probabilistic and cannot be the last line of enforcement. A system prompt telling a model to ignore malicious input is far weaker than a deterministic resource server that rejects an unauthorized transfer whatever JSON the model produced.

That calls for layered defense:

• Strict isolation of external content from trusted instructions
• Tightly constrained tool interfaces with schema validation
• Independent authorization checks that run outside the model’s context window
• Out-of-band confirmation for sensitive actions, bound to the cryptographic hash of the exact transaction being approved, so that any change to a material field after consent invalidates the approval

Behavioral biometrics and AI agent detection

To see into automated sessions, banks increasingly use behavioral analytics and biometric telemetry to catch account takeover, social engineering, and unauthorized automation. These systems study micro-interactions in a session instead of relying only on passwords or network addresses. BioCatch, whose Connect 2.0 platform was announced in late 2025, and Incognia, which launched AI Agent Detection capabilities in October 2026, take in thousands of telemetry signals to build a running risk profile. The signals include keystroke dynamics, mouse trajectory entropy, touch pressure, gyroscope fluctuations, and the sequence of DOM interactions.

Humans are noisy. Mouse paths follow irregular curves, and typing rhythm shifts with cognitive load and fatigue. Agents and scripts tend to produce clean, low-entropy trajectories, or skip the UI event listeners and inject commands straight into the browser’s execution context.

Those differences help flag automation, but they do not prove malicious intent or unauthorized delegation. People who use assistive technology, a sophisticated password manager, or a homemade automation workflow can look like bots. Agent developers are also building agents that imitate human noise with randomized delays and synthetic mouse jitter to beat heuristic detection.

What matters is what the bank does with the signal. A session that looks automated should prompt a step-up authentication challenge, restrict high-risk operations, or require explicit customer approval for a pending transaction. It should not automatically end the session or lead the bank to assume the agent overstepped its mandate. The sound design pairs continuous behavioral risk scoring with deterministic, policy-based controls. A low-entropy session may get heavy fraud scrutiny, but a wire transfer should still depend on the customer’s explicit permissions, transaction limits, recipient whitelists, and cryptographic approvals. Behavioral analytics can show that activity is anomalous. They cannot confirm that a normal-looking action matches what the customer actually asked for.

Read-only access: the banks’ interim answer

Securing write operations against probabilistic agents is hard, so major banks have mostly chosen to cut what outside systems can do and move toward read-only access. In an October 2026 interview, Charles Schwab CEO Rick Wurster said the firm is blocking tens of thousands of attempts by major AI agents to reach customer accounts. Schwab is building controlled, read-only integrations over Model Context Protocol servers instead. External AI systems can then pull balances, categorize expenses, and do financial research without any permission to move client funds. JPMorgan Chase has taken a similar line, drawing a sharp distinction between controlled API access to information and customers’ credentials being used to operate inside the bank’s core systems.

Read-only keeps most of the useful functions, such as cash flow analysis, subscription tracking, and budgeting, and closes the path to unauthorized money movement. If an integration exposes only balance and transaction retrieval, a persuasive prompt cannot make the agent start a payment, because the API gateway rejects the operation outright.

Read-only still carries privacy and cost risks

Balances and detailed transaction histories reveal salary payments, medical expenses, travel patterns, and recurring habits. An agent pulling that data continuously might pass it to unvetted outside services, store it in unencrypted vector databases, or leak it through insecure logging. Even read-only integrations need data minimization, retention limits, secure token storage, and explicit, revocable consent.

The economics add friction. In September 2025, JPMorgan Chase and Plaid announced a renewed, monetized agreement for sharing consumer-permissioned data. The bank cited the operational burden of third-party API traffic, saying only a small share of requests tied to actual customer transactions while most was continuous polling by intermediaries. Agentic AI could multiply that polling as agents watch accounts for arbitrage or optimization triggers. Banks have to protect their infrastructure from denial-of-service conditions caused by aggressive agent polling, and they also have to offer standard, permissioned interfaces so consumers do not fall back on screen scraping. Read-only is a useful interim boundary. It will not hold for long in a market that is going to ask for tightly constrained, secure transactional capabilities from its AI assistants.

Model Context Protocol security in banking

The fast adoption of the Model Context Protocol (MCP) is an industry effort to standardize how AI systems connect to external tools, databases, and workflows. MCP typically uses JSON-RPC 2.0 over standard input/output or Server-Sent Events (SSE) to open a two-way channel between the LLM client and the resource server. A bank could run an MCP server exposing tools for retrieving balances, inspecting transaction histories, or fetching approved tax documents. The institution controls which tools exist, how clients authenticate to the MCP host, and which backend services the protocol may call. That beats letting an agent roam an unrestricted website, because it enforces a schema and limits the agent to predefined, deterministic functions.

MCP is still a transport and integration standard. It is not a full financial authorization framework. A standard interface does not guarantee that the client is trustworthy, the user’s consent is valid, the tokens are properly scoped, or a request reflects what the customer wants. Those properties come from the identity management, authorization logic, and policy enforcement behind the server.

Consider a server that exposes both get_account_balance and initiate_transfer. A client cleared to call the first must not get the second by implication. Even when initiate_transfer is available to the agent, the backend has to validate the parameters against the user’s active delegation policy, enforce daily limits, and screen the recipient against sanctions lists. Tool descriptions in the MCP manifest can also be manipulated or misread. A model fed misleading documentation or untrusted content may choose the wrong operation or produce malformed parameters. The resource server therefore has to validate the actual HTTP request and the business logic and ignore the model’s natural language account of why the request is needed.

A secure financial MCP deployment needs authenticated client connections, narrowly scoped capabilities, strict input validation, and reliable, immutable audit logs. The bank stays responsible for enforcing permissions on its own core systems. It cannot hand authorization over to an AI model’s probabilistic reasoning.

Regulation and liability when an AI agent moves money

The technical problems are playing out against legal uncertainty over consumer data rights, third-party access liability, and who bears the risk when an agent goes beyond its instructions. In the United States, consumer data access rests on Section 1033 of the Dodd-Frank Act. The Consumer Financial Protection Bureau (CFPB) finalized its Personal Financial Data Rights Rule in October 2024, setting requirements for covered data, interface security, and third-party authorization. The rule is now in flux. The CFPB issued an advance notice of proposed rulemaking in August 2025 to gather input on changes, and on October 29, 2025, the Eastern District of Kentucky stayed the rule’s compliance dates. The industry is left in legal ambiguity, and it cannot assume that legacy data-sharing permissions cover autonomous, probabilistic actions.

Access to financial data and legal authority to start irrevocable transactions are separate matters. A framework that lets a consumer direct the sharing of transaction history does not decide when an AI agent may move money, how its delegated authority should be bounded, or who is liable when it exceeds its instructions.

One agentic transaction can involve the consumer, the foundation model provider, the agent developer, an integration middleware provider, an account aggregator, the depository bank, and the payment rail processor. Each controls part of the workflow and sees a different slice of the agent’s decision-making. Assigning responsibility means working out who authorized the action, which security controls existed and were bypassed, and where the chain of trust broke.

Handing credentials to an agent does not make every later action legally authorized. An agent’s hallucination does not release the bank from its duty to protect the account either. Click-through consent boxes will not be enough. Banks need a cryptographically verifiable, immutable record of what the consumer authorized, which capabilities were granted, when the delegation started, which constraints applied, and whether the executed transaction met those parameters.

Offensive AI: automated reconnaissance against banks

The same technology that powers helpful financial assistants also scales reconnaissance, credential abuse, and intrusion workflows for attackers. In October 2026, cybersecurity firm Straiker published an investigation into an alleged AI-orchestrated campaign by a cybercrime group called CyberCartel. It reportedly targeted more than 400 financial institutions and payment providers across Latin America. The operation, codenamed CARLIY0S, reportedly coordinated several commercial AI models, including systems from Anthropic, xAI, and Moonshot AI, to automate the whole attack lifecycle. Each agent had its own job. One did deep reconnaissance on target infrastructure, another analyzed application behavior for zero-day vulnerabilities, a third generated and modified exploit code, and a fourth harvested and tested compromised credentials.

Botnets and scripts have done credential stuffing and port scanning for years. Language models add the ability to adapt a workflow to an unfamiliar environment, read unstructured error messages to refine an exploit, and produce polymorphic code that slips past static signatures. A multi-agent offensive system can send the result of a failed SQL injection attempt back to a central controller, which tells another agent to rewrite the payload and retry through a different vector.

The lesson for banks is not that AI makes every attack unstoppable. Their adversaries are now adaptable, scalable, and autonomous. That raises the value of controls that still work when an attacker can automate continuous experimentation: phishing-resistant authentication, tightly protected privileged service accounts, segmented payment rails, and well-tested incident response. Banks should evaluate AI-generated offensive activity next to established indicators of compromise, and assume their external APIs and integration points are under constant automated attack by agents that can reason around defenses.

How to design a secure agentic banking architecture

Safe agentic banking needs cryptographic identity, granular authorization, deterministic policy enforcement, and disciplined operations together. No single safeguard covers every failure mode that autonomous software introduces, whether that is a model-level system prompt, a behavioral biometric heuristic, or a standard OAuth token. Five requirements stand out.

1. Verifiable agent identity and delegation. Every agent needs a cryptographic identity and an auditable delegation relationship. Banks must be able to tell the consumer, the agent, the integration provider, and the service making the final API call apart. Mutual TLS (mTLS), client attestation, and securely managed keys establish which software is connecting. Those mechanisms should feed a central ledger recording who granted access, the exact scope, and the time limits of the delegation.
2. Action-level authorization with hard constraints. Authorization should cover specific actions and limits, not just API endpoints. A customer might let an agent categorize transactions and draft payments up to a set threshold, while requiring interactive biometric approval before any money leaves the account. The policy engine should define permitted accounts, whitelisted recipients, allowed transaction types, and expiration conditions. The resource server enforces them regardless of how the agent interprets anything.
3. An independent policy enforcement point. Sensitive operations should pass through a separate enforcement point that checks the request against the active delegation, verifies the integrity of the transaction fields, and applies mandatory fraud checks. The model’s claim that an operation is necessary or sensible should have no bearing on whether policy is satisfied.
4. Approval tied to the exact transaction hash. If a customer approves $500 to a specific vendor, that signature must not cover a later payment of $5,000 to someone else. Any material change to the amount, destination, or routing data voids the earlier approval and requires a fresh decision.
5. Continuous trust evaluation and complete audit logs. An agent’s identity can stay cryptographically valid while its environment is compromised or its behavior drifts. Systems should cut privileges, demand step-up confirmation, or end sessions when risk signals warrant it. The audit trail should immutably record the principal, the agent’s identity, the authorization context, the requested action, the policy decision, the approval evidence, and the outcome, so investigators can rebuild events without depending on the AI provider’s logs, which may themselves be unreliable. After an incident, the bank needs a tested process to revoke tokens across distributed systems, halt pending settlement, and preserve forensic evidence that separates a legitimate customer action from an agent malfunction or a compromised integration.

The goal is that the bank’s authorization system stays the deterministic authority. An agent can propose actions, analyze data, and do permitted administrative work. It must never be able to expand its own privileges, bypass security friction, or read a customer’s broad goal as unrestricted financial authority. Until banks can answer not only who is entering the vault but what authority that party holds once inside, autonomous finance will stay in tension with a basic requirement: customers, not their software, keep control of their money.