SR 26-2 explained: governing agentic AI when model-risk guidance excludes it

For fifteen years, US bank model risk management meant SR 11-7. On 17 April 2026 the Federal Reserve, OCC and FDIC replaced it with a joint revision: SR 26-2 at the Fed, OCC Bulletin 2026-13 and FDIC FIL-15-2026. One footnote in it matters more than any other for anyone building agents in a bank: generative and agentic AI are explicitly out of scope.

That footnote does not give you a free pass. It hands the question back to you. This article covers what the guidance says (quoted from the primary text), what the exclusion does and does not mean, and a control framework for the gap that reuses the parts of model-risk discipline that still work.

This is a practitioner’s reading, not legal or regulatory advice. Talk to your compliance and model-risk teams before you act on it.

What SR 26-2 actually says

Read the guidance itself, the SR 26-2 attachment. It’s twelve pages. The parts that matter for agents:

• It supersedes SR 11-7 (2011) and SR 21-8 (2021, BSA/AML models). The OCC bulletin also rescinds OCC Bulletin 2011-12, Bulletin 2021-19, Bulletin 1997-24 and the Model Risk Management booklet of the Comptroller’s Handbook.
• It is principles-based, and explicitly not enforceable on its own. In the guidance’s words it “does not set forth enforceable standards or prescriptive requirements; accordingly, non-compliance with this guidance will not result in supervisory criticism.” Footnote 1 adds the caveat that matters: “supervisory action may result for any violations of law or unsafe or unsound practices stemming from insufficient management of model risk.”
• It is aimed at larger banks. It is “expected to be most relevant to banking organizations with over $30 billion in total assets,” though it may also matter for smaller banks with significant model exposure.
• “Model” is narrower than before. A model is “a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates.” Simple arithmetic and “deterministic rule-based processes and software” are excluded.
• Generative and agentic AI are excluded. Footnote 3, verbatim:

“Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance. Nonetheless, a banking organization’s risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document. However, the principles described in this guidance apply to traditional statistical and quantitative models and non-generative, non-agentic AI models.”

The OCC bulletin adds that the agencies plan to issue a request for information on model risk management generally, including banks’ use of AI and specifically generative and agentic AI. As of October 2026 I could not confirm that this RFI has been published, so check the agencies’ press pages before you cite it.

Be careful with secondary sources. Some vendor posts claim SR 26-2 “covers agentic AI.” The primary text says the opposite.

What the exclusion means, and what it doesn’t

It does not mean “ungoverned.” The footnote tells you to govern these systems with your existing risk-management and governance practices. Your other obligations don’t care about the footnote either: third-party risk management, information security, operational resilience, fair lending, consumer protection, BSA/AML and privacy all still apply to whatever the agent touches. And footnote 1’s “unsafe or unsound practices” language still covers you if an ungoverned agent causes harm.

It does mean you have to write your own standard. There is no agency rulebook for agents to point at, so your organization defines what “adequate” looks like and must be able to defend it. That is harder than following guidance, but it also lets you design controls that fit how agents actually fail.

Hybrid systems split. Most production agents in a bank are not purely generative. An agent that calls a traditional credit-scoring model as a tool, or routes requests with a non-generative classifier, contains in-scope models. Those components stay in your model-risk program, with tiering, validation and monitoring as usual. The LLM, the harness, the prompts and the tool layer around them fall under the agent standard. Decompose before you classify.

%% caption: Which rulebook applies? Triage a new AI use case
flowchart TD
    A(["New AI use case"]):::system --> B{"Generative or agentic<br/>component?"}:::decision
    B -- "No" --> C{"Produces quantitative<br/>estimates from theory?"}:::decision
    C -- "Yes" --> D(["Model under SR 26-2:<br/>tier, validate, monitor"]):::outcome
    C -- "No" --> E(["Software and EUC controls"]):::outcome
    B -- "Yes" --> F["Decompose the system"]:::workflow
    F --> G["Traditional or non-generative<br/>models it calls"]:::system
    G --> D
    F --> H["LLM, harness, prompts,<br/>tools, memory"]:::agent
    H --> I(["Agent governance standard:<br/>inventory, tier, evaluate,<br/>change control, monitor, oversee"]):::outcome

A control framework for the gap

The good news is that SR 26-2’s structure still makes a useful skeleton. Development, validation, monitoring, governance and third-party oversight are the right questions for agents. The answers just change, because an agent’s output is a sequence of actions chosen at runtime rather than a score. Here are the seven controls I would put in an agent standard, each tied back to the SR 26-2 concept it borrows from.

1. Inventory: one record per agent, not per model

SR 26-2 calls a comprehensive inventory “common industry practice.” For agents, the record has to cover more than one model. At minimum:

• owner, business purpose and the decisions or actions it supports;
• the model(s) and provider(s) it calls, pinned to version;
• every tool it holds, with each tool’s action class (read, reversible write, irreversible write);
• the data it can reach and its classification;
• the prompt and configuration version currently deployed;
• any in-scope models it calls (cross-referenced to the model inventory).

If this sounds like a lot, start with the adoption ladder inventory and grow it.

2. Tiering: reuse materiality, add autonomy

SR 26-2 sets materiality from exposure (how much the output affects) and purpose (regulatory and financial-risk uses rank higher). Keep both and add the dimension that matters most for agents: autonomy, meaning what the agent can do without a human approving it. A simple three-tier scheme:

Tier drives everything below it: depth of evaluation, who approves changes, monitoring frequency and the human-oversight pattern.

3. Validation-like evidence: evaluate the behavior, review the design

You can’t validate an agent the way you validate a scorecard, because you can’t enumerate its trajectories in advance. You can still produce the two kinds of evidence SR 26-2 asks for:

• Conceptual soundness → design review. An independent reviewer checks the architecture: capability boundaries enforced in the tool layer rather than in the prompt, approval gates on irreversible actions, how untrusted input is handled (see the prompt-injection threat model), and failure modes. This is where “effective challenge” happens for agents.
• Outcomes analysis → evaluation suites. Golden tasks, including should-refuse and error-recovery cases, run before deployment and on every change, with pass thresholds set by tier. The evaluation tutorial builds this harness.

SR 26-2 also allows use before validation finishes in urgent cases, with limits and closer monitoring. The agent equivalent is a constrained launch: read-only tools, or every action behind pre-approval, until the evidence is in.

4. Change management: everything is a model change

An agent changes when any of its parts change: the model version, the system prompt, a tool’s description or schema, a retrieval index, an MCP server upgrade. Treat each as a change that re-runs the evaluation suite and, above a tier threshold, needs sign-off. Pin model versions, never use “latest” aliases in production, and pin your dependencies and tool servers too. The supply-chain guide covers how.

5. Ongoing monitoring: watch trajectories, not just outputs

SR 26-2’s ongoing monitoring asks whether the model still performs as expected as conditions change. For agents, monitor the trajectory: cost and step-count outliers, never-before-seen tool sequences, approval-override rates and production pass rates on sampled tasks. The observability guide has the log spec and the four alerts worth paging on.

6. Human oversight: designed, measured and tiered

Put the human where the risk is. A blanket rule of “a human approves everything” turns into rubber-stamping within weeks. Use pre-approval for irreversible, material actions, sampling audits for reversible ones, and track override rates as evidence that oversight is real. The human-in-the-loop patterns piece covers the five patterns and the matrix for choosing between them.

7. Third-party and model-provider risk

SR 26-2’s vendor section says you still need to understand a vendor model’s “conceptual soundness, design, development data, and performance,” even when the vendor won’t share the internals. Foundation-model providers are the extreme case, since you’ll never see the weights or training data. So compensate with what you control:

• contractual terms on data use, retention, model deprecation notice and incident notification;
• your own evaluation evidence on your tasks, re-run whenever the provider ships a new version;
• a tested fallback (a second provider or a degraded mode) for Tier 1 agents;
• the provider’s published documentation (model cards, system cards, usage policies) filed with the inventory record.

Model providers are also third parties under your existing third-party risk-management program. Run them through it like any other critical vendor.

The mapping table

“By analogy” is the honest label. None of these are requirements for agents under SR 26-2. They’re the parts of a framework your examiners and auditors already understand, applied to a system the framework chose not to cover.

Where to start

If you have nothing today, do these in order:

1. Build the inventory and tier every agent you can find, including the ones teams built without asking.
2. Write a two-page agent standard that names the seven controls above and what each tier requires.
3. Get Tier 1 agents through design review and an evaluation suite first.
4. Wire up trajectory logging before you need it for an incident.

The governance framework walks one generic agent through all five control layers, and the EU AI Act timeline covers what changes if you also operate in Europe.