SR 26-2 LLM Governance: Controlling and Evidencing a Model That Calls an LLM

Inventory, scoping and change management

SR 26-2 was issued on April 17, 2026 by the Federal Reserve, the FDIC and the OCC as revised model risk management guidance. It covers the factors that influence model risk, model development and use, validation and monitoring, and governance and controls. It also recognizes that practices appropriately vary with a banking organization's risk profile and model usage. As of November 2026, a hybrid system needs a deliberate scope decision rather than an assumption.

The first governance question is whether the LLM component, and the combined system, fall within the guidance's definition of a model. Whatever the conclusion, record it in policy with the rationale. Where a tool or system is not covered by the guidance, the bank's own risk management and governance practices should determine the controls, so the LLM component should still sit under a documented control set. Map those controls to the existing model risk management framework rather than creating a parallel one.

The inventory entry should identify the LLM dependency, the model that invokes it and the task performed, with enough information to understand risk for the individual system and in aggregate. Change management is the second gap. A change to the LLM version, a prompt template, a retrieval source or a tool permission can alter behavior without touching the in-scope model's code. Each should be a tracked and approved change, with a defined trigger for revalidation.

Separating pre-deployment controls from runtime controls

Pre-deployment validation answers whether the design is sound and whether the system meets defined performance thresholds before it goes live. NIST AI 600-1 suggests minimum performance or assurance thresholds that are reviewed in go/no-go deployment approval, and NIST AI RMF MEASURE 2.9 calls for the model to be explained, validated and documented, with output interpreted in context. These belong before deployment: task-level accuracy testing, documented limitations, approval criteria, and a decision on who provides effective challenge of the LLM component.

Periodic review and ongoing monitoring address drift and recurring issues over time. NIST AI RMF treats risk management as continuous across the lifecycle, and NIST AI 600-1 calls for regular checks that security measures remain effective. Exceptions, recommendations and management responses should be documented.

Some controls cannot be demonstrated by testing alone because they concern a single interaction. Examples include whether a prompt contained data the LLM should never receive, whether an output was passed downstream without review, whether a tool call stayed within its permitted scope, and whether call volume exceeded a set limit. For these, the control has to operate in the execution path: allow the interaction, redact part of it, block it, rate limit it, or escalate it for human approval. The practical test is whether a policy can be stated as a rule on one interaction. If it can, runtime enforcement is a candidate. If it concerns the design or statistical performance, it belongs in validation.

The evidence an examiner would expect to inspect

An examiner reviewing a hybrid system needs to see what the system was permitted to do and what it did. These are separate records. The first is the policy in force at the time of each interaction, including its version and who approved it. The second is the interaction record, showing the action taken, such as allowed, redacted, blocked, rate limited or escalated, along with the outcome of any human approval.

The evidence should also tie to the inventory entry and to change records, so a reviewer can see which LLM version, prompt template, retrieval sources and tool permissions applied on a given date. Retention periods and data residency obligations for this evidence must be confirmed with legal and compliance, because interaction records can contain sensitive customer data. Decide up front what is stored in full, what is stored in redacted form and who can access it. NIST AI RMF documentation expectations give a useful framing for what the evidence should support.

Where runtime policy enforcement fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. The actions are allow, redact, block, rate limit and escalate for human approval. They are enforced at runtime, not reviewed after the fact. Enforcement generates audit-ready evidence continuously, mapped to frameworks including NIST, and it can be self-managed in the customer's cloud with configurable retention and data residency. Trussed does not claim model lineage or end-to-end tracing of agentic workflows.

For a model risk program, the relevant question is whether this fits the control set already defined: whether the policies can express the interaction-level rules identified above, and whether the evidence can answer an examiner's questions. Trussed's production record is in regulated enterprises, and insurance, a regulated financial sector, is where it is deepest. That includes 18+ months of continuous production in a regulated enterprise, 99.95% uptime on live production traffic and 100+ models under one policy plane. It also includes customers across four regulated verticals: insurance, pharma, healthcare and education. Trussed does not claim bank deployments. The value for a bank is in examiner scrutiny and evidence, and any fit has to be established against the bank's own requirements.