SR 11-7 and AI Agents: What Model Risk Management Asks For, Now That Its Replacement Leaves Agents Out
SR 11-7 was superseded on 17 April 2026 by SR 26-2, which puts generative and agentic AI explicitly out of scope and leaves their controls to each bank's own governance. SR 11-7 is still the most complete template for that job: a clear statement of purpose, validation of conceptual soundness, ongoing monitoring and outcomes analysis, an inventory, and effective challenge with the authority to restrict use.
On this page
For fifteen years, SR 11-7 set out how US bank supervisors expected model risk to be managed. On 17 April 2026, the Federal Reserve, the OCC and the FDIC replaced it. SR 26-2 supersedes SR 11-7, and the revised guidance attached to it contains a footnote that matters to anyone running AI agents in a bank: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance."
The same footnote says a bank's own risk management and governance practices should guide the controls for anything the guidance does not cover. The OCC's Bulletin 2026-13, issued the same day, said the agencies planned to issue "in the near future" a request for information on model risk management that would consider banks' use of AI, including generative and agentic AI.
So for agents, the agencies have handed the question back to the banks. The obvious template is the one model risk teams already know.
What SR 11-7 asked for
The 2011 guidance (the FDIC's adopted copy is still online) defined model risk as "the potential for adverse consequences from decisions based on incorrect or misused model outputs and reports". It organised the response into three elements, held together by one principle:
- Development, implementation and use: a clear statement of purpose, sound data, and testing that includes conditions outside the ordinary.
- Validation: three core elements, namely evaluation of conceptual soundness, ongoing monitoring (including process verification and benchmarking), and outcomes analysis (including back-testing), generally carried out by people who are not responsible for development or use.
- Governance, policies and controls: board and senior management oversight, written policies, clear roles, internal audit, a model inventory and documentation.
- Effective challenge: "critical analysis by objective, informed parties who can identify model limitations and assumptions and produce appropriate changes", which, the guidance said, depends on incentives, competence and influence.
Is an AI agent a "model" under SR 11-7?
Often not, strictly. SR 11-7 defined a model as a quantitative method that processes input data "into quantitative estimates", and much of what an agent produces, such as an email, a refund or a case note, is not an estimate. The guidance anticipated this. A footnote said that more qualitative approaches outside the definition "should also be subject to a rigorous control process".
SR 26-2 narrows the definition further and then excludes agents by name. The useful question was never whether an agent is a model. It is whether the agent gets the discipline.
How SR 11-7 maps to an AI agent
| SR 11-7 asks for | For an AI agent, that means |
|---|---|
| A clear statement of purpose | A written mandate: tasks, tools, the actions it may take and the ones it may not |
| Testing outside the range of ordinary expectations | Adversarial inputs, injected instructions, out-of-scope requests |
| Evaluating the impact on models that rely on the output | Tracing what downstream agents and systems do with what it produces |
| Conceptual soundness | Review of the prompt, tool set, permissions and evaluation rubric before launch |
| Process verification and change control | Versions for prompts, tools and the underlying model, with every change logged |
| Outcomes analysis | Comparing actions with what happened next: reversals, complaints, reopened cases |
| Analysis of overrides | Treating human reversals of agent actions as evidence about the agent |
| A model inventory | An agent inventory: purpose, owner, tools, foundation model and version, restrictions |
| Validation of vendor models | Evidence from the model provider, and a plan for when that model changes or is withdrawn |
Three of these deserve more than a table row.
Overrides are evidence
SR 11-7 said that overrides are an indication "that, in some respect, the model is not performing as intended", and that a high override rate is often a sign the model needs revision. The agent equivalent is the reviewer who reverses or edits an agent's action. If nobody counts those reversals, the bank is discarding its earliest warning. If nobody is reversing anything, it is worth checking whether reviewers are still really reviewing.
Change control now includes someone else's model
SR 11-7 asked that model code be controlled so that it "cannot be altered except by approved parties", with every change logged. An agent's behaviour depends on its prompt, its tools and a foundation model the bank usually does not control, and any of them can change. Each needs a version. SR 11-7 also said material changes to models should be validated; for an agent, a new prompt, a new tool or a new model version can be exactly that.
Effective challenge needs authority, not just independence
SR 11-7 was specific that challenge fails without influence, and that control staff "should have the authority to restrict the use of models". For an agent, that means two things. The evaluation is done by people, and with tools, that the agent's builders do not own. And a failed evaluation can actually restrict what the agent may do. A finding that cannot restrict anything is a report, not a challenge. One-off red-team exercises do not meet this bar on their own; their findings have to become standing release gates.
What SR 26-2 changes for the models it does cover
For traditional models, SR 26-2 keeps much of the vocabulary: conceptual soundness, outcomes analysis, ongoing monitoring, a model inventory, effective challenge. It is shorter, risk-based and explicitly non-prescriptive. It says it is most relevant to banking organisations with more than $30 billion in total assets. It drops SR 11-7's at-least-annual review language, saying instead that the timing and frequency of validation vary with the model's purpose, methodology and changes. And it states that it does not set enforceable standards, so non-compliance with it will not result in supervisory criticism, while noting that supervisory action can still follow from unsafe or unsound practices in managing model risk.
For agents, that leaves a bank's own framework as the standard it will have to defend. Building that framework from SR 11-7's parts has a practical advantage: its terms are the ones model risk, validation and audit staff have worked with since 2011. Documentation is the easiest part to skip; SR 11-7 itself noted that developers who know a model well may not appreciate its value. It wanted documentation detailed enough that "parties unfamiliar with a model can understand how the model operates", and for an agent that starts with a record of each consequential action: who acted, on whose authority, what it did and what checked it.
Where Syntrox fits
Effective challenge needs a check that the agent's builders do not control, and results a validator can reproduce. Syntrox sits outside the agent. Nucleus runs at temperature 0 with a fixed seed, so the same input gives the same verdict, and every verdict is stamped with the judge model and version that produced it. Per evaluated trace, Syntrox records the score, confidence and judge version, which is the evidence a validator needs to re-run a finding.