Model Risk Management Principles Extended to LLMs and Agents: A Requirement-to-Control Table

What the April 2026 guidance does and does not say

On April 17, 2026, the OCC, Federal Reserve and FDIC issued revised model risk management guidance. It supersedes SR 11-7 and SR 21-8, and the OCC states that it rescinds prior model risk management guidance and other issuances. It covers model development and use, validation and monitoring, governance and controls, and vendor and other third-party products.

Two points matter for anyone building a requirement-to-control table. First, the guidance states that generative AI and agentic AI models are novel and rapidly evolving and are not within its scope. Its principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI models. Second, it sets no enforceable standards or prescriptive requirements, and non-compliance will not result in supervisory criticism.

For tools and systems it does not cover, the guidance says a banking organization's own risk management and governance practices should guide the appropriate governance and controls. The agencies have also said they plan a request for information on model risk management that considers banks' use of AI, including generative and agentic AI. A table that calls its rows guidance requirements for LLMs would therefore overstate the text. The more defensible framing is that the institution has chosen to extend model risk principles to LLMs and agents, and has documented why.

The model definition also matters. It excludes deterministic rule-based processes, so a runtime policy engine should not be described as a model under the guidance.

Requirement-to-control table: principles extended to LLMs and agents

Each row starts from a theme in the revised guidance, which was written for traditional and non-generative models. The runtime control, enforcement point and evidence are an institution's design choices, not regulatory prescriptions. Rows describe what is enforced on individual interactions and tool calls, and what each decision leaves behind.

• Governance and policy: Runtime control: written policy expressed as enforceable rules that return allow, redact, block, rate limit or escalate. Enforcement point: the policy decision made on each prompt, output and tool call. Evidence: the policy version applied and the decision record for each interaction.
• Controls over use: Runtime control: scoped permissions for which models, tools and MCP servers an agent may reach, with redaction of sensitive data in prompts and outputs. Enforcement point: before the model call or tool call executes. Evidence: the requested action, the decision and the rule that produced it.
• Ongoing monitoring: Runtime control: rate limits and blocks tied to defined thresholds, with decision records reviewed over time. Enforcement point: continuous, at each interaction. Evidence: aggregated allow, block and escalation counts by policy, model and tool. This supports periodic monitoring and does not replace validation.
• Human oversight: Runtime control: escalation for human approval on defined high-consequence actions. Enforcement point: the action is held until an approver responds. Evidence: the action held, the approver, the outcome and the time.
• Third-party products: Runtime control: the same policy applied to vendor-supplied models and tools at the point of use. Enforcement point: the outbound call to the provider or tool. Evidence: which provider or tool was called, under which policy, with what decision.
• Documentation and evidence: Runtime control: enforcement generates the record as a by-product, with configurable retention. Enforcement point: written at decision time, not reconstructed later. Evidence: durable records that internal audit and examiners can access directly rather than through management summaries.

Periodic review versus per-interaction evidence

The guidance's emphasis on validation and monitoring is lifecycle-level. Validation asks whether a model is conceptually sound and performs as intended. Monitoring asks whether that remains true over time. Neither, by itself, shows what an LLM or agent was permitted to do on a specific Tuesday afternoon, or what it actually did.

That gap is where runtime controls differ from after-the-fact review. A control enforced at runtime changes the outcome: a prompt containing account data is redacted, a tool call to an unapproved MCP server is blocked, a payment-related action waits for an approver. Review after the fact can only describe what already happened. Both are useful, but they answer different questions, and the table should keep them in separate columns so that evidence from one is not presented as evidence of the other.

Governance expectations in the guidance still apply to the institution's own design. Sound governance delineates who is responsible for key activities across the lifecycle, and internal audit generally assesses whether practices are rigorous and effective rather than duplicating them. For runtime controls, that means named owners for policy changes and decision records internal audit can inspect without relying on the team that operates the control.

Cross-referencing NIST AI 600-1 and documenting the rationale

Because the revised guidance leaves generative and agentic AI to institutional governance, a second reference point helps. NIST AI 600-1, the Generative AI Profile, provides actions to govern, map, measure and manage generative AI risks. These include enumerating generative AI systems for the AI system inventory and applying existing risk management policies to third-party generative AI data and systems. Its measurement actions on explaining, validating and documenting the model and interpreting output in context are model-level activities, not per-interaction enforcement. Confirm action identifiers against the current published text before citing them in a table.

Until the planned request for information produces further direction, document your own rationale. Record that generative and agentic AI are outside the April 2026 guidance, which principles you have chosen to extend, which governance standard applies, and which table rows are enforced at runtime versus handled by validation, inventory or change control. Examiners and internal audit are better served by a stated position than by an implied one.

Where Trussed fits

Trussed is one way to implement the runtime rows of the table. It enforces policy in the execution path across models, agents, tools and MCP servers: allow, redact, block, rate limit, or escalate for human approval, on individual interactions and tool calls. Enforced at runtime, not reviewed after the fact, each decision generates audit-ready evidence, mapped to frameworks including NIST, NAIC and NYDFS. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

Trussed does not replace validation, inventory, lineage, end-to-end workflow tracing or transaction-level governance, which remain separate programs. Insurance, a regulated financial sector, is where Trussed is deepest. The platform has run continuously in production in a regulated enterprise for 18+ months at 99.95% uptime, with 100+ models under one policy plane.

The table above is useful whichever tooling you choose. The evaluation question is whether each runtime row produces a record you can hand to an examiner without reconstruction.