Why SR 26-2 Excludes Generative and Agentic AI, and What It Means for Runtime Control

Read the exclusion as a scoping decision

Risk leaders tend to react to an exclusion in one of two ways. Some assume the excluded systems are already covered by existing model validation and governance processes. Others assume the exclusion means no supervisory expectations apply at all. Both readings are wrong, and both lead to weak control design.

Guidance is written for a defined class of system. SR 26-2 is model risk management guidance, and its processes of inventory, validation, ongoing monitoring and governance are built around models in that sense. Placing generative and agentic AI outside its scope means those processes are not the prescribed mechanism for those systems. It is a statement about the reach of one document. It is not a statement that the institution's accountability for the systems it deploys has lapsed, and it is not a loophole to be exploited.

The practical consequence is that the institution decides, within its own risk framework, how excluded systems are identified, assessed, controlled and evidenced. That decision should be deliberate and documented rather than inherited by default.

Why these systems do not fit a model-centric approach

The structural reasons are visible in how the systems behave. Model-centric validation assumes a bounded object that can be tested before release and monitored against stable expectations. Generative and agentic systems weaken each of those assumptions.

• Inputs: A conventional model takes structured, defined inputs. A generative system accepts open-ended natural language, so the input space cannot be enumerated in advance.
• Outputs: A conventional model returns the same output for the same input. A generative system can return different outputs for the same prompt, so a validation sample describes the system only partly.
• Behavior: Generative behavior is steered by prompts and context at the time of use, so it can change without any change to the underlying model.
• Actions: NIST and CAISI describe an agent system as a generative model plus scaffolding software that equips it with tools to take discretionary actions. Risk attaches to what the agent does, not only to what it says.
• Attack surface: NIST material notes that attackers can manipulate an agent's natural-language input to alter its goals, exfiltrate data or hijack workflows, and that legitimate tools can be misused through prompt manipulation or privilege control.

What remains the institution's responsibility

Out of scope for one guidance document does not mean out of scope for the risk function. Three reference points are useful, and none of them depends on SR 26-2.

First, third-party risk. Many generative and agentic capabilities are supplied by vendors. A proposed third-party risk management guidance, published in the Federal Register in September 2026 and still a proposal as of November 2026, describes oversight proportionate to the risk of each relationship and consistent with the banking organization's risk appetite and tolerances. For higher-risk relationships it may include due diligence, contract negotiations and ongoing monitoring. Because it is a proposal, treat it as a signal of direction rather than a settled obligation.

Second, voluntary frameworks. NIST AI RMF 1.0 and its generative AI profile, NIST AI 600-1, give a shared vocabulary for risk management and documentation. The profile states that use of generative AI systems may warrant additional human review, tracking and documentation, and greater management oversight. The AI RMF also says that where risk levels are very high, development and deployment should cease in a safe manner until risks can be sufficiently managed. These are not banking supervisory requirements, but they are credible benchmarks for internal policy.

Third, the institution's own policies. Whatever the external text says, the board-approved risk appetite and internal control standards still apply to any system that touches customers, data or operations. Examiners and auditors will ask what the institution decided for these systems and whether it can show that the decision was carried out.

Runtime control and evidence for AI that takes actions

Pre-deployment review remains useful, but it cannot settle the behavior of a system whose inputs are open-ended and whose outputs vary. For agents, the decisive moment is when a prompt becomes a tool call. A control placed in the execution path can act at that moment, on that interaction, with the policy in force at that time.

The set of decisions available at that point is small and familiar: allow the action, redact sensitive content, block the action, rate limit it, or escalate it for human approval. Escalation maps directly to the human review and oversight that NIST says generative AI may warrant. Authorization limits on tools and privileges address the tool-misuse and privilege-control threats NIST describes.

Evidence follows from the same placement. If each decision is recorded with its input, the policy applied and the outcome, the institution holds a durable record of what the system was allowed to do and what it did. That supports the tracking and documentation referenced in NIST AI 600-1 and gives audit and examination teams something concrete to review.

There are tradeoffs. Runtime enforcement adds a decision point to the request path, so latency, failure behavior and policy maintenance need design attention. Policies that are too coarse will block legitimate work, and policies that are too loose will not matter. Treat runtime control as a complement to inventory, third-party oversight and human accountability, not a replacement for them.

Where Trussed fits

Trussed is control and evidence infrastructure for consequential AI, built for the regulated enterprise that must show a regulator or auditor what its AI was allowed to do and what it did. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. The decisions are allow, redact, block, rate limit and escalate for human approval, and they are enforced at runtime, not reviewed after the fact. The scope is individual interactions and tool calls.

The enforcement itself generates continuous audit-ready evidence, mapped to frameworks including NIST, NAIC, NYDFS, HIPAA and the EU AI Act. Deployment is self-managed in the customer's cloud, with configurable retention and data residency. Trussed has run in continuous production in a regulated enterprise for more than 18 months, and operates 100+ models under one policy plane.

This addresses one part of the problem described above: runtime enforcement and evidence for AI that takes actions. It does not replace the inventory, third-party and accountability decisions that remain with the institution.