AI Model Risk Management for Financial Services Under SR 11-7 and SS1/23

What SR 11-7 and SS1/23 Actually Require

SR 11-7, issued jointly by the Federal Reserve and OCC in 2011, defines a model broadly as any quantitative method, system, or approach that processes input data into quantitative estimates. It requires model risk management across the full lifecycle: development, implementation, use, and ongoing monitoring, supported by independent validation before and during deployment. Its framework rests on three pillars: robust development and implementation, sound validation, and effective governance, policies, and controls.

SS1/23, published by the PRA in 2023, is more directly relevant to AI. It explicitly states that its principles apply to AI and machine learning models, not just traditional statistical ones. The standard sets out five principles: model identification and risk classification, governance, development and implementation, independent validation, and model use. Firms must maintain a model inventory and classify models by risk tier, which determines the intensity of validation and monitoring applied.

Both frameworks share a common structure: define the model, validate it, monitor it over time, and govern the process with clear accountability. That structure works well for models with relatively fixed input-output relationships. It is less clear how it applies to systems that make sequential decisions and act on the world between validation cycles.

The Gap: Neither Framework Was Written for Agentic Systems

Neither SR 11-7 nor SS1/23 contains explicit provisions addressing autonomous agents, tool-calling behavior, or dynamic permissioning. Both are structured around model outputs assessed at defined intervals rather than continuous runtime decision-making. This is not a drafting oversight. SR 11-7 predates modern AI/ML and agentic systems entirely. SS1/23, while naming AI and ML as in scope, was written before agentic architectures where a model calls external tools, chains multiple sub-decisions, and operates under permissions that shift based on task context became common in production financial services environments.

Traditional validation assumes you can test a model through backtesting, benchmarking, and sensitivity analysis at scheduled intervals. Agentic AI systems introduce risk between those intervals. An agent's behavior can drift, or it can invoke a tool or take an action outside its intended scope, without any change to the underlying model weights or training data. A validation cycle built around periodic output review will not catch this.

Dynamic permissioning compounds the problem. If an agent's access rights change depending on the task it is executing, a static model inventory entry does not capture that variability. Model risk classification frameworks under SS1/23 assume a fixed scope of what the model can do. Agentic systems break that assumption.

Where Traditional Frameworks Meet Agentic AI

Ongoing Monitoring and Auditability: Where the Obligation Extends Furthest

SR 11-7's ongoing monitoring requirement exists to confirm a model continues to perform as intended and that changes in products, exposures, or market conditions have not introduced new risks. This obligation does not disappear when the model in question is an AI agent. If anything, it becomes harder to satisfy, because behavioral drift in an autonomous decision sequence looks different from output drift in a static prediction model.

Audit trail expectations implicit in SR 11-7's governance pillar and SS1/23's documentation requirements presume that model decisions can be traced back to defined inputs. That assumption holds reasonably well for a model producing a single score or classification. It becomes significantly harder when an agent chains multiple tool calls or sub-decisions to arrive at an action. Institutions need runtime logging and decision-tracing capability sufficient to reconstruct an agent's action sequence, not just its final output, if they intend to support independent validation or respond to supervisory review.

This is also where governance accountability under SS1/23 becomes concrete. The standard places explicit senior management responsibility for approving model risk appetite and overseeing the model risk framework. Deploying an autonomous agent in a regulated process is a decision that falls within that accountability, and it requires the same level of informed oversight as approving a new statistical model, arguably more, given the agent's capacity for autonomous action.

Implementation Decisions Risk Teams Need to Make

Closing the gap between regulatory text and agentic AI in production requires a set of concrete decisions rather than a single policy update. Risk tiering frameworks under SS1/23 should be reassessed to determine whether agentic systems warrant a higher risk classification purely on the basis of autonomous action-taking, independent of how complex the underlying model itself is. A moderately complex model that can independently invoke tools and act on their output carries a different risk profile than a static model of similar complexity that simply produces a score.

Independent validation functions also need attention. Many validation teams were built to assess statistical model performance, not agent orchestration logic, tool permission structures, or runtime guardrails. Effective challenge, a requirement under both frameworks, means little if the reviewing team lacks the technical background to challenge how an agent's tool access is scoped or how fallback mechanisms behave under failure conditions. This typically requires bringing technology risk expertise into the validation process rather than treating it as a separate function.

Documentation and change management processes need to widen in scope as well. SR 11-7's development documentation standards need to capture tool access policies and override mechanisms, not just training data and model architecture. Change management should track updates to the tools and APIs an agent can reach, since a change in permission scope can alter risk exposure as much as a change in model weights.

Where Technical Controls Support Regulatory Obligations

The frameworks themselves do not specify technical implementation, which leaves institutions to determine what controls satisfy the governance and monitoring obligations they describe. Least-privilege access enforcement for AI agents interacting with core systems or external tools is a reasonable technical response to SR 11-7's governance and control expectations, even though the guidance does not name it directly. The same applies to runtime policy enforcement that can restrict or flag tool invocations that fall outside an agent's approved scope.

This is the layer where runtime governance platforms operate: capturing agent identity and permissions, enforcing least-privilege access at the point of tool use, logging decisions for audit purposes, and monitoring for anomalous behavior in production. Trussed AI provides runtime governance and security for enterprise AI agents, including agent permission enforcement, tool approval workflows, and audit logging designed to support the kind of decision traceability that SR 11-7 and SS1/23 imply but do not explicitly define. These capabilities do not replace a model risk management program. They provide the operational data and enforcement layer that independent validation and governance functions need to assess agent behavior rather than model output alone.