Safely means narrowly. A bank gives an agent one job, lists each action the job needs, proves each action on its own past cases, and lets the agent act only as far as that proof supports. Limits are checked when the agent acts, every decision is filed, and anything moving money or affecting a customer's rights waits for a person.
What does a safe first deployment look like?
Most safe deployments begin with work where the agent reads and drafts but does not act. Payment investigations, complaint summaries, KYC file preparation and internal policy questions all fit. The agent saves staff time, its output is visible, and a person still decides.
The pattern that causes trouble is the opposite: a broad "assistant" connected to many systems with a general instruction to be helpful. That agent has no clear scope, so nobody can say what it should refuse. The bank-wide view of where the line sits is in AI agents in banking: what they may and may not do.
How do banks decide how far an agent may act?
They set it per capability, not per agent. One agent can read account history freely, draft letters a person sends, update a contact preference on its own and still be barred from releasing a payment.
| Depth | What the agent may do | Typical bank example |
|---|---|---|
| 1, read | Look up and summarise | Pull a customer's last six months of card disputes |
| 2, draft | Prepare; a person sends | Draft a complaint response for a handler to approve |
| 3, execute within bounds | Routine, reversible actions | Re-send a statement, update a marketing preference |
| 4, money or hard to undo | Move money, close, freeze | Release a refund; held for a person above a limit |
| 5, coordinate agents | Direct other agents | Reserved for orchestrators |
Depth is earned. The bank sets a ceiling for each capability, evidence from testing sets the actual depth, and the lower of the two applies.
What stays with a person?
Some decisions stay with a named person at every depth, because they carry legal effect, cannot be undone, or rely on judgement the bank must be able to defend:
- declining credit or setting terms for an individual;
- filing a suspicious activity report or deciding not to;
- releasing payments above the bank's limit or to new payees;
- closing accounts on the bank's own initiative;
- handling customers in vulnerable circumstances once that is identified.
The agent can prepare every one of these. It cannot be the one who decides.
A worked example: SIM swap requests
Take a retail bank whose contact centre handles calls from customers saying they have a new phone. A SIM swap is a common step in account takeover, so this is a high-risk request that looks routine.
The agent reads the customer's profile, checks recent changes to contact details, devices and payees, and checks the phone number against the bank's own records. If nothing has changed and the request comes through an authenticated channel, it can update the device registration at depth 3. If the phone number on file changed in the last few days, or a new payee was added, the request is held and passed to the fraud team. The steps are covered in how to handle SIM swap requests safely with an AI agent.
The point is that the agent is not trusted to judge "is this a fraudster?". It is trusted to check named signals, and the hold happens whenever one fires.
What controls make it safe in practice?
Safe use depends on controls that sit outside the agent's instructions, where the agent cannot argue its way past them.
- Tool permissions per action. Each system the agent calls is a tool with a defined action and limit, as explained in what tool use is. No general database or console access.
- Source labels. Facts from the core ledger count for more than facts from an email. An outside claim cannot authorise money moving.
- No open code execution. Agents that can write and run code need a sandbox and no route to production systems; see whether an AI agent can run code safely.
- Testing on the bank's own cases, before go-live and on a cycle.
- An append-only record of every action and refusal, with its reason.
- A fast way down. A failed test or a process change drops the agent to read-only the same day.
Validation is its own discipline in a bank; how banks validate an AI agent covers what model risk teams look for.
How does regulation shape this?
Banks already work under rules on operational risk, outsourcing, data protection and model risk, and those apply to agents too. In the EU, the AI Act adds obligations for some uses, with creditworthiness assessment of individuals listed as high-risk; see the EU AI Act for banks deploying AI agents. Elsewhere, supervisors tend to apply existing rules on governance and accountability to agents rather than write new ones.
Questions people ask
Should a bank build its own agents or buy them?
Either can be safe. What matters is that the bank can see each capability, set its limits, test it on its own cases and read the record. A bought agent the bank cannot test on its own data is harder to defend.
Can customers talk directly to a bank's agent?
Yes, for information and simple service tasks, provided the customer is told they are dealing with an AI system and can reach a person. Advice and decisions with real consequences need more care.
How often should limits be reviewed?
On a fixed cycle, and whenever the process, the sources or the underlying model change. Limits that are never revisited drift away from the evidence that set them.