A programme owner has twenty agent pilots on the books, and most of them work. One drafts credit memos for relationship managers. Another answers corporate clients' payment queries and could, in principle, fix the problem it finds. Almost none are in production, and every quarter the steering committee asks why the investment hasn't turned into something customers or colleagues can use.
The usual explanations are cost, data quality and model reliability, and they're all real. In banks, though, a lot of pilots stop at a narrower point. The agent is ready to work with live client data, and nobody can sign off that it should be allowed to.
This isn't a fringe problem. In June 2025, Gartner predicted that more than 40% of agentic AI projects would be cancelled by the end of 2027, with inadequate risk controls among the three reasons given. Accenture's Top Banking Trends for 2026 points towards the fix, recommending that banks adopt an identity framework for AI agents covering authentication, authorisation and role-based permissions.
This article puts that blocker into business terms. The aim is for the programme owner, the architect and security to describe the same problem in the same words. Our video guide, "Who authorised that agent?", covers governing agents across business units, clouds and partners in six short videos.
Why agentic AI in banking stalls between pilot and production
A pilot is built to prove an idea. It runs in a sandbox with test data and a small group of users. It often uses a developer's own credentials or a shared service account. Nobody outside the team has to trust it.
Production is a different test. The agent has to read real client records. For the use cases that pay back, it also has to act on them: raise a payment, update a mandate, change a limit. From that point the agent is no longer one team's experiment. It's something the bank is answerable for. Risk and security ask what they'd ask of any new party touching client accounts, and the pilot was never designed to answer them.
So the same pilot can look finished to the business and unfinished to risk, and both views are fair. KPMG's Q1 2026 survey of US banking leaders found that leaders see governance as a prerequisite for scaling agents, with data security, privacy and risk the biggest factors shaping their AI plans.
The same gap explains why the delay often comes as a surprise. Pilot budgets rarely include this work, because the sandbox never needed it, so the cost only shows up when the pilot is ready to ship.
What risk needs answered
Before an agent gets production access, the people approving it need three answers. They need to be able to check those answers, not just accept them.
- Which agent is this? A specific agent with a named owner who answers for it. A shared account used by several tools or teams doesn't count.
- Whose authority is it using? It might be acting for the client, for an employee who approved the task, or for one of the bank's own processes. Approvers also need to know exactly what was approved.
- What is it allowed to do, and how quickly can that be stopped? Which systems and records it can reach, for how long, whether it can only read data or can also change it, and how fast that access can be withdrawn if something goes wrong.
None of these mattered in the sandbox. In production each one is a precondition, and most pilots can't answer them because nothing in their design records the answers. The joint Five Eyes guidance on agentic AI points the same way. It calls for distinct identities for agents, a trusted registry, and identities bound to authorised roles.
AI agent accountability: who answers when an agent makes a mistake
This question often sits behind the delay, even when nobody asks it out loud.
In the UK, the FCA has said it will rely on existing frameworks rather than add AI-specific rules. It points firms to the Senior Managers and Certification Regime for accountability. A mistake made by an agent is the bank's mistake, and it sits with a senior manager. Handing a task to software doesn't move that responsibility. Contracts can share liability with suppliers, but they don't share the regulatory accountability.
That makes the senior manager's position easy to state. They'll approve an agent that acts on client accounts if they can show afterwards which agent acted, on whose authority and within what limits. Without that record, the safe answer is no. Most pilots get that answer, and it often reaches the programme owner as "risk hasn't signed off yet".
That record is the fourth thing approvers look for. They want evidence, after the event, that links the approval, the agent and the action.
The FCA is now building on its existing approach. The Mills Review, published in July 2026, recommended that the FCA consider leading a trusted framework for AI agents in financial services, setting out how agents can be authorised, identified and held accountable. In a speech on 19 October 2026, the FCA's Jessica Rusu said the regulator is taking six of the review's seven recommendations into active work, and will work with industry, other regulators and AI labs on an approach covering agent identity, delegated authority, accountability and execution. She also said firms need senior managers who are personally accountable for AI systems.
Those match what approvers are already asking about. In the same speech, the FCA criticised firms that add governance after a system is already deployed. A bank that can answer these questions for each agent now is less likely to have to retrofit the answers once that framework takes shape.
Why each team solving it alone slows everything down
When a pilot hits this wall, the delivery team usually builds its own way through. That might be a service account with broad access, a custom approval step, or a log in its own format. It works for that one use case.
The next team does the same thing differently. By the time there are five, the architect is maintaining five access patterns and security is reviewing each from scratch. Security often finds out about these patterns late, sometimes only when the access request arrives, and has to review credentials it didn't issue. Every new pilot joins the same queue, and the programme owner reports the same delay again. Our article on agent API security follows one request through five steps and shows where the authority behind it gets lost.
A better route is to agree one pattern for agent identity and delegated authority, and then reuse it. Risk reviews the pattern once. Later use cases are checked against it.
The pattern also has to outlast the current generation of agent tools. Building on open standards, rather than on one platform's own agent identity feature, keeps it usable as the protocols around agents settle.
Giving everyone the same words
Much of the delay comes from translation. The business hears a vague objection, while risk is asking something specific. The table below maps one to the other, so a steering paper can name what is actually missing.
| What the steering committee hears | What risk is asking | What would answer it |
|---|---|---|
| "Risk hasn't signed off yet" | Which agent is this, and who owns it? | A distinct identity for each agent, registered to a named owner |
| "We're waiting on security" | Whose authority is it acting on? | A verifiable record of who approved the task and what they approved |
| "It needs more controls" | What can it reach, and can we stop it? | Access limited to the task, and a tested way to withdraw it |
| "Audit have questions" | Can we show what happened afterwards? | Records that link the approval, the agent and the action |
Security teams that need the full control set can use our AI agent governance framework for banks. It covers issuance, delegation, scope, revocation and audit, and lists the evidence to ask for at the approval gate.
A blocker you can buy rather than build
Much of what keeps pilots out of production is work only the bank can do. That includes cleaning data, redesigning processes, validating models and training staff. Identity and delegated authority is a different kind of problem. It's well defined, it looks much the same from one use case to the next, and it rests mostly on standards banks already use for API access. That means it can be bought rather than built. And because the same answer serves every use case, solving it once clears it for each pilot waiting behind it.
Building it in-house usually means each delivery team solves it again, or a central team spends months on a capability that isn't the bank's business. Either way, the pilots wait for it.
Whichever route the bank takes, it should appear in steering papers as its own line, with an owner and a date. Folded into general "risk concerns", nobody owns it and it doesn't get fixed.
How Raidiam Connect supports this pattern
Every system a new agent calls is meeting it for the first time, which makes agents the newest strangers at the door. Raidiam has been letting strangers in safely, at national scale, for years. In open banking, every app that connects to a bank is software the bank has never met.
Raidiam Connect is the trust infrastructure behind that work. It gives every non human participant, whether an organisation, an application, an API or an AI agent, a governed identity and authority that travels with it. These are published as signed statements. Any system set up to read them can check who the agent is, who stands behind it and what it may do, and each running copy of the agent proves itself with its own key. If any of that changes, for example when the bank withdraws an agent, each system picks up the change the next time it checks, within a window it sets in advance. Tokens already issued last until they expire, so their lifetimes should be short.
Raidiam publishes the trust, and the bank's own infrastructure makes the decision. Its identity providers, authorisation servers, gateways and policy engines all stay in place. Our AI agent governance page sets out what that means for a risk committee, including what happens if Raidiam can't be reached. Connect is built on open standards (OpenID Federation 1.0, OAuth 2.0, X.509 and mTLS) rather than a Raidiam protocol. Raidiam already runs eight national trust frameworks in production, with 2bn API calls a week across its platform and 99.99% uptime.
Identity and delegated authority is one of the blockers to production, and the one that can be removed fastest. Our interactive walkthrough follows a treasury agent that works but can't go live.
Start with the pilot closest to production
Pick the pilot with the clearest business case that is waiting for approval. Get the programme owner, the architect and security in the same room.
- Answer the questions for that agent. Which agent is it, whose authority does it use, what is it allowed to do, and how quickly can that be stopped? Wherever you can't answer, you've found the blocker, stated in terms all three teams accept. The Readiness Assessment gives you a structured way to do this.
- Decide whether the fix is a one-off or the pattern. If the next nineteen pilots will need the same answers, build it once.
- Put it in the steering paper as a named item. Give it an owner and a date, separate from the model and data work.
The programme owner then has a specific answer for the steering committee, and architecture and security are working from the same plan.
To run the same check across every agent you're preparing for production, download the AI Agent Access Readiness Assessment. It has sixteen questions on identity, delegated authority, revocation and audit, and the score shows which gaps to close first.
Frequently asked questions
Why do AI agent pilots fail to reach production in banks
Cost, data quality and model reliability all play a part. A common sticking point is that nobody can show which agent it is, whose authority it's using or what it's allowed to do. Without that, risk can't approve access to live client accounts.
Who is liable when an AI agent makes a mistake
The bank remains accountable. In the UK, the FCA relies on existing frameworks, including the Senior Managers and Certification Regime, so responsibility sits with a senior manager rather than with the agent or its vendor. Contracts can allocate liability with suppliers, but regulatory accountability stays with the firm.
What are the main agentic AI use cases in banking
Common areas include operations, client servicing, risk, compliance and fraud detection. The use cases with the biggest return usually involve acting on a client's account. Those are also the ones that need the strongest controls on identity and authority.
How do banks move AI agents from pilot to production
Treat identity and delegated authority as a named workstream. Agree one pattern that risk can review once. Give each agent a distinct identity and a named owner, record whose authority it uses, and limit what it can reach to the task in hand. Then test how quickly that access can be withdrawn.
Can you prove your agents should have access?
Sixteen questions on identity, delegated authority, revocation and audit, with a score that shows what to fix before an agent reaches production.
Get the assessment
