LLM Risk Assessment vs Model Risk Management: Coverage Gaps Under SR 26-2

The baseline has changed: SR 26-2 replaces SR 11-7

Many LLM risk discussions in financial services still cite SR 11-7 as the model risk baseline. The Federal Reserve, OCC and FDIC have since issued Revised Guidance on Model Risk Management (SR 26-2), dated April 17, 2026. It supersedes SR 11-7 and the 2021 BSA/AML model risk statement, SR 21-8. As of October 2026, SR 26-2 is the US reference to cite. Internal policies, inventories and validation standards that point to SR 11-7 should be checked and updated.

Several themes in the revised guidance matter for LLM scoping. Model risk management practices vary with a banking organization's risk profile and model usage, and model risk depends on inherent risk, exposure, purpose and use. The guidance also calls for assessing risk individually and in aggregate, including reliance on common assumptions, data or methodologies that could affect several models at once. A shared third-party LLM behind many applications is a natural example of that aggregate exposure.

The guidance describes testing as a core part of development, including out-of-sample and out-of-time testing and a critical assessment of data quality and inputs. Those techniques fit statistical models with defined inputs and outputs. The gaps below appear when the same review is applied to a system whose inputs include free text and whose outputs can trigger actions.

Mapping review components to LLM risk areas

The table takes each component of a traditional review and shows what an LLM deployment adds. The useful question for each row is whether pre-deployment work is enough or whether a runtime control is also needed.

• Inventory: A model list does not capture prompts, context sources, tools and third-party model versions that together define the deployment. Both: inventory the dependencies, and see at runtime what was actually invoked.
• Development and testing: Out-of-sample testing assumes a stable relationship between inputs and outputs. LLM outputs vary, and inputs include untrusted text. Both: test before release, enforce policy during use.
• Validation: Validation is a point-in-time conclusion about behavior on the tested cases. It cannot speak to later prompts or later model behavior. Both: validate, then constrain at runtime.
• Ongoing monitoring: Performance metrics do not show prompt manipulation, data exposure or unauthorized actions in individual interactions. Runtime control, with per-interaction records.
• Change management: A provider can change a hosted model, or a team can change a prompt or tool, without a conventional model change. Both: parallel run on replacement, and hold policy constant at runtime.
• Documentation: A validation report describes design and testing. It does not record what happened in a given interaction. Runtime evidence fills that gap.

Which LLM risks fall outside periodic validation

Prompt and context manipulation is the clearest case. NIST's adversarial machine learning taxonomy notes that many LLM application vulnerabilities arise because instructions and data are not provided to the model in separate channels. Attackers can inject instructions through data the model reads, a flaw NIST compares to SQL injection. It also describes jailbreaks as direct prompting attacks that bypass restrictions set by a developer or deployer. Validation can sample such attacks. It cannot prove that restrictions inside the model will hold against the next one.

Sensitive data exposure follows a similar pattern. OWASP's LLM02:2025 describes models embedded in applications exposing sensitive or confidential details through output, and NIST notes that attacks may reveal private information supplied in context but not intended for unfiltered user access. Exposure can occur in prompts, retrieved context or responses, long after validation closed.

Tool and agent actions raise the consequence. When model output can invoke a tool, an incorrect or manipulated output becomes an action. OWASP recommends validating proposed tool arguments, enforcing the caller's permissions in execution code outside the model, requiring action-specific approval for high-risk operations, and treating model output as untrusted at every downstream use.

The remaining areas are output variability and third-party dependence. Output variability limits what any finite test set can show. Dependence on an external model means behavior can change outside the institution's change process, and shared dependencies concentrate risk in the aggregate sense SR 26-2 describes. FINRA has suggested that firms adopting AI review and update their model risk frameworks, citing explainability, data integrity and customer privacy, and that validation cover input data, parameters and thresholds, and output. FINRA also suggests running current and new models in parallel until the new ones are validated. These steps help before and during a transition. They do not replace controls that operate on each interaction.

What evidence a reviewer is likely to ask for

A validation package answers whether the model was sound when reviewed. A reviewer examining an LLM deployment will also want to know what the system was permitted to do, what it did, and who intervened. The following is design rationale for assembling that evidence, not a statement of examiner requirements. The practical test is whether a specific interaction from last quarter can be reconstructed from retained records: the policy in force, the decision, the identity involved, and any human approval.

This changes how limitations are handled. Where pre-deployment validation cannot cover a risk, the limitation should be documented and a compensating control named, with the evidence that control produces. Risk tiering should follow SR 26-2's emphasis on use and exposure, so an assistant that drafts internal notes carries a different control set from an agent that can move data or trigger transactions.

A short set of practical steps follows from this. Replace SR 11-7 references in policy. Add prompts, context sources, tools and external model dependencies to the inventory. Build the risk-to-control-to-evidence map for each deployment. Decide which tool actions need human approval and where that approval is recorded. Document third-party LLM concentration as aggregate risk.

Where Trussed fits

Trussed addresses the runtime half of this gap. It enforces policy in the execution path across models, agents, tools and MCP servers, on individual interactions and tool calls. Outcomes are allow, redact, block, rate limit, or escalate for human approval. Policy is enforced at runtime, not reviewed after the fact, and each enforcement decision generates audit-ready evidence mapped to frameworks including NAIC, NYDFS and NIST. It complements model validation rather than replacing it.

Insurance, a regulated financial sector, is where Trussed is deepest. Trussed has not been deployed in banking or broker-dealer settings, and the framing here is model risk management and examiner scrutiny, not a claim of financial-services customers. The platform has run in continuous production in a regulated enterprise for more than 18 months, with 99.95% uptime on live traffic and more than 100 models under one policy plane. It can be self-managed in the customer's cloud, with configurable retention and data residency.