Runtime Kill Switches for Bank AI Agents: What Model Risk Guidance Does Not Cover

What changed in model risk guidance for AI agents

The Federal Reserve issued SR 26-2, Revised Guidance on Model Risk Management, on April 17, 2026. It updates the approach in SR 11-7 and emphasizes a risk-based approach tailored to a bank's model risk profile, size and complexity. It is expected to be most relevant to banking organizations regulated by the Federal Reserve with over $30 billion in total assets.

In a May 1, 2026 speech, a Federal Reserve speaker said that, together with the OCC and FDIC, the Fed recently amended its model risk management guidance to clarify that it does not apply to generative or agentic AI. The speaker added that supervisors had expanded the scope of the previous guidance beyond its original purpose. So the gap for agents is a scope exclusion, not only a missing mechanism.

The guidance also says a bank's own risk management and governance practices should guide the governance and controls for tools, processes or systems it does not cover. Banks therefore cannot treat validation, governance and monitoring expectations from model risk management as the agent control framework. A documented agent runtime control policy, owned by the bank, is one such practice. Whether other guidance fills the space is a separate question that risk leaders should settle with their own regulatory counsel.

What a runtime kill switch is, and where it operates

Validation happens before deployment. Review happens after the fact. Neither stops an agent action that is already in progress. A runtime kill switch is the control point that does.

The term suggests one button that shuts an agent down. In practice it is better defined as policy enforced in the execution path. A full halt is the most severe outcome of that policy. Most decisions should be narrower and graduated.

There are two enforcement points. The first is the individual interaction, such as a prompt or response passing between a user, an agent and a model. The second is the tool call: an API call, a resource access or a request to an MCP server. NIST guidance on agent identity proposes that each tool invocation, API call or resource access undergo continuous runtime verification based on current state, environmental context and risk profile.

NIST CSRC material on runtime execution governance adds three requirements: bind current authority to the proposed consequence, revalidate at commit time, and record receipt or refusal evidence. The commit-time check matters because authority that was valid when an action was proposed may not be valid when it executes.

Graduated responses and the evidence each produces

The mapping below is a practical synthesis, not a regulatory taxonomy. Each response suits a different condition, and each should leave a different record. Pairing these responses with least-privilege access is the stronger design. Least privilege limits which tools, data and action authority an agent holds for a task. Runtime enforcement then verifies each call against that scope.

• Allow: Applies when the action is within granted authority and risk thresholds. Evidence: a receipt showing the policy that applied, the agent, the tool and the decision.
• Redact: Applies when the action is acceptable but the data in a request or response exceeds what the task needs. Evidence: a record of the data class removed and the rule that removed it.
• Block: Applies when the action falls outside granted authority or violates policy. Evidence: a refusal record naming the rule and the attempted action.
• Rate limit: Applies when individual calls are permitted but volume or frequency is abnormal. Evidence: counts, the threshold crossed and the throttling event.
• Escalate for human approval: Applies when an action crosses a risk threshold the bank has defined. Evidence: the request, the named approver, the decision and the outcome.

Evidence an examiner can inspect

The core question an examiner can ask is what the agent was permitted to do, how its actions were stopped or escalated, and what proves it. Evidence should show that the control was defined, enforced and exercised.

Defined means a written policy: the tools, data and action authority each agent holds, the risk thresholds that trigger escalation, and the named authorities who receive escalations. Thresholds and authorities should be owned by the bank and set according to the risk of the transactions the agents support.

Enforced means a record at each decision point. Refusals matter as much as permitted actions, because a log of only successful calls cannot show that the control ever said no. Exercised means the records show blocks, redactions and escalations actually occurring, and escalations being resolved by a named person. Monitoring that flags anomalous agent access supports this as a detection input.

Banks that use the NIST AI RMF can organize this evidence under their existing model documentation practices. If an agent depends on a vendor AI component, document any customization, consistent with the way model risk guidance treats customization of vendor models.

Where Trussed fits

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 allow, redact, block, rate limit and escalate for human approval. Its scope is individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and it generates continuous audit-ready evidence mapped to frameworks including NIST. It deploys self-managed in the customer cloud, with configurable retention and data residency.

Insurance, a regulated financial sector, is where Trussed is deepest. Its approved operating proof is general: 18+ months of continuous production in a regulated enterprise, 99.95% uptime on live production traffic, and 100+ models under one policy plane. Banks should assess it against the criteria above, as they would any other approach.