Banks are warning customers that sharing credentials with AI agents could make them responsible for what happens next. But what if the agent never needed those credentials in the first place?
I recently came across a warning from a major financial institution to its wealth management customers. One sentence caught my attention: “If you do share your credentials, keep in mind that you’re responsible for activity resulting from that access.”
At first glance, that sounds perfectly reasonable. Give someone your banking password, and you shouldn’t be surprised if they use it. But there’s something interesting about this warning.
What if I don’t share my credentials at all? What if I authenticate myself, using the bank’s approved authentication mechanism, and then let an AI agent operate my account? And what if that agent does something I never authorized? Who’s responsible then?
Welcome to one of the most interesting security and liability questions of the AI agent era.
I Followed the Bank’s Instructions. Exactly.
Let’s imagine a fairly ordinary scenario. I ask my AI assistant: “Review my investment portfolio, identify opportunities to improve my returns, and prepare some recommendations.”
The agent opens my bank’s website. The bank requires strong authentication: maybe a passkey, Face ID, or a QR code that sends me to my banking app. No problem. The agent asks me to take over for authentication. I authenticate myself using the bank’s approved process. Then I hand control of the browser back to the agent.
This isn’t some exotic hacking technique; human-to-agent handoff is a natural capability of computer-using AI assistants. The agent now operates inside my authenticated banking session. It can navigate my accounts, review my holdings, and interact with whatever functionality the website makes available to that session.
And here’s the important part: I never gave the agent my password. I never shared my biometric information. I never handed over my passkey’s private key. I simply authenticated myself and allowed the agent to continue.
So far, I’ve followed the bank’s warning about not sharing credentials. Now things get interesting.
The Agent Decides to Be Helpful. A Little Too Helpful.
My assistant reviews my portfolio. It identifies an investment it believes is underperforming and decides that selling it would improve my returns. Perhaps it misunderstands my instructions. Perhaps it interprets “improve my returns” as permission to rebalance my portfolio. Perhaps something in the information it encounters influences its decision.
Whatever the reason, it attempts to execute a trade. Let’s assume the bank’s application permits the transaction without additional human confirmation. The trade goes through.
I discover it later, and I’m furious. I never asked the agent to execute trades; I asked it to review my portfolio and prepare recommendations. So I call the bank. Who is responsible?
The bank might argue that I voluntarily gave the agent control of my authenticated session. The AI provider might argue that the agent was acting on my behalf. And I would argue that I never authorized the transaction.
Here’s the uncomfortable reality: all three statements could be true. And that’s exactly the problem.
We Keep Confusing Three Very Different Things
For decades, online banking security has focused heavily on answering one question: is this really the customer?
We’ve become remarkably good at answering it. Passwords evolved into multifactor authentication, hardware security keys, passkeys, and biometrics. Today, a bank can authenticate a customer with very high confidence. But AI agents introduce two additional questions that authentication alone cannot answer.
1. Who is actually operating the session?
The customer might have authenticated, but an AI agent could be controlling the browser. And that agent might not identify itself. To the bank, the session may appear to belong to the authenticated customer.
2. What is that operator authorized to do?
Even if the bank knows an agent is operating the session, that doesn’t establish what the customer permitted it to do. Review balances? Analyze investments? Prepare a transaction? Execute a transaction?
These are very different levels of authority. Yet when an agent operates through an ordinary authenticated browser session, the bank may have no reliable way to distinguish between them.
Authentication establishes identity; it does not automatically establish permission for every action that follows. That distinction has always mattered. AI agents are making it impossible to ignore.
But Wait. Didn’t I Authorize the Agent?
This is where the situation becomes genuinely complicated. I did authorize the agent to access my account. I did allow it to operate my authenticated session. But I didn’t authorize it to execute a trade.
Does granting an agent access imply granting it permission to use every capability available in the session? It shouldn’t.
Think about how we authorize people in the physical world. If I give my accountant access to my financial statements, I’m not authorizing them to transfer my money. If I ask my financial adviser to review my portfolio, I’m not necessarily authorizing them to execute trades.
We understand the difference between allowing someone to perform a task and granting them unrestricted authority over an account. But much of today’s digital infrastructure wasn’t designed to express that distinction when the person (or software) performing the task uses the customer’s own authenticated session.
The website sees an authenticated customer. The application exposes the capabilities available to that customer. And the agent can potentially interact with those capabilities. The missing piece is a reliable connection between the customer’s actual instructions and the actions the agent is permitted to perform.
So Am I Legally Responsible?
Not necessarily. And neither is the bank automatically responsible simply because the agent acted without my explicit permission. The answer depends on the circumstances, the type of account, the applicable laws, and the terms governing the relationship.
For example, US consumer protections under Regulation E can limit liability for certain unauthorized electronic fund transfers. Securities transactions and wealth management accounts can be governed by different rules. Whether an agent’s action qualifies as unauthorized may itself become a disputed question.
A bank might argue that I deliberately granted the agent access. I might argue that granting access to review my portfolio is not authorization to execute a trade. An AI provider might have its own terms addressing responsibility for actions performed by its software. And a warning about sharing credentials doesn’t necessarily resolve any of those questions.
There’s also an important technical distinction: handing control of an authenticated session to an agent might be treated as sharing access under some account agreements, even if no password or authentication secret was disclosed.
So this isn’t a clever loophole that makes customers immune from liability. It’s something more fundamental: our existing definitions of access, authorization, and responsibility are being tested by software that can independently decide how to carry out a customer’s instructions. And simply telling customers not to share their passwords doesn’t answer the hardest questions.
The Bank Might Not Even Know an Agent Was Involved
Here’s another complication: suppose the customer disputes the transaction. The bank investigates. Its records show that the customer successfully authenticated using a trusted device and a strong authentication mechanism. The transaction originated from the authenticated session.
There was no obvious account takeover. No stolen password. No failed authentication attempts. From the perspective of traditional authentication systems, everything may look legitimate.
But those records don’t necessarily reveal whether the transaction was initiated by the customer or by an AI agent controlling the browser. And even if the bank detects automation, that doesn’t establish which agent was involved, what the customer instructed it to do, or whether the action exceeded those instructions.
This creates an entirely new challenge for fraud investigations and transaction disputes. A transaction can be technically authenticated without being intentionally authorized by the customer.
That’s not an entirely new legal concept; banks have dealt with disputed authorization for decades. What’s new is the growing possibility that autonomous software is making the decisions between authentication and execution.
The Answer Isn’t to Ban AI Agents
It’s tempting to conclude that banks should simply block third-party AI agents. And for certain sensitive activities, restricting unsupported agents may be the right decision today. But I don’t believe blanket blocking is a sustainable long-term strategy.
Customers will increasingly want AI assistants to help manage their financial lives. They’ll want agents to analyze spending, compare financial products, monitor investments, identify opportunities, and complete increasingly complex tasks.
Banks can try to prevent that interaction, or they can develop the infrastructure to make it safer. The second approach requires moving beyond a security model that treats successful customer authentication as sufficient evidence that everything happening in the session is legitimate.
Banks need to understand when an AI agent is involved. Where technically possible, they need to identify which agent platform is operating and assess its risk characteristics. They need mechanisms for establishing what the customer has actually authorized the agent to do.
They need to monitor agent activity throughout the session and recognize when an agent attempts something unusual, sensitive, or outside its permitted scope. And they need ways to require additional customer confirmation before consequential actions.
Importantly, agent identification alone won’t solve this. Knowing that a legitimate AI assistant is operating the session doesn’t mean every action it takes is legitimate. An agent can be trustworthy in general and still misunderstand a customer’s instructions. It can be compromised. It can be manipulated by malicious content. Or it can simply make a mistake.
The objective isn’t just to know which agent is acting; it’s to understand whether the agent should be allowed to perform the action it’s attempting. That requires agent intelligence, delegated authorization, continuous risk evaluation, and transaction-level controls working together.
One Last Question
Let’s return to the bank’s original warning: “If you do share your credentials, keep in mind that you’re responsible for activity resulting from that access.”
It’s sensible advice. Customers shouldn’t hand their banking passwords to unknown third parties. But consider what happens when a customer follows that advice perfectly.
They never share their password. They authenticate using the bank’s strongest available mechanism. They allow an AI assistant to help them with a legitimate task. And the assistant does something they never intended.
Who is responsible?
The answer cannot be determined simply by asking whether the customer shared their credentials. We need to ask who was operating the account, what authority they had, what they actually did, and whether the customer authorized that specific action.
For the past two decades, we’ve invested enormous effort in making sure the right person can access a bank account. For the next decade, we’ll need to become equally good at ensuring that software acting on behalf of that person does only what it’s authorized to do.
Because in the age of AI agents, knowing who logged in is only the beginning of the story.
