Banks govern AI agents with a control layer that sets, for each agent, what it may do on its own, what it may spend, what it may see, and who approves the rest. The working parts are autonomy levels, limits and budgets, named approvers, guardrails, a kill switch and a complete record of every action. For customer-facing agents, the customer also chooses how much freedom the agent has, inside a ceiling the bank sets.
Why “human in the loop” is not enough
Many AI vendors describe governance as a human in the loop, an audit trail and some policy checks. Those are necessary. They are also too coarse for a bank running dozens of agents. A disputes agent and a research agent should not carry the same freedom. An agent that drafts a credit memo should not be able to send it to the customer. And a risk team needs to change one agent’s permissions without touching the others.
The answer is to treat each agent like a new member of staff: a role, a level of authority, a spending limit, the systems it may use, and a manager who signs off above its authority.
1. Autonomy levels
An autonomy level says which actions an agent may take on its own. In Tuvel Control Plane, staff agents hold one of five levels:
- L1, Observe. Reads and reports. Anything it would write, even a draft, waits for a person.
- L2, Assist. Reads and drafts on its own. Changes to records other people rely on wait.
- L3, Operate. Changes workspace records on its own. Anything that reaches outside the workspace waits.
- L4, Represent. Acts outside the workspace, such as emailing a contact. Publishing waits.
- L5, Lead. Publishes and hands work to agents below it. Deleting and governance changes always wait.
Bank agents start at L1 or L2. A person approves each step up. Each action an agent may take is also tagged: the agent does it, proposes it, or leaves it to a person. The level decides which tags apply.
2. Two keys for customer-facing agents
A money advisor that serves customers needs one more control. In Tuvel Advisor, the customer holds one key: a level from 1 to 5 that says how much the advisor may do for them. The bank holds the other: the highest level each customer segment may use, and caps per payment and per day. The lower of the two applies. Until the bank saves its rules, every action waits for the customer’s tap. We explain this in two keys.
3. Limits and budgets
Every agent has daily and monthly budgets for what it spends on model calls and tools. Going over budget stops the agent. Customer money actions carry their own caps per payment and per day, on top of the customer’s level. Budgets make cost predictable. They also act as a circuit breaker: an agent stuck in a loop runs out of budget before it runs up a bill.
4. Approvals on cards, by named people
Anything above an agent’s level waits on an approval card for a named person, in the room where the work is. The rules that make approvals safe are simple:
- Only the button approves. Typing “approve” in a chat does nothing.
- Requests expire. A high-risk request expires after 24 hours, the rest after 7 days, so nothing old fires by surprise.
- Reasons go on the record. The reason for each decision is written down, and agents read it next time.
For customers, the equivalent is the confirmation tap: one tap confirms one exact amount to one exact payee, and a spoken or typed yes never moves money. See why a spoken yes never moves money.
5. Guardrails and what each agent may see
Guardrails cover what always needs a person, what each agent may see, and baseline rules every agent follows: decision boundaries, untrusted content, confidentiality, citations, escalation and logging. Each agent sees only the customer details and tools it was granted. Personal identifiers are masked before text reaches a model, and PINs and one-time codes stay out of models altogether.
6. A kill switch
Any agent can be paused in one click. This matters more than it sounds. A risk team that knows it can stop an agent at once is far more willing to let it start.
7. Model routing per agent
Each agent runs on the model set for it, through one routing layer that falls back when a provider key runs out and prices every call against the agent’s budget. Changing an agent’s model changes cost and speed, never its permissions. That separation keeps model choices out of the control conversation.
8. The record
Every turn, tool call, hand-off and decision is recorded, with who asked, what ran and why. A reviewer can see why an action ran, waited or was refused. This is the evidence model risk, internal audit and compliance teams ask for. Calls to bank systems are kept in a tamper-evident, hash-chained trail, with a signed export the bank’s SIEM can ingest and verify on its own.
9. Changing the rules safely
Rules change over time, so changing them needs its own controls. In Tuvel’s console, loosening a rule, such as raising a ceiling or a limit, waits for a one-time code sent to the admin. Tightening takes effect at once. Every change is versioned and can be rolled back, and changes to connections can require a second person to approve them (maker-checker). New agents move from sandbox to staging to live, with automated checks before each step, and only a bank admin puts one live.
A checklist for your risk team
Put these questions to any agentic AI vendor, and ask to see each answer working in a demo:
- Can each agent hold its own level, and who approves a step up?
- Does each agent have a budget, and what happens when it runs out?
- Who approves above an agent’s level, and can typing in a chat ever count as approval?
- Can you pause one agent at once, without stopping the others?
- What does each agent see, and how is access granted and revoked?
- For customer actions, who sets the limits: the customer, the bank, or both?
- Can you replay why a given action ran?
- How are rule changes approved, versioned and rolled back?
For how this maps to India’s published rules, see agentic AI in Indian banking and our responsible AI page.