All articles
AI AgentsBankingEnterprise ArchitectureSecurityEngineering Leadership

Blocking Outside AI Agents Is the Easy Part. Building the Front Door Is the Real Work.

Big U.S. banks have blocked third-party AI agents from moving customer money. That is a sensible pause, but engineering leaders should use it to build a governed front door for agents: distinct identity, narrow scopes, human approval and full audit trails.

Blocking Outside AI Agents Is the Easy Part. Building the Front Door Is the Real Work.

Over the last few weeks, some of the biggest names in U.S. banking said the same thing in slightly different words: outside AI agents are not going to move customer money. On their earnings calls, JPMorganChase, Bank of America, Citi and Schwab all drew that line, while largely allowing read-only access through approved connectors, as PYMNTS summarized. A few days later, reporting surfaced that banks were finding and removing unvetted agents already operating inside customer accounts, often because customers had handed their username and password to an AI tool (CBS News).

I spend my days building AI agents for a banking service portal, so I have read this story from both sides. My view: the blocks are reasonable for now, but they are a holding pattern, not a strategy. Customers are not going to stop using agents. The question for engineering leaders is what the approved path looks like, and how fast we can build it.

(These are my personal views, not those of my employer.)

Why the blocks make sense today

Start with what is actually happening. When a customer gives an agent their credentials, the bank cannot tell the difference between the customer and the software. Every control we have built (device fingerprinting, behavioral signals, step-up authentication) assumes a human is on the other end, or at least a known integration. A credential-sharing agent breaks that assumption silently.

Then there is liability. If an agent misreads an instruction and pays the wrong party, who absorbs the loss? The customer, the agent vendor, or the bank? Today there is no clean answer. PNC's CEO called agent transactions "incredibly unsafe" and said liability rules would be needed (PYMNTS). When I put on my MBA hat, that is the crux: risk you cannot price is risk you should not take.

So blocking writes while allowing reads is the conservative, defensible default. I would make the same call.

Why it can't be the end state

At Priceline I spent years on systems where a large share of traffic was not humans at all. It was metasearch engines, partners, scrapers and bots. We learned quickly that you cannot wish automated traffic away. You either give it a well-designed, governed channel, or it finds the undocumented one, and the undocumented one is always worse for everyone.

Banking is heading into the same pattern. Credential sharing is what happens when the legitimate channel does not exist. Some skeptics are already asking whether the blocks are about protecting customers or protecting revenue. I think the security concerns are real, but the best way to answer that question is to ship a safe alternative, not just a wall.

There are early signals of what that looks like. Schwab has said it will offer model context protocol (MCP) servers so a client's chosen AI can check balances and run research under Schwab's rules, while money movement stays with its own assistant. Robinhood has exposed agent access with customer-set spending limits and optional manual approvals. Those are different bets, but they share a principle: the institution defines the tools, the scopes and the guardrails, rather than letting an agent impersonate a person at the login screen.

What a "front door" for agents needs

When my team embedded agents into our ticket portal for triage, routing and follow-ups, the hard part was never the model. It was deciding what the agent was allowed to do, under whose authority, and what happened when it was wrong. Those lessons translate directly to external agents:

  1. A distinct identity for the agent. An agent should authenticate as an agent acting for a customer, not as the customer. That separation is what makes monitoring, revocation and audit possible.
  2. Narrow, explicit scopes. Read balances is one permission. Pay a known biller under $200 is another. Add a new payee is a third, and probably should not be delegable at first. Scope by action, not by account.
  3. Human approval on high-risk actions. In our internal system, anything with real customer impact goes to a person before it executes. For external agents, that becomes a push confirmation to the customer for money movement above a threshold. It adds friction exactly where friction belongs.
  4. Tools, not screens. Agents should call well-defined APIs or MCP tools with typed inputs, not drive a web UI. Structured tools are easier to validate, rate-limit and log. Screen-driving agents are fragile and nearly impossible to govern.
  5. Full traceability. Every agent action should record which agent, which customer consent, which scope and which instruction triggered it. When disputes come, and they will, that trail is what settles the liability question.

None of this is exotic. It is the same discipline we already apply to partner APIs and open banking connectors, extended to a new kind of client.

Takeaways for engineering leaders

  • Treat agents as a new channel, not a threat category. Give the work an owner, a roadmap and a budget, the same way you would for mobile or open APIs.
  • Start read-only, but design for write. Build the identity, consent and audit layers now, even if the first release only exposes balances and transactions. Retrofitting them later is far more expensive.
  • Get risk, legal and product in the room early. The liability model is a business decision as much as a technical one. Engineers should bring options with clear cost and risk trade-offs, not wait for a policy to arrive.
  • Dogfood internally first. If your own teams are building agents with Spring AI, Azure OpenAI or similar stacks, the guardrails you build there (approval workflows, scoped tools, logging) are a prototype of your external agent platform.
  • Measure the shadow traffic. If you are detecting credential-sharing agents, track the volume and what they try to do. That data tells you which use cases customers want most.

Closing thought

The banks that drew a hard line this month are protecting customers in the short term, and I respect that. But a wall only buys time. The institutions that come out ahead will be the ones that use that time to build a governed front door: agent identity, narrow scopes, human approval where it matters, and an audit trail that holds up in a dispute. Customers have already decided they want agents. Our job is to make the safe path the easy one.