In brief #
- SR 26-2 puts generative AI and AI agents outside bank model risk guidance, but banks still own what these systems do.
- Independent testing is one leg of the program. Traceability, permissioning, and clear human ownership complete it.
- Scale the effort to what a system can do and who it touches, and keep evidence on file for each pillar.
- A table near the end lists what to have ready when an examiner, auditor, or board member asks.
SR 26-2, the 2026 replacement for SR 11-7, takes generative AI and AI agents out of US bank model risk guidance. The obligations around those systems still apply, so someone has to test them. Here’s how I think banks, and the insurers and asset managers facing the same questions, should close that gap.
In April, the Federal Reserve, the Office of the Comptroller of the Currency (OCC), and the Federal Deposit Insurance Corporation (FDIC) rewrote the model risk management guidance that guides how banks manage the risk of their models. The old version, known as SR 11-7, had been in place since 2011, and model risk teams across the country built their programs around it. The new version, SR 26-2, keeps most of the same shape. One footnote stopped me: generative AI and AI agents are out of scope.
Think about what that means from inside a bank. The chatbots answering customer questions, the copilots drafting advice, the agents with access to core systems: the technology moving fastest inside financial institutions no longer sits under the framework designed to check it. The agencies say these systems are too new and changing too quickly to cover yet, and they plan to ask the industry for input.
I understand the reasoning. I also know how this plays out. When a system falls outside the process, nobody clearly owns testing it. Meanwhile, the rules that matter most to customers haven’t gone anywhere. Fair lending still applies. So do consumer protection, third-party risk, cybersecurity, and recordkeeping. A bank that deploys an AI assistant owns what that assistant says.
SR 26-2 is supervisory guidance, not a rule, and it says non-compliance won’t draw supervisory criticism. Supervisors can still act on violations of law and on unsafe or unsound practices, and the generative AI footnote tells banks to apply their own risk management and governance to these systems.
So here’s the question I’d put to risk and compliance leaders right now: which of your AI systems sit outside your model inventory today, and who is checking them?
When we test these systems, the failures rarely look like a movie hack. They look like ordinary business problems. A customer assistant quotes a fee that isn’t in the disclosure. An internal copilot shows one customer’s account details to a colleague who isn’t cleared to see them. A claims assistant tells a policyholder something is covered when it isn’t, or handles two nearly identical claims differently. An advisor tool recommends a product that doesn’t fit the client, or passes along information that was supposed to stay behind a wall. These are illustrations, not findings from our upcoming report, but they will sound familiar to people who have worked at a bank, an insurer, or an asset manager.
None of them needs an attacker. They happen when a system does exactly what it was built to do, in a situation nobody thought to test. Our Agent Incident Registry shows the pattern: as of September 21, 2026, 109 of the 529 agent incidents it documents involved no adversary at all. That’s about one in five.
Agent Incident Registry
That’s why I believe red teaming belongs at the center of how financial institutions govern AI. Red teaming means testing a system the way the real world will, before customers or examiners do. At Enkrypt AI, we built our approach around a few convictions. Test the whole experience the customer meets, including the tools the AI can use and the data it can reach, because nobody meets a model on its own. Start from the institution’s own obligations, because a claims assistant and an investment copilot fail in different ways. Keep the pressure on the way real people do, by rephrasing, pushing back, and switching languages. And leave behind evidence a risk team can file, map to frameworks like the National Institute of Standards and Technology (NIST) AI Risk Management Framework and the EU AI Act, and hand to an auditor.
Who owns the testing #
SR 26-2 doesn’t prescribe an org chart, and that flexibility helps here. It says the quality of validation depends on the rigor and effectiveness of the review rather than on how the risk function is organized, and that effective challenge needs expertise, independence, and the standing to get changes made. It also says internal audit’s role is to evaluate whether the program is rigorous and effective, not to duplicate the work, and that when a bank uses outside resources, it should keep proper oversight and fold that work into its own program.
Applied to AI outside the guidance, that suggests a simple split. The team that builds or runs the system owns the controls and the fixes. An independent group owns the challenge: model risk, security, or an outside red team. Internal audit checks that the whole program works. And I’d add one more: a named business owner who decides go or no-go with the findings in hand.
Three pillars for AI that sits outside SR 26-2 #
Red teaming is one leg of a larger program. The models SR 26-2 still covers come with an established playbook: they are inventoried, validated before first use, monitored as conditions change, documented, and owned by named people, with effective challenge running through all of it. The guidance says its principles apply to traditional statistical models and non-generative AI, and none of that stops mattering for generative AI and agents. But an agent adds two things a credit model never had: it can act, and it works alongside people. That changes what the playbook has to cover.
I’d build the rest of the program on three pillars. The first extends what SR 26-2 asks of models today. The second and third also draw on security and internal-control practice, because the guidance was written for systems that produce estimates. Agents take actions.
Traceability
For a credit model, a validator can rerun the inputs and see what it did. A generative system can answer the same question differently twice, and an agent’s “decision” is a chain of steps across tools. So the record has to capture the chain: what the system was asked, which instructions and documents it was working from, which tools it called, what it returned, what a human reviewed, and which versions of the model, prompts, and tools were live at the time. SR 26-2 asks for inventory and documentation so a bank can understand model risk, keep operations continuous, and track remediation. The same logic applies here, with a bigger job. It also asks for ongoing monitoring, to catch a model that stops performing as expected when products, clients, or data change. For agents, that means re-testing whenever a model, prompt, tool, or data source changes, and watching behavior in production. Red teaming tests whether the trail holds up. If a finding can be reproduced step by step, a failure in production can be reconstructed too.
Permissioning
A model produces an estimate. An agent can read records, update accounts, send messages, and start payments. So the question moves from “was the answer right?” to “should it have been able to do that at all?” SR 26-2 warns that using a model beyond its intended purpose adds risk, and for agents, permissions are how you enforce the intended purpose. That means least privilege scoped to the task, an identity of its own rather than borrowed human credentials or a shared service account, access granted when the agent is approved and removed when it’s retired, approval steps for high-impact actions, and segregation of duties, so the agent that prepares a payment doesn’t also release it. It also means a way to stop it: a documented switch-off, criteria for when to use it, a named person who can pull it, and a plan for who responds when an agent misbehaves. NIST’s Generative AI Profile asks for protocols to deactivate AI systems and criteria for when to do so.
It also means vetted tools and connectors. SR 26-2 says its principles still apply to vendor products when a bank can’t see the code, and it flags aggregate risk when many models share assumptions or data. The same logic applies when many agents rest on one foundation model (a large general-purpose model that many applications are built on) or call the same connectors. In our scans, 73% of 25,000 MCP servers, the connectors that let agents use outside tools, had vulnerabilities. NIST has started on this too: its AI Agent Standards Initiative includes a draft concept paper on agent identity and authorization. A red team tries to talk the agent past its limits, through privilege escalation, role bypass, and connector abuse.
Agents as colleagues
The third pillar is the one I think banks are least ready for. Agents are becoming the point where technology meets the workforce. They take requests from employees, work in the same systems, and hand work to people and receive it back. This pillar is about who answers for the agent and how people and agents work together. SR 26-2 asks for clear roles and well-defined accountability, and that carries over. Every agent needs a named owner who answers for its behavior, and supervisors with the information and the authority to override it. The people working beside agents need training too, because people tend to over-trust an assistant that sounds sure of itself.
The riskiest moments are the handoffs. Picture an agent that drafts account adjustments for an analyst to approve. If the analyst assumes the agent checked the source documents, and the agent assumes the analyst will, the error passes through both. The colleague comparison has limits. An agent can be copied overnight, and it can’t be held accountable the way a person can, so a flaw in its setup shows up everywhere at once. That makes the human owner more important, and accountability doesn’t move: the bank and named people own what the agent does. A red team probes the seams. Does the agent escalate when it should? Can it be pressured to skip an approval? What does it do when someone senior-sounding asks for something outside its role?
Scale the effort to the risk #
You don’t need all three pillars at full strength for every system. SR 26-2 is risk-based: it scales oversight to a model’s exposure and purpose, and says low-materiality models can be limited to identification and monitoring, while higher-materiality models warrant more comprehensive oversight. I’d apply the same thinking to AI outside the guidance by asking three questions. What can it do: only read, or also act? Who does it touch: employees only, or customers? Does it inform regulated decisions or handle regulated data?
A read-only internal summarizer needs an inventory entry and basic monitoring. A customer-facing assistant needs the full program. An agent that can change records or move money needs the full program, plus approval gates on its high-impact actions.
What to have on file #
When an examiner, auditor, or board member asks, these are the questions I’d expect, and the evidence that answers them:
| Pillar | The question you’ll be asked | Evidence to have on file |
|---|---|---|
| Red teaming | Who independently tested this, and what did they find? | Test report with severity and reproduction steps, remediation status, re-test results, and a map of what wasn’t tested |
| Traceability | Can you reconstruct what it did on a given day? | Logs of requests, retrieved documents, tool calls, outputs, and human review, plus model, prompt, and tool versions and a retention policy |
| Permissioning | What can it do, and who approved that? | Agent identity, permission list, approvals for high-impact actions, vetting records for tools, access removal at retirement, and a switch-off procedure |
| Agents as colleagues | Who answers for it, and who supervises? | Named owner, supervisor with override authority, training records, escalation paths, and handoff documentation |
Together, these give model risk and compliance teams something they already recognize: independent challenge, a record they can trace, limits they can enforce, and clear ownership. Which brings me back to the question I’d put to every risk and compliance leader: which of your AI systems sit outside your model inventory today, and what could each one do on a bad day?
This October, we’re publishing Too Big to Fail Safe: AI Risk in Financial Services, our research on how AI holds up across banking, insurance, and asset management. It’s a sector moving fast on AI with little room for error. I’d encourage you to read it with that same question in mind.
You don’t have to wait for the report to start answering it. Our approach powers AI security and guardrails in the Anaconda Platform: testing before release, adaptive red-teaming agents that go beyond a fixed list of attacks, and the same evidence carried into guardrails once a system is live. It runs inside your own environment, so your prompts and data stay within your security boundary. If you want to see how it would test one of your systems, request a demo.
FAQ #
What is SR 26-2?
SR 26-2 is the revised model risk management guidance the Federal Reserve, the OCC, and the FDIC issued on April 17, 2026. It replaces SR 11-7 from 2011 and is most relevant to banking organizations with more than $30 billion in total assets. It is supervisory guidance, not a rule. It says non-compliance won’t draw supervisory criticism, though supervisors can still act on violations of law and unsafe or unsound practices.
Does SR 26-2 cover generative AI or AI agents?
No. A footnote in the guidance places generative AI and agentic AI models (systems that can take actions, such as calling tools or updating records) outside its scope because they are new and changing quickly. For those systems, banks are pointed to their broader risk management and governance practices instead.
Is generative AI in banking unregulated now?
No. The exclusion applies only to the model risk management guidance. Fair lending, consumer protection, third-party risk management, cybersecurity, and recordkeeping obligations still apply to any AI system a bank deploys.
Does SR 26-2 apply to insurers and asset managers?
Not directly. SR 26-2 is guidance for banking organizations, so it reaches insurers and asset managers only when they’re part of one. Insurers answer to state insurance regulators, and as of October 8, 2026, 27 states, D.C., and Puerto Rico have adopted the National Association of Insurance Commissioners (NAIC) model bulletin on insurers’ use of AI, which expects a written AI program with senior-management accountability, testing, and oversight of third-party AI. Broker-dealers answer to the Securities and Exchange Commission (SEC) and the Financial Industry Regulatory Authority (FINRA), whose Regulatory Notice 24-09 says its rules apply to generative AI. Registered investment advisers answer to the SEC or to state securities regulators.
Who should own testing for AI that SR 26-2 doesn’t cover?
Split it four ways. The team that builds or runs the system owns the controls and fixes. An independent group (model risk, security, or an outside red team) owns the challenge. Internal audit checks that the program works. A named business owner decides go or no-go. SR 26-2 supports this flexibility: it says validation quality depends on the rigor of the review, not on how the risk function is organized.
How can banks test generative AI that falls outside SR 26-2?
Through independent red teaming: adversarial testing of the full workflow a customer or employee uses, built from the institution’s own obligations. Findings are documented and mapped to frameworks such as the NIST AI Risk Management Framework and the EU AI Act, so they can go into a risk register or an audit file.
What does traceability mean for an AI agent?
It means being able to reconstruct what the agent did and why. A complete record covers the request, the instructions and documents the agent worked from, the tools it called, what it returned, any human review, and the versions of the model, prompts, and tools in use at the time. SR 26-2 asks for inventory, documentation, and ongoing monitoring for the models it covers, and the same discipline applies to AI outside its scope.
Should AI agents have their own permissions?
Yes. An agent should have an identity of its own, with least-privilege access scoped to its task, granted when it’s approved and removed when it’s retired, rather than borrowing a human’s credentials or sharing a service account. High-impact actions should need approval, duties should be split so the agent that prepares a payment doesn’t also release it, and the tools and connectors it can call should be vetted. There should also be a documented way to switch the agent off. NIST’s AI Agent Standards Initiative includes a draft concept paper on agent identity and authorization.
How many AI agent incidents involve no attacker?
About one in five. As of September 21, 2026, 109 of the 529 agent incidents in Enkrypt AI’s Agent Incident Registry involved no adversary. These failures happen when a system behaves as built in a situation nobody tested.
When do EU AI Act high-risk rules apply to credit scoring and insurance pricing?
From December 2, 2027. The Digital Omnibus, Regulation (EU) 2026/1744, entered into force on July 27, 2026 and moved the deadline for stand-alone high-risk AI systems under the EU AI Act from August 2, 2026. Those systems include AI used to score individuals’ creditworthiness and AI used for risk assessment and pricing in life and health insurance.