What the SR 26-2 Exclusions for LLMs and AI Agents Mean for Bank Model Risk Management

What the exclusion says, and what it does not

On April 17, 2026, the OCC, the Federal Reserve Board and the FDIC issued revised model risk management guidance. The Federal Reserve published it as SR 26-2 and the OCC as Bulletin 2026-13. The agencies describe it as clarifying model risk management principles, setting out a risk-based approach, and rescinding prior model risk management guidance and other issuances. It addresses factors that influence model risk, model development and use, validation and monitoring, and governance and controls.

On the treatment of LLMs and agents, a Federal Reserve official said in a May 1, 2026 speech that the agencies recently amended the guidance to clarify that it does not apply to generative or agentic AI. The same speech said supervisors had over time expanded the scope of the previous guidance beyond its original purpose and applied it in unintended ways, and that the Fed's approach should help banks implement AI tools safely, effectively and efficiently. Public commentary on the guidance quotes it as stating that generative AI and agentic AI models are not within its scope.

That is the extent of what the exclusion establishes: a boundary around one guidance document. The guidance also states that practices should vary with each bank's risk profile and model usage, and that each bank is responsible for practices appropriate to the risks it faces. As of November 2026, that responsibility is the constant. The exclusion changes which document applies to validation. It does not change who is accountable for the risk.

Why excluded does not mean unregulated

A scope statement in one piece of guidance speaks to that guidance. It does not, by itself, retire expectations that come from elsewhere. A bank that deploys an LLM for customer correspondence or an agent that calls internal tools still runs a system that touches vendors, data, customers and operations. Those are areas where supervisors may ask questions under frameworks other than model risk management.

Public comment letters illustrate the point from two directions. One commenter, writing on a separate Federal Reserve proposal, argues that an AI system acting for a bank through a vendor's product could sit in neither the model risk guidance nor the proposal. That is the commenter's characterization, not an agency position, but it names a real design question: who owns the control when the AI action happens inside a third party's product. Another commenter observes that SR 26-2 excludes deterministic rule-based processes from the model definition, while an FFIEC manual page says rule-based surveillance monitoring systems should still be independently validated. The lesson is that sitting outside the model definition has not historically meant sitting outside all validation expectations.

There is also a housekeeping consequence. Because the prior guidance has been rescinded, internal policies that cite it as the basis for validating AI systems may need review. Dropping an AI system from the model inventory without replacing the control framework that used to surround it leaves a gap.

Frameworks that can still reach an LLM or agent

The table lists areas a bank's examiners may approach when reviewing an excluded AI system, with an illustrative question for each. These are prompts for internal assessment, not statements of specific requirements.

• Third-party risk: Which vendor models or products perform the AI action, and how is their behavior constrained on the bank's behalf?
• Operational risk: What happens when the system errs, loops or acts outside its intended task, and who is accountable?
• Information security: What data can the system read, send or write, and which tools can an agent call?
• Data governance: Which data classes can enter prompts and outputs, and how is sensitive content handled?
• Consumer protection: Can the bank explain what the system said or did in a customer-facing interaction?
• Safety and soundness: Is the use case governed in proportion to its risk, with named owners and a documented rationale?

The evidence gap outside formal model validation

Model validation as the guidance describes it centers on activities such as conceptual soundness review, ongoing monitoring and outcomes analysis. Those activities suit statistical models whose inputs, outputs and performance can be characterized and periodically revisited. An LLM or an agent is different in practice. Its behavior depends on the prompt, the surrounding context and, for agents, the tools it is allowed to call. A periodic review of the model does not tell an examiner what the system did on a particular afternoon.

When a system is outside formal validation, the evidence that would otherwise come from that process is absent, and something has to take its place. The useful question shifts from whether the model is sound to three narrower ones. What was this system permitted to do? What did it actually do, interaction by interaction and tool call by tool call? Where a human approved or escalated an action, who did so and for which action?

There is a tradeoff to weigh. Controls applied only in after-the-fact review can describe what happened but cannot prevent it. Controls applied in the execution path can stop or modify an action before it completes, and they generate the record as a byproduct. Many banks will want both, scaled to the risk of the use case, which is consistent with the guidance's own emphasis on risk-based practice.

Enforcing policy in the execution path

Trussed is built for the evidence gap described above. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. Outcomes are allow, redact, block, rate limit or escalate for human approval. Because enforcement happens at runtime, not after the fact, each decision produces audit-ready evidence of what the system was permitted to do and what it did. That evidence is mapped to frameworks including NAIC, NYDFS, HIPAA, the EU AI Act and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

Insurance, a regulated financial sector, is where Trussed is deepest. Customers span four regulated verticals: insurance, pharma, healthcare and education. Trussed has run in continuous production in a regulated enterprise for more than 18 months, with 99.95% uptime on live production traffic, more than 100 models under one policy plane, and more than 30 GB of audit evidence generated per day. This page makes no claim of bank deployments.

Runtime enforcement does not replace a bank's own judgment about scope, ownership or risk appetite, and it is not a substitute for legal review. It addresses one specific need: a durable record, produced as the system operates, that a risk leader can put in front of an examiner.