Security Questions Were Built for People: Authenticating AI Agent Callers in Mortgage Servicing and Banking

The Question a Security Question Answers

A knowledge-based authentication question — the last four of the Social Security number, the amount of the last payment, the street the customer lived on in 2014 — answers one thing: does the caller know what the customer knows? For decades that has been a reasonable proxy for "is the caller the customer", because the only other people who knew those things were people who had stolen them, and contact centers layered fraud controls on top for exactly that case.

A personal agent breaks the proxy in a new way. It is not the customer, and it is not a thief. It is software the customer authorized, and it may well have read access to the customer's email, statements and documents. If the customer has connected it to their inbox, it may be able to answer many out-of-wallet questions faster than the customer can, and often more accurately. So the security question still returns "yes", but "yes" no longer tells the servicer or the bank whether it is talking to the customer, to software the customer authorized, or to software someone else pointed at the customer's data.

This is a contact-center problem before it is a protocol problem, and it lands first in mortgage servicing and retail banking, where the call volume is high and the calls are about money.

Three Callers Who All Pass

It helps to name the three callers a contact center now cannot tell apart with questions alone.

1. The customer. The case KBA was designed for.
2. The customer's agent, acting within what the customer asked for. It wants to set up a payment plan, request a payoff statement, ask why escrow went up, or dispute a card charge. It knows the answers because the customer gave it access.
3. An agent acting without the customer's authority. Either a legitimate agent that has drifted past its instructions, or an attacker's tool operating on data from a breach or a compromised inbox. It also knows the answers.

Today the second and third callers are handled the same way: either they pass and are treated as the customer, or the agent says it is software and is refused. Both outcomes are wrong for the second caller and the first one is dangerous for the third.

What Regulation E Settles, and What It Does Not

For electronic fund transfers from consumer accounts, the stakes of getting this wrong are set partly by Regulation E. An unauthorized electronic fund transfer is one "initiated by a person other than the consumer without actual authority to initiate the transfer and from which the consumer receives no benefit" (12 CFR 1005.2(m)). The same definition excludes a transfer initiated by a person to whom the consumer furnished the access device, unless the consumer has notified the institution that transfers by that person are no longer authorized.

Read against personal agents, that language raises questions it was not written to answer. Is giving an agent your banking credentials "furnishing the access device"? If the agent makes a transfer the customer did not ask for, is that a transfer by a person with actual authority, or one without it? We are not aware of regulatory guidance that resolves this, and we would not want a contact center's authentication design to depend on how it is eventually resolved. The practical lesson is that a bank or servicer that cannot show what a customer actually authorized an agent to do is in a weak position whichever way the question goes.

Mortgage servicing has its own version. A servicer handling a request from someone other than the borrower already has to decide whether that person is authorized to receive information about the loan, and privacy rules under the Gramm-Leach-Bliley Act sit behind that decision. An agent is a new kind of third party, and "it knew the escrow balance" is not a record of authorization.

Move the Proof of Authority Out of the Conversation

The fix is not a better question. It is to stop asking the conversation to prove authority, and to prove it somewhere else: at the institution's own sign-in, with a record of what the customer allowed.

The Personal Agent Protocol draft 0.3 lays out the pieces for this, and they are useful whether or not an institution adopts that particular protocol.

The agent identifies itself. Each agent has a client_id that is a URL where its metadata and signing keys are published. It presents signed session tokens with each request, and the guidance recommends that operators also sign requests using HTTP message signatures (RFC 9421). A contact center or gateway can then tell a named agent from an anonymous one, and allow or block agents by name.

The customer grants access at the institution, not to the agent. The protocol prefers direct sign-in at the business's own site, or a device flow where the customer approves on a second device (the pattern standardized in RFC 8628). Collecting the customer's credentials inside the agent is described as a transitional option to plan to remove. The consent page shows the agent's name and domain, the account, and each permission in plain language.

The agent asks for scopes, not for everything. Reading the loan's status, requesting a payoff statement and setting up a repayment plan are different permissions. A customer can grant the first without the third.

Consequential actions come back to the customer. The protocol's "operations" let a business ask the customer to approve an action — with a summary that stands alone, terms that match the request's own fields, and an expiry — and record that approval. A payment plan, a transfer or a dispute filed by an agent becomes something the customer approved on the institution's side.

When sign-in is needed mid-conversation, it is an event, not a code typed into chat. The guidance is explicit that a business should send an authorization event rather than asking for a verification code in a message, which keeps one-time codes out of the agent's conversation history.

What This Looks Like on the Phone

Most agent traffic to a servicer or a bank today will not arrive through a protocol. It will arrive as a voice call or a chat session from an agent that does not announce itself. A contact center can still apply the same principle in three steps.

Detect. Some agents say what they are. Others can be flagged from cadence, phrasing and the speed of their answers. We wrote about the related problem of synthetic voices in voice cloning and caller verification; detection there and here share methods, though the intent behind the caller is different.

Downgrade, do not refuse. A detected agent gets read-only answers that a signed-out caller could get anyway: general process, hours, what documents a hardship application needs. Anything about the account needs a stronger proof than a security question.

Step up outside the call. Send the customer a sign-in link or a push approval through a channel the institution already trusts, and continue the session with the agent only within what the customer approves there. The record shows which customer approved what, and when.

That last step is the one that changes outcomes. A servicer that negotiates a forbearance or a repayment plan with an agent and later learns the borrower did not want it has a dispute on its hands and, depending on the program, a loss mitigation problem. A servicer that has the borrower's own approval of the plan's terms does not.

The Same Design Serves the Customer

It is easy to read all of this as defensive. It is also the design that lets a contact center say yes more often. A customer who has connected an agent with a clear set of permissions can have that agent handle the routine: payoff requests, escrow questions, payment date changes, document uploads. The contact center stops spending human time on calls whose only purpose is to relay information the customer already authorized the agent to have. Its people spend more of their time on the calls where judgment is the point.

For lenders thinking about the origination side of the same shift, the personal agent readiness guide covers how a borrower's agent finds a lender, how its identity is checked, and how every session ends up in a record an examiner can read.