Proving AI Use Limits Are Enforced at Runtime in Banks After SR 26-2

What SR 26-2 asks, and what it does not specify

SR 26-2 is a Federal Reserve supervision letter dated April 17, 2026. The OCC announced updated model risk management guidance the same day, issued in coordination with the Federal Reserve Board and the FDIC. The guidance highlights sound principles for model risk management and recognizes that practices appropriately vary among banking organizations based on risk profile and model usage. Each bank remains responsible for adopting practices that are appropriate and effective for the risks it faces.

Two parts of the text bear directly on AI use limits. Where a model has limitations, sound practice includes determining appropriate controls, and the examples given are placing limits on model use or more closely monitoring performance. The guidance also says adequate documentation supports effective model risk management, including the tracking of recommendations, responses and exceptions.

That is the extent of what the guidance supports here. It does not prescribe a technical enforcement mechanism or a specific evidence format. Applying it to AI models, agents and tool calls is an interpretation, and because expectations scale with risk, the rigor of runtime controls should follow the risk tier of the use case. Risk leaders should expect examiners to ask a simple question: when your policy says a use is limited, how do you know the limit held?

Stated, enforced and provable limits

Separating these three states clarifies where a control program stops. Each state maps to different artifacts that an examiner could reasonably request.

• Stated limit: Artifacts: policy text, model inventory entry, approval record. Shows intent and authorization. Does not show what happened at execution.
• Enforced limit: Artifacts: a policy evaluated in the execution path that can allow, redact, block, rate limit or escalate a call before it proceeds. Shows the limit operated as a control.
• Provable limit: Artifacts: an enforced limit plus a retrievable record of the policy applied, the call it applied to, the decision and its outcome, retained with integrity protections.

Where common controls leave gaps

Model inventories and approval workflows are necessary. They establish which models exist and who authorized their use, and they give the documentation base the guidance describes. But they record a decision made before deployment. They say nothing about a specific call made on a specific day.

Pre-deployment validation has the same boundary. It assesses a model under test conditions. Ongoing monitoring is expected as well, and the guidance describes procedures for responding to issues before and after a model is approved. Recognized AI practice, such as NIST AI RMF MEASURE 2.4, also calls for monitoring functionality and behavior in production. Monitoring tells you what happened. It is not the same as a control that decides whether the action proceeds.

After-the-fact log review is the most common substitute. Logs can show that a prohibited action occurred, which is useful, but the review happens once the data has moved or the tool has acted. Logs also tend to record events rather than policy decisions, so they may not show which limit applied or why a call was permitted. Whether a bank can satisfy an examiner with these controls alone is a judgment each bank must make. Framed as an evidence question, the gap is clear: these controls document intent and observe outcomes, but they do not show enforcement at the moment of execution.

Exceptions deserve separate attention. If a human approves a call that policy would otherwise stop, that approval is an exception to track. It should be reconcilable with the inventory and approval record.

Criteria for evaluating a runtime control

These criteria are evaluation questions for a bank's own selection process. They are not regulatory requirements. Start by converting each use limit in the model risk policy into a testable condition, such as a permitted tool, data class or action. A limit that cannot be expressed as a condition cannot be enforced at runtime.

• Execution path: does the control evaluate policy before a call proceeds, or only record it afterward?
• Coverage: does it extend to models, agents, tools and MCP servers, so limits do not depend on which path a request takes?
• Decision range: can it allow, redact, block, rate limit and escalate for human approval, and record each outcome?
• Per-call evidence: can it produce the policy and version applied, the decision and the outcome for a given interaction?
• Deployment and data location: can it run self-managed in the bank's own cloud, with data residency controls?
• Retention and integrity: is retention configurable to the bank's own schedule, and is the record protected against alteration?

How Trussed applies runtime enforcement

Trussed is runtime control and evidence infrastructure for consequential AI. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with decisions to allow, redact, block, rate limit or escalate for human approval. Scope is individual interactions and tool calls. Limits are enforced at runtime, not reviewed after the fact.

That enforcement generates continuous audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency. It does not provide transaction-level governance or end-to-end tracing of agentic workflows.

On proof, Trussed has run 18+ months in continuous production in a regulated enterprise, with 99.95% uptime on live production traffic, 100+ models under one policy plane and 30+ GB of audit evidence generated per day. Customers span four regulated verticals: insurance, pharma, healthcare and education, and insurance is where Trussed is deepest. Certifications and attestations include SOC 2 Type II, HIPAA, GDPR, FERPA, ISO 27001 and NIST AI RMF. Trussed does not claim bank deployments. Banks should test any control against the criteria above.