Most AI governance programs at banks and insurers are written down. A policy defines acceptable use. A committee approves use cases. An inventory lists the models in production. All of that is necessary. None of it controls what an agent does at two in the morning.
Governance is decided in committee. It is enforced on the rails: the API gateway, the identity platform, and the logs that every system call passes through. If an agent's actions do not travel on those rails, the committee's decisions are advice.
What Changed in April
On April 17, 2026, the Federal Reserve, the OCC and the FDIC issued SR 26-2, which replaced SR 11-7 and SR 21-8. The new guidance is more risk-based and less prescriptive, and it expressly leaves generative and agentic AI out of scope. Banks govern those systems under their broader risk frameworks.
Some teams read that as breathing room. It is the opposite. Responsibility for outcomes stays with the bank, and there is no checklist to point to. The bank has to design its own controls for agents and then defend them. We covered the carve-out itself in SR 26-2 carved out agentic AI. The liability didn't move.
When a model risk committee, an internal auditor or an examiner looks at an AI agent, the questions come down to four:
Which agent took the action? This needs an identity registered for that agent, not a shared service account. On whose authority? When an agent acts for a person, the record has to carry both the agent and the person. That is a delegation record, issued at the moment of the call. What did it touch, and under which policy? This is a gateway access log tied to the policy decision that allowed the call. Can you stop it? This means a revocation path that works in seconds, tested before go-live.
Each answer is a system record. None of them is a document.
Why Documents and Prompts Cannot Answer Them
A policy document describes intent. A prompt instruction asks the model to behave. Neither one stops a call or records that it happened. We made the second point in Every prompt-based control is a future postmortem.
The fallback in many pilots is the developers' memory: ask the team what the agent can reach. That is not evidence. Neither is a log assembled after an incident. Reconstruction carries less weight than a record produced as the agent ran.
The Rails Already Exist
Banks and insurers have spent fifteen years building the controls agents need. API gateways enforce authentication, rate limits and access policy for every application and partner. Identity platforms issue scoped credentials and revoke them. Central logging keeps the trail. Auditors already know how to test all three.
Agents are a new class of caller. The work is to route them through the same layer:
Give every agent its own identity. It is registered, scoped to least privilege and revocable. We argued this in Agent identity is becoming an exam question for bank CIOs and CROs. Route model calls, MCP tool calls and agent-to-agent traffic through an AI gateway that applies policy and logs the decision. What is an AI gateway and when do you need one covers the basics. Treat MCP as a tool interface, not an authorization model. Authorization stays in the identity and gateway layer. See MCP is a context protocol. Most enterprises are letting it become an authorization model.
The patterns are common in pilots, and each one works in a demo:
A service account key in an environment variable, shared by every agent in the project. An MCP server that connects straight to a production database. A model API called from application code with no gateway in between.
Each produces a working agent and no evidence. None of them fails the pilot. All of them fail the audit.
The usual objection is that a gateway means sending prompts and data through a vendor's cloud. That is no longer true. AI gateways and the control planes that govern them can now run entirely inside your own infrastructure, including air-gapped environments. The rails can sit in the same perimeter as the models and the data.
A Test for Your Next Pilot
Before the next agent goes to production, pick one real transaction it performed in testing. Ask the team to answer the four questions from system records alone, without asking the developers.
If they can, the controls are load-bearing. If they cannot, the gap is not model risk. It is integration, and it is cheaper to close before go-live than after the first finding.
Before the next agent goes to production, pick one real transaction it performed in testing. Ask the team to answer the four questions from system records alone, without asking the developers.
If they can, the controls are load-bearing. If they cannot, the gap is not model risk. It is integration, and it is cheaper to close before go-live than after the first finding.
