Lara Trust — Agent Identity Platform

Why agents and banks don't naturally fit together

Banks have spent decades building systems designed around one assumption: the person using the account is a human, present, making a conscious decision.

Login systems verify humans. Fraud detection looks for human behavioural patterns. Strong authentication (entering a passcode, approving a push notification) is designed for humans who can read, decide, and confirm.

AI agents break this assumption. An agent is a piece of software acting on someone's behalf. It moves fast, works at any hour, doesn't need to stop and read a warning, and has no intuition about whether something feels wrong. It does what it's been told.

This creates three problems banks haven't had to deal with before:

The agent can be manipulated.

A human might notice a suspicious email and pause. An agent just reads it and acts. Bad actors are already experimenting with hiding instructions inside documents, emails, and websites to make agents do things the customer never intended. This is called prompt injection — and it's a real and growing threat.

The agent can act at scale.

A human making ten payments in five minutes would trigger fraud alerts. An agent doing the same might look different depending on how the system is calibrated. Speed and volume aren't signals of intent for a machine the way they are for a person.

The agent has no legal identity of its own.

When something goes wrong, who is responsible? The customer? The AI company? The app developer? Right now, there are no clear answers — because there's no standard way for a bank to even know what kind of agent it's talking to, who built it, or whether it's behaving the way the customer intended.

Lara Trust addresses all three.

Five ways an agent can access a bank

Not all agents are the same. A customer's personal Claude assistant is different from a bank's own embedded AI, which is different from a third-party fintech app the customer connected. Each type carries different trust, different risks, and a different set of questions the bank needs to answer before acting.

The five types are:

Your AI assistant

A customer connects their own AI to the bank. They control what it can do. The bank verifies it and enforces the customer's chosen limits.

Bank-embedded AI

The bank's own AI, running inside its own app. Because the bank built it and operates it, it carries the highest level of trust. It still requires step-up confirmation for unusual actions.

Third-party app

An external company the customer has given access to. Similar to how Open Banking works today for reading data — but extending to actions. The customer consents once; the app acts within that consent.

Delegated access

A named individual or organisation the customer has given specific, limited access to — a financial adviser, accountant, or family member. Time-limited. Scoped. Tied to a verified identity.

Scheduled rules

A standing instruction the customer created. Runs automatically on schedule. No customer present at execution. Consent was given once, when the rule was set up.

Each of these is handled differently in terms of how the agent connects and what trust it's given. But all five go through the same enforcement checks on every request.

How authorisation works — the basics

When an agent wants to do something on a customer's behalf, it needs to prove two things: who it is, and what it's allowed to do.

Who it is is handled by an access token — a digital credential, like a signed letter. The token is issued by an identity system (in Lara Trust, this is Authentik — a standard OAuth server). It says: "This is agent X, acting on behalf of customer Y, and it was issued at time Z."

The token contains something called the act claim — a small piece of information that records the agent's own identity separately from the customer's. This matters because a human logging in directly is different from an agent acting on their behalf — and the bank needs to know which situation it's in.

What it's allowed to do is defined by something called a Record of Authority (ROA) — the agent's rulebook. It specifies, for this specific customer and this specific agent: which accounts it can see, which actions it can take, the maximum amounts it can move, which payees are on the approved list, and how long the permission lasts.

The ROA is stored and enforced by the bank — not the agent. The agent doesn't get to decide what it's allowed to do. It makes a request, and the enforcement layer checks the request against the ROA before anything happens.

Why this matters

If the ROA says an agent can move up to £500 and the agent tries to move £50,000, the request is stopped — regardless of what the agent says, regardless of what its token looks like, regardless of whether the instruction came from the customer or from somewhere else entirely.

The enforcement layer — what sits between the agent and the bank

In Lara Trust, there's a component called the Border Gateway. It sits between the agent and the bank's actual systems. The agent cannot reach the bank's API directly — every request goes through the Gateway first.

This is a deliberate design choice, and it matters for one specific reason: the agent itself can be compromised.

If enforcement lived inside the agent — if the agent was responsible for checking its own permissions — then a manipulated agent could bypass those checks. An agent told by a fraudulent email to wire money might also be told to ignore its own safety rules.

By making enforcement external — something the agent cannot control or override — the bank maintains a layer of protection that exists regardless of the agent's state.

The Gateway checks every incoming request against three things:

Is the agent authorised?

Does it have a valid token? Is it on the registered list for this customer?

Is the request within policy?

Does it match the ROA — the right account, the right payee, within the right limits?

Does this request need the customer to confirm it first?

Some actions — a large payment to a new recipient, for example — require a fresh confirmation from the customer before they proceed, even if the agent has general permission to make payments.

If any check fails, the request is blocked. The bank API never sees it.

Consent — what it actually means for agent access

When people talk about consent in banking, they usually mean a customer clicking "I agree" on a terms page. That's not what consent means here.

For agent access, consent is the mechanism by which a customer tells the bank what an agent is allowed to do — and under what conditions it needs to ask again.

There are two different consent patterns in Lara Trust:

Setup consent

the customer approves a set of permissions once, and the agent can act within those permissions without asking again. This is used for scheduled rules and for routine tasks within a pre-agreed scope. The customer approved the rules; the agent just follows them.

Per-action consent

some actions require the customer to approve them individually, even if the agent has general permission to act. This happens when: the amount is above a certain threshold; the payee is new or not on the approved list; the action is outside the normal pattern for this customer.

When per-action consent is needed, the customer receives a notification — on their phone, in the banking app — with the full context: what the agent is trying to do, how much, to whom, and why confirmation is being asked for. They approve or deny. The agent waits.

This design means the customer stays in control without having to approve every small transaction manually. Routine things happen automatically. Unusual things stop and ask.

Know Your Agent — verifying who the agent actually is

Banks spend enormous effort verifying the identity of their customers before they can open an account. This is called Know Your Customer, or KYC.

Agents need something equivalent — a way for the bank to know who built the agent, what it's supposed to do, whether its identity can be verified, and whether it's been used responsibly.

This is called Know Your Agent, or KYA.

In Lara Trust, when a customer connects an agent, the bank checks a publicly available record published by the agent's creator — similar to how a website publishes a security certificate. This record states who built the agent, what it's designed to do, and what level of trust it's been granted by the issuing organisation.

Based on this, the bank assigns the agent a trust tier:

Bank-operated

the bank's own AI. Highest trust, because the bank controls it completely.

Verified commercial

a well-known, commercially available AI (like Claude or ChatGPT) whose publisher has provided verifiable attestation. High trust, customer-controlled.

Third-party registered

a fintech or service provider that has registered with the bank and passed a vetting process. Moderate trust; requires explicit customer consent for each scope.

Delegated

access granted by a customer to a named party. Trust is inherited from that relationship.

Policy-bound

a scheduled rule. The agent executes autonomously, but only within a fixed, pre-approved policy. Lower runtime trust because no human is present.

The trust tier affects what the agent can do by default, what it needs step-up confirmation for, and how quickly the bank will revoke it if something looks wrong.

The audit trail — a permanent record of every decision

Every time an agent makes a request — whether the bank approves it or denies it — a record is created.

This record is called an Authorisation Execution Receipt, or AER. It's generated by the enforcement layer (the Border Gateway) — not by the agent itself. This means the agent cannot modify or delete it.

The receipt contains:

What was requested
Which agent made the request
Which customer it was acting for
What checks were run and what they found
The decision — approved or denied, and why
The timestamp
A cryptographic signature, so the receipt cannot be altered after the fact

Why this matters for banks

When a customer disputes a transaction — "I never authorised that" — the bank can show exactly what happened. Which agent made the request. What it claimed to be authorised to do. What the enforcement layer checked. What it decided, and when.

When a regulator asks for evidence of appropriate controls on AI decision-making, the AER log is that evidence — already structured, already signed, already complete.

The record exists regardless of outcome. Every allow. Every deny. Every step-up request. All of it.

What regulation is coming — and why it matters for agent access

AI agents in financial services aren't operating in a regulatory vacuum for much longer. Several frameworks are converging that will make the infrastructure Lara Trust demonstrates not just good practice but a legal requirement.

PSD2 and Strong Customer Authentication (SCA)

Europe's payment regulation already requires banks to verify customer intent for certain transactions — typically anything above €30, or payments to new recipients. When an agent initiates a payment, the question becomes: does the agent's pre-approval from the customer count as strong authentication? The answer, under current interpretations, is often no. Banks will need to document how agent-initiated payments satisfy SCA requirements — or build step-up flows that do.

The EU AI Act

The AI Act, which came into force in 2024, classifies certain AI uses in financial services as high-risk. High-risk AI systems must have human oversight, maintain audit logs, and demonstrate that their decisions can be explained. An agent making payment decisions on behalf of a customer is a strong candidate for this classification. The AER receipt trail in Lara Trust is exactly the kind of audit log the Act requires.

FCA guidance on AI in financial services

The UK's Financial Conduct Authority has been clear that AI systems in regulated activities must be explainable, auditable, and subject to appropriate controls. An agent that can move money without a clear record of why it was authorised to do so — and a clear way to stop it — would not meet this standard.

IMF: Know Your Agent

The International Monetary Fund published analysis in 2026 calling for KYA requirements in payment systems — specifically the ability to verify and register AI agents that initiate financial transactions. The KYA layer in Lara Trust is a direct implementation of what that looks like.

Banks that build agent infrastructure now — identity, authorisation, enforcement, audit — will be ahead of the regulatory curve. Banks that don't will be retrofitting controls onto systems that weren't designed for them, under time pressure, in response to incidents rather than in anticipation of them.

The standards underneath this

What you see in this demo rests on a stack of emerging specifications — some finalised, some in active draft, some competing. This is not a mature ecosystem. It is a construction site. That is the point.

The decisions being made in IETF working groups and vendor engineering blogs right now will define how agent identity works in banking for the next decade. Understanding which standards compose, which compete, and which solve different parts of the problem is what separates a PM who can lead this from one who can only follow it.

OAuth 2.0 Token Exchange (RFC 8693)

The base standard for delegated token exchange. Allows a client to exchange one token for another — used to derive an agent token from a user token. RFC 8693 defines the act (actor) claim in JWTs. Every agent token in Lara Trust carries an act claim documenting which agent is acting on which user's behalf. Where it breaks: RFC 8693 works for single-hop delegation. When an agent delegates to a sub-agent — and that sub-agent delegates further — the single act claim model doesn't scale.

Why it matters for banks: The foundational delegation primitive. Without it, there is no standard way to encode "agent acting for user" in a token.

Status: RFC (finalised, 2020). Widely deployed.

OAuth On-Behalf-Of for AI Agents

draft-oauth-ai-agents-on-behalf-of-user

Extends RFC 8693 specifically for AI agent scenarios. Introduces requested_actor (which agent is requesting access) and actor_token (the agent's verifiable identity credential) in the token request. The consent screen can now show: "Claude wants to pay £14.99 to Netflix on behalf of Sarah Chen" — not just "an app wants access."

Why it matters for banks: Without this, the consent screen has no way to surface the agent's identity to the customer. This draft is the foundation for KYA-grade consent UX. Auth0, Okta, and WorkOS have implementation previews aligned to it.

Status: Active IETF draft.

Agent Identity Protocol (AIP)

draft-prakash-aip

A verifiable identity credential for AI agents. Analogous to X.509 for machines. An agent publishes a signed identity document at a well-known endpoint (.well-known/aip/). The document includes: agent ID, operator identity, model version, capability manifest, and a cryptographic key. AIP-Delegated extends this for agent-to-agent delegation chains — when Agent A delegates to Agent B, Agent B's credential includes a verifiable reference to Agent A's grant.

Why it matters for banks: AIP is the "KYC for agents" standard. It's what makes Know Your Agent technically implementable rather than a policy aspiration. Lara Trust implements a simplified version of AIP-Core.

Status: Active IETF draft. No production deployments yet.

AgentROA (Route of Authority)

draft-nivalto-agentroa-route-authorization

A cryptographic policy enforcement framework for MCP. Defines the ROA (Record of Authority — what an agent is authorised to do), the AER (Authorisation Execution Receipt — a signed pre-execution commitment), and the ARA (per-hop attestation for multi-agent chains). The key architectural insight: enforcement should be external to the agent's execution context. An agent running in a compromised environment can be prompted to do anything. A Border Gateway enforcing the ROA externally cannot be overridden by a prompt.

Why it matters for banks: This is the principle behind Lara Trust's Border Gateway — and why the £50k prompt injection scenario works as a demo. Lara Trust is a full reference implementation.

Status: Active IETF draft.

A2A (Agent-to-Agent Protocol)

Published by Google DeepMind (2025). A protocol for agents to discover, communicate with, and delegate to other agents across organisational boundaries. A2A defines agent cards (published capability manifests), task negotiation (structured request/response between agents), and delegation tokens. Relationship to MCP: MCP is the protocol between an agent and a tool. A2A is the protocol between an agent and another agent. They compose: an orchestrating agent speaks A2A to coordinate sub-agents; each sub-agent speaks MCP to call tools.

Why it matters for banks: Multi-agent financial workflows require agents to delegate to specialist sub-agents across model boundaries. A2A is the emerging standard for how that delegation works.

Status: Open specification. Google, Salesforce, Atlassian are early adopters. No IETF standardisation yet.

Biscuit tokens

An alternative to JWTs for agent delegation chains. Uses a logic-based (Datalog) authorisation language embedded directly in the token. Key innovation: offline attenuation. With JWTs, delegating a narrower scope requires a roundtrip to the authorisation server. With Biscuit, the agent attenuates the token offline — it adds a new logic block that further restricts what the token allows. The sub-agent gets a token that is cryptographically bound to those constraints and cannot be modified to widen them.

Why it matters for banks: Elegant solution for multi-hop delegation without server roundtrips. Production use at Clever Cloud. Worth watching as a JWT successor for agent delegation specifically.

Status: Production use at Clever Cloud. IETF draft in progress. Not yet in mainstream banking toolchains.

GNAP (Grant Negotiation and Authorization Protocol)

RFC 9635 (finalised 2024)

The "OAuth successor" designed from scratch with delegation, non-browser clients, and structured access descriptions in mind. Rather than OAuth's implicit assumptions (a human in a browser approving a scope string), GNAP treats every grant as a structured negotiation: the client describes what it needs, the server decides what it will give, the human approves a specific grant — not a scope string. GNAP's structured access descriptions are a much better fit for agent consent than flat OAuth scope strings.

Why it matters for banks: The right answer in 3–5 years; not yet. Zero ecosystem. No major IdP ships GNAP in production. Lara Trust extends OAuth 2.0 pragmatically and is designed to migrate when the ecosystem catches up.

Status: RFC 9635 (finalised). Ecosystem adoption: minimal. Reference server implementations exist.

Standards map — how they compose

CONSENT LAYER         IDENTITY LAYER         ENFORCEMENT LAYER
─────────────         ──────────────         ─────────────────
OAuth OBO draft   →   AIP (agent ID)     →   AgentROA (ROA + AER)
RFC 8693 (act)    →   Biscuit (chains)   →   Border Gateway
GNAP (future)         A2A (multi-agent)      Audit trail

OAuth / GNAP handle the consent and token mechanics.
AIP / Biscuit handle the identity and delegation chain.
AgentROA handles enforcement and audit.
These three layers are independently specifiable — no single vendor owns this stack.

The honest assessment

Most of these standards are drafts. Several overlap. Some will be superseded. The ecosystem is moving fast enough that this page will need updating quarterly.

That is not a reason to wait. The banks that engage with these standards now — that have engineers on the mailing lists, PMs who can read a draft and know what it means for their architecture — will define what "agent-safe banking" means. The banks that wait for standards to stabilise will implement whatever the first-movers locked in.

Lara Trust is a bet that the architecture will still be coherent when the dust settles, because it is built around the right principles — external enforcement, verifiable agent identity, structured consent, forensic audit — not around any single draft that might be replaced.

The concepts behind the demo