Executive briefing

A safe way for customers to use AI assistants with their bank

What goes wrong when an assistant borrows a customer's identity, and how the Federated Agent Connector answers each risk - with an identity of the assistant's own, permission the customer gives, trust the bank vouches for, and an off switch.

The situation

Customers have started asking AI assistants to deal with their banking - to check a bill, find a better deal, keep an eye on a balance. Today an assistant can only do that by pretending to be the customer: it holds their password, or a login that looks exactly like theirs. The bank cannot tell the two apart, cannot limit what the assistant does, and cannot switch it off without switching the customer off too.

That leaves a bank three options - block assistants, look away, or offer a way to use them that keeps the customer in control. We think the third is the only one that lasts, and this briefing is about how it can be done safely.

What "safe" has to mean

Five things go wrong when an assistant borrows a customer's identity:

• It is invisible. Nothing it does can be told apart from the customer's own actions, so nothing can be attributed to it, or disputed.
• It can do everything. Whatever the customer meant it to do, it holds the customer's full authority.
• Its credentials can be copied. They sit on a laptop or a server, and a copy works as well as the original.
• Nobody else can trust it. A partner of the bank has no way to tell an assistant the bank stands behind from one nobody does.
• There is no off switch. Withdrawing its access means changing the customer's password and hoping.

The approach, risk by risk

The Federated Agent Connector gives the assistant a strong cryptographic identity of its own, kept in the device's secure hardware and issued by the customer's bank, and ties everything it does to permission the customer gave. Each of the five problems has a specific answer, built from open standards the banking industry already relies on.

1. Its own identity, kept in hardware

The assistant's keys are created inside the customer's own device - the Secure Enclave of a Mac, or a hardware security key - where they cannot be copied out. Apple's App Attest lets the bank verify that the assistant's software is genuine and unmodified and that the device is in a secure state, both when it enrols and every time its credential is renewed. From then on every request the assistant makes names two parties: the customer, and the assistant acting for them. (Attestation-based client authentication; App Attest.)

2. The customer stays in charge

The customer links the assistant by signing in to the bank with a passkey. No password ever passes through the assistant, and passkeys cannot be phished. The customer then approves exactly what the assistant may see and for what purpose - their balances and transactions, to manage their accounts - and the bank checks each request against what this kind of assistant is for before the customer is even asked. A request outside those purposes, such as using the customer's data for marketing, is refused without troubling the customer at all. (FAPI 2.0; rich authorisation requests with stated purposes; a policy decision point.)

3. Trust that travels

The bank vouches for the assistant through OpenID Federation: signed statements that any participating organisation can verify back to a shared trust anchor, and a Trust Mark - a signed statement that the assistant meets the bank's requirements. A partner that has never met the assistant can decide, from the federation alone, whether to serve it, and the bank caps what an assistant may claim about itself whatever the assistant says. Trust does not have to be rebuilt partner by partner.

4. Credentials that are useless if stolen

Every token the assistant holds is bound to its hardware key, so a copy taken from anywhere else does not work. (DPoP, as FAPI 2.0 requires.)

5. An off switch that reaches everywhere

The bank can withdraw its Trust Mark, and partners stop serving the assistant. It can cancel the assistant's registration, and the bank stops too. The customer's own access is untouched either way, and the customer can ask for either from their banking app.

Because every credential carries who the customer is, which assistant acted, what it was allowed and why, every action can be reconstructed afterwards - the evidence a dispute needs, and the evidence a regulator will ask for.

What this gives a bank

• A way to say yes. Customers who want to use an assistant get one on the bank's terms, instead of being blocked or left to share passwords.
• Controls that work once for everyone. The same checks apply to every assistant and every partner, built on standards rather than one-off integrations.
• Evidence. An audit trail that names the assistant, its permissions and its purpose, not just the customer.
• A safe choice for customers. They see exactly what an assistant may do, approve it with a passkey, and can switch it off in a moment.

Where this stands

It works end to end in the demonstration on this site: a bank authorisation server (PingFederate with the federation modules), a trust anchor, a partner, and a connector for Claude that a customer links with a passkey. You can drive it yourself, watch the two-minute film, or connect your own assistant to it.

It is a demonstration, not a product. It uses sample accounts and cannot make payments. The version served to assistants over the web keeps the assistant's keys on the demonstration server, because a web service has no access to the customer's device; the version installed on a Mac keeps them in the Secure Enclave with Apple's attestation, which is the arrangement a bank would ship. How quickly withdrawal takes effect at scale is one of the things a pilot would measure.

Try the demonstration Watch the film (2 min) Use it with your own assistant