Model risk management handoff checklist for AI agents under the April 2026 guidance

What changed in April 2026, and what it means for agents

On April 17, 2026, the Federal Reserve (SR 26-2), the OCC, and the FDIC issued revised model risk management guidance. The OCC states that it rescinds prior model risk management guidance and other issuances, and the FDIC is rescinding FIL-22-2017 and FIL-27-2021 in connection with the release. The guidance asks for practices that are risk-based and tailored to the size, complexity, and extent of model use. This is current as of November 2026.

The Federal Reserve letter also says that generative AI and agentic AI models are novel and rapidly evolving and are not within the guidance's scope. Its principles are stated to apply to traditional statistical and quantitative models and to non-generative, non-agentic AI models. For tools and systems the guidance does not cover, a bank's own risk management and governance practices should determine the governance and controls.

For an AI platform team, this changes how the handoff should be framed. Whether an agent is treated as a model, and how it is tiered, is a classification decision the bank makes under its own policy. The guidance's definition of a model, a quantitative method that applies statistical, economic, or financial theories to produce quantitative estimates, does not clearly map to an agent. The checklist below is useful because the guidance's principles are sound, not because a rule demands it. Record the bank's scope decision in the package, and apply the same controls whichever way that decision goes.

How to use the checklist

Each item below has three parts. The platform team states what it provides. The model risk team states what it verifies. The evidence line names what demonstrates the item without relying on the platform team's description alone.

This structure follows the guidance's emphasis on delineated responsibilities across the lifecycle. It also supports effective challenge, which the guidance describes as critical analysis by objective experts. A reviewer cannot challenge what has not been written down. The package should be assembled before validation or equivalent independent review begins, since validation generally precedes first use. Involving model risk during design, rather than only at handoff, reduces rework. NIST's AI RMF Playbook, a voluntary reference and not a checklist, likewise suggests including oversight functions from the start and separating development from oversight.

What runtime enforcement and evidence can support

Items 3 and 4 are where runtime policy enforcement is most relevant. Policy enforced in the execution path, rather than reviewed after the fact, means the record of what the agent was allowed to do is produced by the same mechanism that made the decision. Trussed enforces policy in the path across models, agents, tools, and MCP servers, with allow, redact, block, rate limit, and escalate for human approval. It generates audit-ready evidence at the level of individual interactions and tool calls. It can be self-managed in the customer's cloud, with configurable retention and data residency, which lets a bank set those values to its own policy.

This evidence can inform parts of the review: it gives model risk a durable record of permitted and executed actions to test against the inventory and the intended-use statement. It also supports monitoring of escalations and exceptions. Trussed has run continuously in production at a regulated enterprise for more than 18 months, and insurance, a regulated financial sector, is where it is deepest.

The limits matter as much. Runtime evidence does not perform validation, conceptual soundness assessment, outcomes analysis, effective challenge, or model risk tiering. Those remain the bank's responsibilities under its own governance and documentation processes. The evidence is scoped to individual interactions and tool calls, so the bank should decide whether that granularity is enough for each agent, and cover other needs such as model lineage or dataset provenance through its own documentation.

Running the handoff and testing sufficiency

Hold a working session where model risk tries to answer, from the package alone, the questions an examiner or internal audit is likely to ask. What was the agent permitted to do? What did it do on a given date? Who approved the exceptions? How would a change to the model or a tool have been identified and routed? If a reviewer needs a verbal explanation, the package is incomplete.

Two tradeoffs deserve an explicit decision. Tighter runtime policies reduce exposure but increase escalations, which adds approver workload. Longer retention and broader capture improve traceability but raise storage and access-control obligations. Record the chosen balance and the rationale in the package.

Because supervisory expectations for agents are set by each bank's own governance, align the checklist with the bank's model risk policy, and have model risk approve the final form. Version the checklist itself, so a later reviewer can see which version a given agent was handed off under.