Back to Blog
AI Governance

Agent Risk Tiering: Adapting Model Risk Management for Agentic AI

SR 11-7's tiering logic — autonomy × blast radius — adapted for AI agents before your regulators ask

Regulators are applying SR 11-7 model risk management principles to AI agents now. The 2-axis tiering grid (autonomy × blast radius) classifies your current pilots in one session — before your examiners ask.

July 28, 202613 min read
AI GovernanceModel Risk ManagementSR 11-7OSFI E-23Financial ServicesNIST AI RMF
AgentTrustOSAGENTIC AI GOVERNANCEGOVERNANCE · MODEL RISKAgent Risk Tiering:Adapting Model RiskManagement for Agentic AIAGENT RISK TIERING MATRIXAUTONOMYBLAST RADIUST2ElevatedT3Board Sign-offT1Standard MRMT2Enhanced ReviewSources: SR 11-7 · OSFI Guideline E-23 · NIST AI RMF 2.0 · Basel Committee AI Principlesagent-trust.tech
Agent risk tiering matrix: place each agent on the autonomy × blast radius grid to determine governance requirements
AI Governance · Model Risk Management · Banking
Key Facts
  • According to the Federal Reserve's SR 11-7 (April 2011), still the primary MRM guidance, every model requires a designated owner, documented tiering by materiality and complexity, and "effective challenge" by an independent party separate from model development.
  • Per OSFI Guideline E-23 (September 2023, updated for AI), Canadian federally regulated financial institutions must maintain a model risk management framework that explicitly addresses AI and ML systems, including agent-based applications with autonomous decision-making capability.
  • The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) organizes AI risk governance across four functions: Govern (policies and accountability), Map (risk identification), Measure (risk assessment), and Manage (risk treatment and monitoring).
  • Agent risk tiering on two axes — autonomy (how independently the agent acts) and blast radius (the scope of potential impact) — maps directly to SR 11-7's materiality-based tiering approach, adapted for the unique characteristics of agentic systems.
  • Tool access — the set of external systems and APIs an agent can invoke — is the defining risk dimension for agentic AI that traditional model validation frameworks were not designed to address. An agent's risk profile changes whenever its tool access changes, even if the underlying model does not.
  • The "Agent Risk Owner" role — a named individual accountable for a specific agent's governance, performance, and risk profile — is the direct adaptation of SR 11-7's model owner requirement to agentic systems.
TL;DR
  • Agent risk ownership gaps — risk falling between InfoSec, Model Risk, and Product — are the primary governance failure mode in enterprise AI programs today.
  • SR 11-7's three requirements (named owner, effective challenge, tiering by impact) map directly to agent governance with one addition: tool access as the new risk dimension.
  • The 2-axis tiering grid (autonomy × blast radius) produces four cells: Tier 1 (sandbox OK), Tier 2 (review required), Tier 3 (board approval), plus a monitoring-only cell.
  • OSFI Guideline E-23 and the NIST AI RMF Govern/Map/Measure/Manage cycle both require documented risk classification, accountability structures, and ongoing monitoring.
  • You likely have Tier 3 agents in production without knowing it — classifying your current pilots takes one working session with the right framework.
Keep reading → The 2-axis tiering grid and RACI template below.

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.

Why doesn't existing model risk management cover AI agents?

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.

Definition — SR 11-7 (Federal Reserve Supervisory Guidance on Model Risk Management)

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.

What does SR 11-7 "effective challenge" mean for agentic AI?

SR 11-7 requires that model risk management include "effective challenge of models in a manner that is meaningful and consequential." 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. First: tool access review — an independent reviewer must assess whether each tool in the agent's allowlist is necessary for its intended purpose and whether the permissions within each tool are appropriately scoped. Second: autonomy threshold review — whether the agent's escalation thresholds are set appropriately for the risk context. Third: behavioral monitoring design — whether the ongoing monitoring plan would detect behavioral drift, tool misuse, or prompt injection attempts in production.

Definition — OSFI Guideline E-23 (Technology and Cyber Risk Management)

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.

How does the 2-axis tiering grid work?

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: Agents that either require human approval for most actions or have access only to low-risk systems. Standard controls apply: documentation, a named owner, periodic review. No board sign-off required.

Tier 2 — either Low Autonomy with High Blast Radius, or High Autonomy with Low Blast Radius: Agents that have either broad access managed by human oversight, or limited access but significant autonomy within that scope. Requires a formal risk assessment before production, a defined escalation path, and a named Agent Risk Owner.

Tier 3 — High Autonomy, High Blast Radius: 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.

15yr
SR 11-7 has governed model risk in US banking since 2011 — now being adapted for agents
Federal Reserve, SR 11-7 (April 2011)
3
Functions that each claim partial ownership of agent risk: InfoSec, Model Risk, Product
AgentTrust OS governance assessment, 2026
0
Enterprises with a formal Agent Risk Owner role at the start of their agent program
AgentTrust OS customer analysis, 2026

Who should own agent risk in a financial institution?

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.

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 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).

Definition — NIST AI Risk Management Framework (AI RMF 1.0)

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). NIST has released supplementary guidance specifically addressing agentic AI systems in its 2025 AI RMF profile updates.

How does NIST AI RMF map to agent risk tiering?

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. 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.

Agent Risk Tiering Matrix — Autonomy × Blast RadiusAUTONOMY (agent independence)HIGHLOWBLAST RADIUS (potential impact scope)LOWHIGHT2TIER 2High autonomy · Limited blast⚠ Review RequiredNamed reviewer · SR 11-7 §§T3TIER 3High autonomy · High blastBoard ApprovalAgent Risk Owner · CRO sign-offT1TIER 1Low autonomy · Low blast✓ Sandbox OKStandard controls · NIST MapT2TIER 2Low autonomy · High blast⚠ HITL RequiredHuman-in-loop forconsequential actions
Figure 1: Agent Risk Tiering Matrix — Autonomy × Blast Radius. Place each agent pilot in one of the four quadrants to determine governance requirements. Tier 3 (top-right) requires board-level sign-off and a named Agent Risk Owner with CRO reporting line.

What does tool access mean as a risk dimension for agent governance?

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 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: The Governance Platform for Agent Risk Tiering

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.

Trust Certify
Pre-production tier classification: evaluates each agent's autonomy profile and tool access inventory to assign a Tier 1/2/3 classification, with SR 11-7-aligned effective challenge documentation and certification artifacts for regulatory review.
Trust Audit
Ongoing governance reporting: generates board-level and regulator-ready reports on agent tier status, tool access changes, Agent Risk Owner accountability, and OSFI E-23 / NIST AI RMF compliance status.
Trust Runtime
Tier-based enforcement: applies different escalation thresholds and tool allowlists based on each agent's tier classification, automatically enforcing governance policy at runtime without manual configuration for each agent.

Frequently Asked Questions

Ready to Govern Your Agents?

Classify Your Pilots. Own the Risk.

AgentTrust OS implements SR 11-7-aligned tiering across certification, runtime enforcement, and board-ready audit reporting.

Start Free →

More from the blog

AI ComplianceJuly 22, 2026AI ComplianceJuly 22, 2026AI GovernanceJuly 22, 2026AI GovernanceJuly 22, 2026AI ArchitectureJuly 22, 2026AI SecurityJuly 16, 2026MLOpsJuly 10, 2026AI ImplementationJuly 8, 2026AI Agent ArchitectureJuly 5, 2026AI Agent ArchitectureJune 30, 2026EngineeringJune 23, 2026AI Agent ArchitectureJuly 2, 2026AI Agent ArchitectureJuly 1, 2026IntegrationsJuly 1, 2026IntegrationsJuly 1, 2026IntegrationsJuly 2, 2026AI SecurityJuly 3, 2026AI SecurityJuly 1, 2026AI ComplianceJuly 2, 2026AI ComplianceJuly 3, 2026AI StrategyJuly 2, 2026AI StrategyJuly 3, 2026AI StrategyJuly 3, 2026AI StrategyJuly 3, 2026Healthcare AIJuly 28, 2026ArchitectureJuly 29, 2026ArchitectureJuly 29, 2026AI StrategyJuly 29, 2026AI StrategyJuly 30, 2026AI SecurityJuly 30, 2026AI ComplianceJuly 30, 2026EngineeringJuly 30, 2026AI GovernanceAugust 4, 2026EngineeringAugust 4, 2026EngineeringAugust 4, 2026