People have discovered AI agents running on cloud-based platforms, and suddenly, those agents are the answer to every bit of financial and operational friction in their lives. Move money from one bank account to another to chase a better interest rate. Pay bills automatically. Analyze spending patterns. Optimize subscriptions. Question fees. Move funds before a payment clears. Find the cheaper service. Make the decision, click the button, save the human from having to think about it. Everyone seems to think they are being very slick.
It sounds like progress. In many ways, it is progress. This is exactly the sort of thing cloud automation has been promising for years, only now the interface is not a brittle script or a scheduled batch job. An AI agent can reason across tasks, handle ambiguity, and act through the same websites and interfaces humans use.
The problem is that the websites on the other side did not sign up for this.
A recent Axios article reported that major US banks are detecting outside AI agents in customer accounts, including cases where agents use customer-provided credentials. Banks are struggling to tell whether activity is human-directed, agent-directed, or something else entirely. Several large banks are already restricting or blocking this kind of access.
Here is the conflict: Customers believe they have authorized the agent. The bank’s policies often say the customer can’t hand over credentials or let a nonhuman third party operate the account through the consumer website. Both sides think they are being reasonable. Both sides have a point.
The web was not built for agents
Most digital business systems were designed around a simple assumption: The user at the keyboard is the person who owns the account or someone explicitly delegated through an approved access mechanism. That assumption was already shaky with password sharing, screen scraping, personal finance aggregators, robotic process automation, and browser extensions. AI agents make it much shakier because instead of just reading information, they are deciding, sequencing, and acting.
A budgeting app that displays balances is one kind of risk. An agent that sees a balance, compares interest rates, moves money, pays a bill, cancels a service, and opens a support chat is something different. It is not merely access. It is agency.
Banks are the obvious first battleground because money is involved and financial regulation already contains strong consumer protections. But this is not merely a banking problem. It is a digital business problem. Amazon has the same issue. So do airlines, insurers, healthcare portals, tax services, subscription businesses, SaaS platforms, retailers, logistics providers, and government agencies. Any website that lets customers take meaningful action will have to decide whether an AI agent acting on behalf of a customer is a valid user, a bot, an approved integration, a policy violation, or a security incident.
Right now, the answer is usually, “We are not sure, but we don’t like it.”
Liability is the real problem
The technical challenges are hard, but the liability questions are worse. If an agent moves money incorrectly, who owns the mistake?
- The customer: “I never authorized that specific transaction.”
- The bank: “You gave your credentials to an outside agent in violation of our terms.”
- The agent platform: “We acted according to the user’s configuration.”
- The cloud provider: “We only provided the infrastructure.”
That is a circular firing squad, not a governance model.
In many countries, consumer financial rules tend to favor the customer when unauthorized or disputed transactions occur. That means a bank may be forced to unwind a problem even if the initiating event was a customer-authorized agent operating in a way the bank’s own policies prohibited. That is a nightmare scenario for banks. They get the downside of customer automation without the control plane to manage it.
Enterprises in other industries should pay close attention. If your website allows customers to place orders, cancel services, change plans, transfer assets, access private information, or trigger contractual obligations, you are in the same line of fire. Maybe the financial exposure is smaller. Maybe the regulatory burden is lighter. But the question is the same: When autonomous software acts through a customer account, what exactly did the customer authorize, and how would you prove it?
Updating policies and systems
Over the next two to three years, enterprises will go through a massive rejiggering of policies, rules, responsibilities, and technical controls. It will not be elegant. Terms of service will be updated to define AI agents, delegated automation, credential sharing, bot access, read-only access, transaction authority, and revocation. Authentication systems will need to distinguish among a human, an approved integration, an unsanctioned script, and an autonomous agent operating with some form of user permission. Customer support teams will need scripts for disputes involving agents. Legal teams will need new language. Security teams will need new detection models. Product teams will need to decide whether blocking agents is a feature, a bug, or a competitive disadvantage.
The first instinct will be to block everything. That is understandable, especially for banks. However, it is not a long-term strategy. Customers will want this capability. Businesses that make it impossible will frustrate customers who are trying to automate routine tasks. Businesses that make it too easy will inherit unacceptable risk.
The middle ground will likely look like controlled delegation. Read-only access for basic analysis. Transaction limits for approved agents. Fine-grained permissions. Authorization that expires. Strong audit trails. Extra authentication for high-risk actions. Clear consent screens written for humans, not lawyers. Certified agent ecosystems. APIs that support customer intent without requiring agents to impersonate humans through websites.
It’s clear we need to stop pretending the browser session is the right abstraction for this.
What should enterprises do now?
Enterprises that depend on customer-facing websites should assume agents are already knocking on the door. Some are probably already inside.
The first task is to classify the actions customers can take through digital channels. Reading a balance, downloading an invoice, changing a shipping address, closing an account, moving funds, or accepting a contract are different kinds of events. Each needs a risk rating and a policy for delegated automation.
The second task is to create an explicit access model. Do not leave this buried in a vague anti-bot clause. Decide what kinds of agents are allowed, what they can do, how they identify themselves, how customers authorize them, how authorization is revoked, and how disputes are handled.
The third task is to build better telemetry. If you cannot distinguish a human from automation, you cannot manage the risk. That does not mean blocking every agent. It does mean you need enough signal to decide whether the action is normal, authorized, high risk, or suspicious.
The fourth task is to offer a sanctioned path. If customers want agents to analyze spending, compare options, or automate routine tasks, give them a safe API or delegated access mechanism. If you do not, they will use credential sharing and browser automation anyway, and you will have less visibility and more risk.