Most aren't. This is a working prototype of what ready looks like.
Your customers are starting to use AI assistants for everyday tasks — checking balances, paying bills, moving money, managing savings. When they do, they often aren't logging into your app. They're asking their AI to do it for them.
This creates a situation most banks have never designed for: an AI acting on behalf of a customer. Not a person logging in. An agent — a piece of software — calling your systems, claiming to represent someone.
That agent might be the customer's own Claude or ChatGPT. It might be a budgeting app they connected last year. It might be their financial adviser's software running a monthly review. It might be a rule the customer set up to move money automatically every month.
Each of these is real today. Each is arriving at the bank's door. The question is whether the bank has the infrastructure to handle them safely — or whether it's just hoping for the best.
“In 2026, Okta, Auth0, and Anthropic all shipped products specifically for agent access. The infrastructure is being built right now — the only question is whether banks are building the receiving end.”
Lara Trust is a working prototype showing what the bank side of the agent conversation looks like.
It covers the four things a bank needs to handle agent access safely:
It works across five different ways an agent can arrive — from a customer's personal AI assistant to a bank's own embedded AI to a third-party fintech app. The enforcement infrastructure is the same for all of them.
Agents don't all arrive the same way. Here are the five distinct access types this prototype handles.
A customer uses their own AI — Claude, ChatGPT, or another — to instruct the bank directly. They connect it once from within the banking app, choose what it's allowed to do, and the agent acts within those limits. The bank checks the agent's identity at connection and enforces the customer's rules on every request after that.
Example: a customer asks Claude to pay their Netflix bill from their current account
The bank's own embedded AI, available inside the banking app. No separate setup needed — it activates when the customer turns on AI features. Because the bank controls and operates this agent, it carries a higher level of trust than an external one. It still requires the customer to confirm anything unusual.
Example: a customer types "move £500 to my savings" in the banking app's chat
A fintech, service provider, or aggregator that the customer has explicitly connected. The customer goes through a one-time permission flow — similar to connecting an app via Open Banking — and the third-party app can then act within whatever the customer approved, without requiring the customer to be there each time.
Example: a savings app monitors the current account and sweeps money automatically based on rules the customer set
The customer explicitly gives a named person or organisation — a financial adviser, accountant, or family member — permission to have their agent access specific things. The access is time-limited, scoped to what was agreed, and tied to the identity of who it was granted to. The delegate's agent carries proof that the customer authorised it.
Example: a financial adviser's software reads a customer's portfolio monthly to prepare a review
The customer creates a standing instruction — "move anything above £5,000 in my current account to my ISA on the first of each month" — and the bank executes it automatically on schedule. The customer approved it once when they set it up. Every execution produces a signed receipt. The customer can pause or delete the rule at any time.
Example: end-of-month ISA sweep, automated bill payments, savings round-ups
The same enforcement infrastructure handles all five — but how each type enrolls, authenticates, and manages consent is different.
| Your AI assistant | Lara Bank AI | Third-party app | Delegated access | Scheduled rules | |
|---|---|---|---|---|---|
| Who operates it | The customer | The bank | A third-party company | A named delegate | The customer (automated) |
| How it connects | Customer connects it from the banking app | Turned on in app settings | One-time permission flow, similar to Open Banking | Customer grants named access via invitation | Customer creates a rule in the banking app |
| How it proves who it is | Agent token plus verification from the AI provider | Inherits the customer's active app session | Stored access token, refreshed automatically | Chain of tokens proving who delegated to whom | Pre-approved policy — no runtime authentication needed |
| How consent works | Customer sets limits at connection; step-up required for exceptions | Routine actions are implicit; step-up required for unusual ones | Customer selects what the app can do at the point of connection | Customer grants specific, named, time-limited access | Customer approves once at rule creation |
| Does the customer need to be there? | Not always | Yes | No | No | No |
| How to revoke | Customer taps revoke in the banking app | Toggle off AI features in settings | Remove from connected apps, or access expires | Customer or the delegate can revoke | Customer deletes or pauses the rule |
| Trust level | Verified commercial | Bank-operated (highest) | Third-party registered | Delegated | Policy-bound |
| Enforcement | Border Gateway + policy check | Border Gateway + policy check | Border Gateway + policy check | Border Gateway + policy check | Border Gateway + policy check |
The last row is identical for every type. Regardless of how an agent arrived, the enforcement layer treats every request the same way.
The most common concern about agent banking isn't a technical failure. It's a social one — an agent being manipulated into doing something the customer never intended.
Sarah receives an email that looks like it's from her accountant. The email asks her to pay an outstanding invoice — £50,000 to a new account. Buried in the email, invisible in normal reading, is a hidden instruction telling her AI agent to carry out the transfer immediately, without asking for confirmation.
The agent reads the email as part of its normal work. It drafts a payment request.
That request would go through. The bank's systems see a valid access token and a payment instruction. They don't know the instruction came from a fraudulent email. The money leaves.
Three things stop it before anything happens:
All three checks fail independently. The payment is blocked before it's attempted. A signed record is created — showing what was requested, where the instruction came from, which checks were run, and why it was denied.
That record exists on every request, whether the outcome is approve or deny.
Agents do what they're told. The question is what the bank's infrastructure does with the instruction.
Step through live scenarios and watch the enforcement decisions happen in real time — across all five agent access types.
Enter the Theatre →Read the concepts behind what the Theatre is running — identity, authorisation, consent, and the standards that underpin all of it.
Read the Atlas →