AI agent governance framework for banks approving agent access

Picture a security lead who has just been told that an agent workflow goes live in six weeks. The business has approved the use case and the build has started, but there is no control set for agent access yet. It will be written in a hurry, and whatever gets approved first is likely to become the pattern every other team copies.

Approving it comes down to three questions. How does each agent get an identity? Whose authority is it acting on? And what can it reach?

Banks already know how to govern service accounts, batch jobs and system integrations. Agents are different in two ways. First, they make choices: which tool to call, or which task to hand to another agent, sometimes based on something they read a moment earlier. Second, a single task can pass through several teams or even several organisations, and the authority given at the start still has to mean something at the end.

There is no industry-wide control catalogue for agent access in banking yet. The NIST NCCoE concept paper is a helpful reference, but it is a draft for comment rather than a finished control set. In the UK, the FCA's position is that existing frameworks and governance expectations already apply to AI. In the UAE, the Central Bank has published guidance on the responsible adoption of AI and machine learning by licensed financial institutions.

This article offers a starting point: five control domains, covering issuance, delegated authority, scope, revocation and audit. For each one, it describes what good looks like and what evidence to ask for before you approve. It sits alongside your model risk, operational resilience and third-party controls rather than replacing them.

What an AI agent governance framework covers

An AI agent governance framework sets out how agents get an identity, how the authority they act under is represented, what they are allowed to reach, how that access is taken away and how what happened is recorded.

The point is practical. Most existing controls assume a system makes a fixed, pre-approved set of calls. An agent that picks its own tools or delegates work does not fit that assumption. A shared framework gives security and architecture the same questions to ask before a use case reaches production.

Five control domains for agent access

1. Issuance

Issuance is about how an agent gets its credentials, and who answers for it.

Give every agent its own identity. If several agents share a service account, or an agent runs under an employee's login, you cannot tell afterwards which one did what. When you issue the credential, record an accountable owner: a named person and the team that runs the agent. Handing work to software does not move accountability away from the senior manager responsible for that business area, so the owner has to be real rather than a placeholder.

Make the credential prove who is using it. A shared secret or a plain bearer token works for anyone who gets hold of it. A sender-constrained token does not. With DPoP, the token is bound to a private key the agent holds, and the agent signs each request with that key, so a stolen token is no use on its own. Keep lifetimes short and automate renewal, so nobody is tempted to issue a long-lived credential just to avoid an expiry.

Keep a register of approved agents: what each one is for, who owns it, which environment it runs in, which tools it can use, which data it can touch and when it is next due for review. Decide up front what happens when an agent that is not in the register asks for access. The default should be no.

• Ask for: the register, one live credential with its expiry date, and what happened when an unregistered agent tried to connect.

2. Delegated authority

Delegated authority is about whose authority the agent is using, and how the systems it calls can tell.

Start by naming which case you are in. An agent might act on its own behalf, running a scheduled job. It might act for a named person who approved the work. Or another agent might call it as part of a larger task. Each case carries different accountability, so they should not share one credential pattern.

When a person approves the work, record exactly what they approved: the request, the client or data it covers, the time period and when they approved it. Signing in proves who the employee is. It does not approve everything an agent might go on to do.

Then decide how that approval travels from system to system. OAuth 2.0 Token Exchange lets a service swap the token it holds for a new one aimed at the next resource. The new token can name both the person the work is for and the agent doing it. It can also list earlier agents in the chain, but that list is for information only. It does not prove that permissions were narrowed at each step, and it cannot rebuild the original approval.

Keep entitlement checks separate. An agent working for an employee should not see data that the employee is not allowed to see. That check usually belongs in the system that holds the data, not in the token.

• Ask for: one completed task, the record of who approved it, and how each system along the way could tell whose authority was being used.

3. Scope

Scope is about how far the access reaches, and how closely it matches the task in hand.

Issue each token for one specific resource. OAuth resource indicators are the standard way to name the target, so a token issued for one service cannot simply be replayed against another. The Model Context Protocol authorisation rules say the same: a server must check that an incoming token was issued for it, and must not forward that token to a downstream API.

Set scope by policy when the token is issued, rather than granting whatever the calling service asks for. Swapping one token for another does not narrow the permissions unless the issuing policy narrows them. Treat reading data differently from moving money or changing records, and require a separate decision for the second.

Tight scope also limits the damage from prompt injection. An agent tricked by malicious content still acts within the permissions it already holds, so the size of those permissions decides the size of the outcome. Tool allow-lists, per-task limits and short-lived tokens all reduce it.

• Ask for: what the agent can reach when no task is running, and which tools it can call without a person approving first.

4. Revocation

Revocation is about taking access away, and how quickly that actually takes effect.

There are two different things to stop. You revoke a credential when a key is compromised or a certificate expires. You withdraw authority when a mandate ends, an employee leaves or a client relationship changes. A framework that only handles the first can leave perfectly valid credentials carrying authority that nobody intends them to have.

Revocation has to take effect at the resource, not just in the directory. Short token lifetimes, status checks and token introspection all narrow the gap between the decision and its effect. If one agent has handed work to others, decide whether stopping the first also stops the work it passed on, and write that decision down.

Then measure it. The number that matters is the time between deciding to stop an agent and its next request failing. Test that number rather than assuming it.

• Ask for: the tested time to effective revocation, and what happens to connected agents and tasks already in progress.

5. Audit

Audit is about what you can piece together afterwards, and how far you can rely on it.

The approval record, the delegation record and the application logs usually live in different systems. Agree a shared reference that links them before the workflow goes live. Adding one later means reprocessing logs in the middle of an incident.

A correlation ID helps you join those records, but it does not prove that a delegation was legitimate. Holding a token is not the same as being the right caller, either: a plain bearer token only shows that the caller had it. Sender-constrained tokens such as DPoP add proof that the caller holds the matching private key. Evidence about the workload itself, meaning the software actually making the request, goes a step further.

Keep records for as long as a supervisor is likely to ask about them. The real test is whether you can rebuild one completed task from the records alone, showing who authorised it, which agents carried it out and whether access stayed within scope.

• Ask for: one task reconstructed end to end from the records, without asking the delivery team.

What to ask for at the approval gate

Written as artefacts a second-line reviewer can request, the five domains become much easier to review.

How this maps to published guidance

Several published documents already set expectations that agent deployments inherit, and citing them makes an internal framework easier to defend in a review. Treat the first four as expectations that already apply, and the NIST paper as a sign of where things are heading. Build your framework so that later guidance can be mapped onto it without starting again.

How a cross-domain trust layer supports this pattern

Several of these domains depend on one thing: a system being able to trust an agent whose credential it did not issue. Raidiam Connect provides the infrastructure to publish and resolve verifiable identity, authority, credential and lifecycle information across domains. It can also bind an agent's governed identity to evidence about the specific instance that is running.

It is built on OAuth, OpenID Federation, public key infrastructure and verifiable credentials, and it sits alongside the identity providers, authorisation servers, gateways and policy engines a bank already runs. Those systems use the trust information when they make and enforce access decisions.

It draws on Raidiam's decade of operating trust infrastructure in regulated financial services. For banks building agent workflows, the aim is one consistent trust pattern that architecture and IAM can evaluate and delivery teams can reuse. Identity and delegated authority are one part of the work needed to get a use case into production.

Use the framework in your next approval

Pick the use case currently waiting for a decision, and work through it with architecture, the delivery team and the programme owner.

1. Fill in the five domains. Answer the five questions from the approval table for that agent. The gaps are the controls you are missing, already in a form a reviewer can act on.
2. Agree what has to be in place before go-live. Issuance, scope and revocation usually come first. Parts of audit can follow later, as long as the shared reference is agreed up front.
3. Test it. Run a task that goes beyond its mandate, let a credential expire mid-task, and withdraw authority from an agent that has already handed work on. Record what happened.

The approver then has a documented basis for the decision, and the next team has a pattern to reuse. The programme owner also knows exactly what has to be resolved for this use case to go ahead.

Explore agent identity and delegated authority across systems.

Frequently asked questions

What is an AI agent governance framework

It is a set of controls for how an organisation gives AI agents an identity, represents the authority they act under, limits what they can access, takes that access away and records what happened. It works alongside model risk, operational resilience and third-party frameworks rather than replacing them.

Do banks need a separate framework for AI agents

Not entirely. Most of the controls already exist for service accounts and other non-human identities. What changes is that an agent picks its own tools, can hand work to other agents and may cross several teams or organisations in one task. The framework records how your existing controls apply under those conditions, so each team does not answer the question differently.

Which regulations apply to AI agents in financial services

In the UK, the FCA says existing frameworks and governance expectations apply, rather than a separate AI rulebook. In the UAE, the CBUAE guidance note sets expectations for governance, human oversight, record keeping and third-party controls. A bank still needs to map those expectations to its own risk, outsourcing, consumer protection and accountability obligations.

How do you audit an AI agent

Link the approval record, the delegation record and the application logs through a shared reference agreed before go-live. A useful test is whether you can rebuild one completed task from the records alone, showing who authorised it, which agents carried it out and whether access stayed within scope.

Does an agent governance framework prevent prompt injection

No. An agent can follow malicious instructions while holding perfectly valid permissions. The framework limits how much those permissions allow, and helps you investigate afterwards. You still need tool restrictions, careful input handling and human oversight.