SR 11-7 gave banking's model risk discipline its structure. Here's how to adapt its tiering logic — autonomy × blast radius — to govern AI agents before your regulators ask you to.
In banking and insurance, model risk management is not optional. SR 11-7, the Federal Reserve's 2011 guidance on model risk management, established the principle that every model — however simple — requires documentation of its intended use, a named owner, and a process for independent review. The discipline has been refined over fifteen years and is now deeply embedded in how US banks govern their analytical systems. Yet nearly every financial institution running AI agent pilots today is operating outside this discipline entirely.
The reason is structural. When an AI agent pilot launches, it typically sits in a space that doesn't neatly fit any existing governance category. InfoSec owns the credential management and vulnerability scanning. Model Risk owns the validation of the underlying foundation model. Product owns the use-case definition and output quality. None of them owns the intersection: the agent's tool access, its escalation thresholds, its documentation, or its ongoing behavioral monitoring. This is not a people problem; it is an organizational design problem that SR 11-7 — adapted for agentic systems — can solve.
This post explains how to adapt SR 11-7's framework, OSFI Guideline E-23, and the NIST AI RMF to create a practical agent risk tiering program. We include the 2-axis tiering grid, a RACI template for the Agent Risk Owner role, and guidance on what OSFI E-23 and SR 11-7's "effective challenge" requirement means in the context of agents that can invoke production APIs.
SR 11-7 defines a model as "a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates." AI agents — particularly those built on foundation models — have characteristics that this definition was not designed to address.
Traditional models have static inputs and outputs. An agent has dynamic tool access that changes its effective capabilities. A credit scoring model processes a defined set of variables and returns a score; an agent processing customer refunds can query order systems, write to payment APIs, send emails, create support tickets, and schedule callbacks. Each additional tool is effectively a new capability that changes the model's risk profile — but changing an agent's tool access doesn't trigger a model risk review under existing frameworks because the "model" (the foundation model) hasn't changed.
SR 11-7 is the Federal Reserve's April 2011 supervisory letter establishing model risk management requirements for federally regulated banks. It requires model inventory maintenance, tiering by materiality and complexity, independent model validation ("effective challenge"), documented ongoing monitoring, and accountability structures with named model owners. While written before the AI era, its principles map directly to agent risk governance. The OCC's similar guidance (OCC 2011-12) applies the same framework to national banks.
The second gap is autonomy. Traditional models provide outputs that humans act upon — a credit decision, a fraud probability, a risk rating. Agents act autonomously. The model risk validation process for a credit scoring model evaluates whether the model's outputs are accurate and well-calibrated. The equivalent for an agent must also evaluate whether the agent's autonomous actions are appropriate given its operational context — a category of assessment that existing MRM frameworks have no methodology for.
SR 11-7 requires that model risk management include "effective challenge of models in a manner that is meaningful and consequential." Effective challenge is defined as critical analysis by qualified staff who are independent of model development and who have both the incentives and capabilities to question the model's conceptual soundness, assumptions, and output quality. For traditional models, this typically means a model validation team reviewing the statistical methodology, data quality, and out-of-sample performance.
For agentic AI, effective challenge must address three additional dimensions that traditional MRM does not cover. First: tool access review. An independent reviewer must assess whether each tool in the agent's allowlist is necessary for its intended purpose, whether the permissions within each tool are appropriately scoped, and whether the combination of tools creates risk concentrations not visible when tools are reviewed individually. Second: autonomy threshold review. An independent reviewer must assess whether the agent's escalation thresholds are set appropriately for the risk context — $50 auto-execute may be appropriate for a low-stakes customer service agent and completely inappropriate for a treasury management agent. Third: behavioral monitoring design. The reviewer must assess whether the ongoing monitoring plan would detect behavioral drift, tool misuse, or prompt injection attempts in production.
OSFI Guideline E-23, updated by Canada's Office of the Superintendent of Financial Institutions in September 2023, requires federally regulated financial institutions to manage technology and cyber risk through a documented framework that addresses AI-related risks. For agentic AI, OSFI E-23 creates obligations around system accountability (a named individual responsible for each AI system), risk assessment (explicit identification and documentation of risks), and ongoing monitoring. OSFI's AI and model risk guidance is increasingly interpreted as requiring the same governance rigor for high-impact AI agents as for traditional credit and operational models.
The tiering grid places agents on two axes: autonomy (the degree to which the agent acts without human confirmation) and blast radius (the scope of systems, data, and operations the agent can affect). This produces four quadrant cells that map to governance requirements.
Tier 1 — Low Autonomy, Low Blast Radius — describes agents that either require human approval for most actions or have access only to low-risk systems. A research assistant that drafts reports for human review, with read-only access to internal databases, is a Tier 1 agent. Standard controls apply: documentation, a named owner, periodic review. No board sign-off required; this is the baseline everyone should already be doing.
Tier 2 — either Low Autonomy with High Blast Radius, or High Autonomy with Low Blast Radius — describes agents that have either broad access managed by human oversight, or limited access but significant autonomy within that scope. A Tier 2 agent requires a formal risk assessment before production, a defined escalation path, and a named Agent Risk Owner who is responsible for ongoing monitoring. SR 11-7 would classify this as a "high" materiality model requiring structured validation.
Tier 3 — High Autonomy, High Blast Radius — describes agents that operate largely autonomously with access to systems whose modification or misuse could cause significant operational, financial, or reputational harm. An agent that autonomously executes payments, modifies customer records, or makes credit decisions is Tier 3 regardless of how well-designed it appears. Tier 3 requires board-level sign-off before production deployment, a named Agent Risk Owner with direct board reporting accountability, continuous real-time monitoring, and a pre-defined incident response plan.
The Agent Risk Owner is the named individual accountable for a specific agent's governance posture, performance against defined KPIs, and risk profile. This role is the direct adaptation of SR 11-7's model owner requirement. The Agent Risk Owner is not the developer who built the agent, not the vendor who supplied the underlying model, and not the compliance officer who signed off on the use case. It is the person who will be asked about this agent's behavior if it causes an incident and who has the authority to modify or disable it if needed.
In practice, the Agent Risk Owner for a Tier 1 or Tier 2 agent is typically a senior product manager or business-side domain expert — someone who understands the operational context well enough to assess whether the agent is behaving appropriately. For Tier 3 agents, the Agent Risk Owner should sit at the VP or equivalent level, with a dotted-line reporting relationship to the Chief Risk Officer. The CRO needs line of sight to Tier 3 agents because they represent the class of AI system most likely to generate regulatory inquiry or operational incident.
The NIST AI Risk Management Framework, published in January 2023, provides a voluntary governance structure for AI risk organized across four functions: Govern (establishing accountability structures, policies, and culture), Map (identifying and classifying AI risks), Measure (analyzing and assessing risks), and Manage (prioritizing, responding to, and monitoring risks). The Govern function's requirements for accountability, transparency, and organizational processes map directly to what agent tiering programs provide. NIST has released supplementary guidance specifically addressing agentic AI systems in its 2025 AI RMF profile updates.
The RACI for agent governance should establish: the Agent Risk Owner as accountable for ongoing governance (A), the development team as responsible for technical configuration (R), the Model Risk or AI Governance function as consulted on risk assessment methodology (C), and the Board or Audit Committee as informed for Tier 3 agents (I). This RACI makes the ownership gap structural rather than accidental — it assigns the intersection that currently falls between functions to a named individual with defined accountability.
The NIST AI RMF's four functions provide a cycle for agent risk management that complements the static tiering classification. Govern establishes the tiering framework itself, the Agent Risk Owner accountability structure, and the board-level reporting requirements for Tier 3 agents. Map is the exercise of classifying each agent on the autonomy × blast radius grid, documenting its tool access inventory, and identifying the specific risks associated with its operational context. Measure is the ongoing assessment of whether the agent's risk profile has changed — for example, whether adding a new tool has moved a Tier 1 agent to Tier 2 — and whether the monitoring controls are detecting behavioral drift. Manage is the treatment of identified risks: adjusting escalation thresholds, revoking tool access, requiring additional validation, or escalating to the Agent Risk Owner or board.
Tool access is the new risk dimension that traditional model validation frameworks were not designed to address. When a bank validates a credit scoring model, the risk profile is a function of the model's inputs, outputs, and the human decision processes that use those outputs. When a bank deploys an AI agent, the risk profile is a function of all of the above plus the set of external systems the agent can invoke directly — APIs, databases, communication channels, financial systems, and any other capability exposed as a tool.
This creates a challenge for existing governance processes: an agent's tool access can change without any change to the underlying model. Adding a new tool to an agent's allowlist changes its risk profile immediately, but it doesn't trigger a model revalidation under current MRM frameworks because the model itself hasn't changed. Agent governance programs must therefore track tool access changes as a separate event type that can trigger a re-tiering review — the same process that would be triggered by a material change to a traditional model's methodology.
The practical implication is that agent governance requires a tool access inventory that is kept current and reviewed whenever the inventory changes. Each entry in the inventory should document: the tool name, the permission scope within the tool, the business justification for access, the last review date, and the name of the Agent Risk Owner who authorized the access.
AgentTrust OS implements the agent risk tiering framework across the full governance lifecycle — classification, runtime tier enforcement, and ongoing audit reporting for regulators and boards.