“Who authorized this transaction?”
“The customer.”
“Which agent submitted it?”
“We do not record that separately.”
“Which tools was the agent allowed to use?”
“It used the customer’s session.”
“Can we revoke the agent without blocking the customer?”
Silence.
This is the architecture review many banks will eventually face.
Banks already know how to identify customers, employees, applications, and service accounts. AI agents introduce a less familiar actor: software that can interpret a goal, select tools, collect data, and initiate actions on someone else’s behalf.
Confirming the customer’s identity is no longer enough. The bank must also know which agent is acting, who owns it, what authority it received, and where that authority ends.
Know Your Agent Is a Chain of Trust
At the Global Fintech Fest 2026, State Bank of India Chairman CS Setty proposed a “Know Your Agent” framework covering agent identity, authentication, customer consent, transaction limits, audit trails, and revocation.
His warning was important. An autonomous error can travel through connected systems at machine speed. The same automation that reduces waiting time can also multiply the effect of a bad decision.
A banking agent should therefore never appear in a transaction as an invisible extension of the customer.
The trust chain should remain visible:
Customer → Consent → Agent → Policy Decision → Banking API
If one link is missing, the bank cannot confidently explain why an action happened.
Authentication proves which agent made the request. Authorization determines whether that particular agent may perform that particular action for that customer at that moment.
Banks need both.
Give the Agent a Passport, Not a Master Key
An agent identity should carry a small, verifiable description of its authority. Think of it as a temporary passport rather than a reusable API key.
Here is an illustrative manifest:
agent:
id: card-dispute-prod
owner: disputes-team
acting_for: customer-8421
permitted:
- transactions.read
- fee_reversal.draft
prohibited:
- money.transfer
- beneficiary.create
approval_required:
- fee_reversal.execute
expires_in: 5m
This information should not exist only inside the model’s prompt. Prompts can be altered, misunderstood, or exposed to injection attacks.
The passport must be issued, signed, and checked by infrastructure outside the model. Every banking API should evaluate it before accepting an action.
This also separates three identities that teams often combine:
- The customer requesting help
- The agent interpreting the request
- The service executing the action
That separation makes investigation and revocation possible.
The NIST National Cybersecurity Center of Excellence is exploring similar questions around agent identification, authentication, least privilege, delegated access, human approval, and verifiable audit records. Its 2026 concept paper also considers established technologies such as OAuth, OpenID Connect, SPIFFE, and SCIM.
Banks may not need a completely new identity system. They may need to adapt proven identity controls to a new class of non-human user.
Authority Should Shrink as Consequence Grows
Not every agent action carries equal risk.
A banking assistant might operate in four lanes:
- Explain: Describe a fee or summarize account activity.
- Prepare: Collect details and draft a dispute.
- Recommend: Suggest a decision to an employee.
- Execute: Change data, move money, or approve an outcome.
Moving from explanation to execution should not simply unlock more tools. It should narrow the acceptable conditions.
A balance explanation may require authenticated account access. Adding a beneficiary should require fresh customer confirmation. Reversing a fee may need an employee’s approval. Moving money should require stricter limits, stronger authentication, and an independent fraud check.
My view is that banks should automate evidence gathering before automating irreversible decisions. It produces meaningful efficiency while keeping responsibility with a person who is accountable for the outcome.
Financial-Crime Work Shows a Safer Starting Point
FIS offers a useful example. Its Financial Crimes AI Agent is designed to assemble evidence from banking systems, evaluate activity, and surface higher-risk cases.
The investigator still controls the decision.
That division of work matters. The agent handles the repetitive search across disconnected systems. A qualified human evaluates the evidence and accepts responsibility for the conclusion.
This is a more defensible starting point than allowing a general-purpose agent to perform every available banking action simply because the customer is authenticated.
Revocation Should Be Boring
If an agent behaves unexpectedly, stopping it should not require disabling the customer’s account or rotating a shared production credential.
Agent authority should be short-lived and revocable independently.
A bank should be able to answer:
- Which agent is active?
- Who or what delegated its authority?
- Which resources can it access?
- What actions has it attempted?
- When does its permission expire?
- Can the bank terminate it immediately?
These are ordinary identity-management questions. What changes is the speed and flexibility of the software being controlled.
The Next Banking User May Not Be Human
This shift also changes how conversational banking products should be built.
For an AI chatbot development company, improving response quality is no longer the complete assignment. Once a chatbot can call tools and modify business systems, its identity, permissions, approval boundaries, and audit trail become part of the product.
At Spaculus Software, that means treating an AI agent as a governed system actor, not merely a conversational interface.
Banks have spent decades learning who their customers are. The next challenge is knowing which software is standing beside those customers, what it has been asked to do, and whether it should be allowed to continue.
If an AI agent contacted your banking API today, could your system identify the agent separately from the customer?
Top comments (0)