Know Your Agent: How Can Banks Verify AI Agents Acting on Behalf of Customers?

A customer builds a personal finance app over a weekend. They connect an AI agent and ask it to monitor spending, compare credit cards, or help manage payments.

For the customer, it is a convenient new way to interact with financial services. For the bank, it raises a question: How do we know this agent is acting for our customer – and that the customer actually permitted what it is trying to do?

Customer-built agents introduce another participant into the relationship between a financial institution and its customer. Preparing for that relationship requires institutions to understand the agent, the person behind it, and the authority connecting them.

TL;DR

Know Your Agent (KYA) means establishing which agent is acting, whose behalf it acts on, and what it is permitted to do. Financial institutions should verify the customer when permission is granted, enforce that permission before actions execute, and monitor for changes in risk. Identity intelligence could help assess the person behind an agent, alongside the technical controls that establish and enforce authorization.

What is Know Your Agent in financial services?

Know Your Agent is an emerging way to describe the trust checks needed when software acts on a customer’s behalf. Here, we use it as a practical framework rather than a universal standard.

For financial institutions, it involves three distinct questions:

• Agent identity: Which software or service is making the request, and who operates it?
• Customer identity: Which person or business does the agent represent?
• Delegated authority: What has that customer permitted the agent to do?

A bank may recognize a legitimate agent provider without knowing whether the person connecting it is the genuine account holder. Equally, a verified customer may authorize balance checks without permitting payments.

The link between these layers matters. Institutions need evidence connecting a particular agent to a particular customer and a defined set of permissions.

Why should financial institutions prepare for customer-built agents?

As people experiment with personal apps and agents, financial institutions should anticipate interactions through software they did not build or select.

A budgeting agent might retrieve transactions. A shopping assistant might compare financing options. A small business owner might create an agent to prepare supplier payments.

Each journey carries different risks. Reading account information exposes sensitive data. Submitting an application creates commitments. Moving money requires clear authority over the amount and recipient.

Standards work is already addressing parts of this challenge. NIST’s AI Agent Standards Initiative includes agent authentication and identity infrastructure, while Visa’s Trusted Agent Protocol addresses trust between agents and merchants in commerce.

These developments make this a useful planning priority. They do not establish that customer-built agents are already a widespread banking fraud channel.

How is AI agent authentication different from authorization?

Authentication establishes which entity is presenting a credential. Authorization determines what that entity may do.

An authenticated agent could still request an action outside its customer’s permission. It could also operate with credentials obtained through a compromised account.

Consider a customer who asks an agent to “help me manage my bills.” That instruction leaves important questions unanswered. Can the agent read bills, prepare payments, or execute them? Which recipients are permitted? Is there a spending limit?

Financial institutions need permission expressed in terms their systems can enforce.

Existing standards offer building blocks. OAuth 2.0 Rich Authorization Requests supports detailed authorization data, including payment amounts and recipients, with consent enforced by the relevant servers.

For agent-mediated banking, the principle is straightforward: a conversational instruction must translate into explicit, bounded authority before it enables consequential actions.

Where should banks place verification controls in the customer journey?

Verification should begin when the customer grants access and continue when the agent attempts an action.

At delegation, the institution should authenticate the customer, identify the agent, and capture understandable permissions. Those permissions should specify the relevant accounts, data, actions, limits, and duration.

At execution, it should check whether the requested action falls within the current permission. A new recipient, higher amount, or request to change account details may warrant additional confirmation under the institution’s risk policy.

During ongoing use, it should check expiry and revocation, monitor activity, and reassess requests for broader permissions.

A budgeting agent with access to transactions should not automatically gain the ability to transfer funds. A separate action requires a separate authorization decision.

The customer should also have a clear way to review and withdraw access.

What could go wrong when an agent acts for a customer?

Institutions can prepare by testing plausible failure scenarios without assuming they are already occurring at scale.

An impersonator grants access. An attacker connects a legitimate agent after taking over a customer’s account. The agent’s authenticity does not resolve the customer identity problem.

An agent exceeds its permission. A tool authorized to prepare payments attempts to execute one, or changes the recipient after approval.

A credential is compromised. A request appears to come from a recognized agent, but an attacker controls its access token or signing credential.

Malicious content redirects behavior. An agent encounters instructions in a document or webpage that influence its next action. Institution-side controls should restrict what can execute regardless of the agent’s reasoning.

Several actions breach an overall limit. Individually permitted payments collectively exceed the customer’s intended spending cap.

These scenarios require coordinated identity, access, and transaction controls. Agent recognition alone cannot establish that every request is legitimate.

How can banks verify the customer behind an AI agent?

When software becomes the interface, the institution still needs confidence in the person or business behind it.

Delegated access should connect to a verified customer account. Institutions should assess signs of impersonation or compromise when access is granted and when subsequent activity introduces new risk.

For business accounts, another question arises: does the individual granting permission have authority to act for the business?

Identity intelligence could contribute additional context. Digital, social, and darknet signals can help assess identity consistency and exposure beyond the information supplied in an application or access request.

That context has limits. Online presence cannot establish consent, and breach exposure does not prove account compromise. Customers with limited digital footprints should not automatically be treated as suspicious.

Its potential value is in helping institutions decide when the identity behind an agent requires closer examination.

Where could Heka fit into Know Your Agent?

At Heka, we see an opportunity for identity intelligence to support this emerging layer of financial interaction.

A future capability could help institutions assess the identity behind an agent-mediated request and bring that context into decisions about access or further verification. For example, inconsistencies across identity signals could prompt closer review when a customer connects an agent or requests expanded permissions.

This would sit alongside the controls that authenticate agents, record customer consent, and enforce delegated authority.

The underlying question is familiar to Heka: How much confidence should an institution place in the identity presented to it? Agent-mediated journeys create a new setting in which that question needs answering.

What should financial institutions do first?

Start with a specific journey, such as account information access, and define the permissions it requires.

Map how the institution will identify the agent, verify the customer, capture consent, enforce limits, and revoke access. Test compromised accounts, changed recipients, expired permissions, and repeated requests.

Retain evidence connecting the customer, agent, authorization, and resulting action.

As customers delegate financial tasks to software, institutions will need to understand both the agent and the person behind it. For Heka, that presents an opportunity to bring identity intelligence into the next generation of customer verification.