Skip to main content
Promotional banner for the pentest readiness checklist
Where Should Your LLM Agent Live Under SR 26-2?Compliance & Audit
5 min readFor AI Governance Leaders

Where Should Your LLM Agent Live Under SR 26-2?

Footnote 3 of SR 26-2 states that generative and agentic AI "are not within the scope of this guidance." It also advises banks to use their own "risk management and governance practices" to determine appropriate governance and controls. This means you must decide which program will manage these systems and how stringent the controls should be.

The Decision You Are Facing

For each generative or agentic AI system in your inventory, you need to decide where it's governed and how rigorously. If left unanswered, this creates a gap: the Model Risk Management (MRM) team might say it's out of scope, while the AI governance team assumes MRM is handling it.

Consider a scenario where a customer-service agent passes a pre-launch review but continues to operate after the foundation-model provider updates it. If no one is responsible for ongoing review, issues like quoting a retired waiver rule might go unnoticed. The path you choose determines who would have caught such errors.

Key Factors That Affect Your Choice

Evaluate each system with these questions before deciding on a path.

1. Is it actually generative or agentic? SR 26-2 applies to "traditional statistical and quantitative models and non-generative, non-agentic AI models." A gradient-boosted credit model remains in scope and needs effective challenge, while a foundation-model agent does not.

2. Does the bank fall under the guidance at all? The guidance is "expected to be most relevant" to organizations with over $30 billion in total assets. The FDIC states it generally doesn't apply to smaller institutions unless there's significant model risk exposure. Smaller banks still need internal practices suited to their size.

3. What is the materiality? The guidance notes that "Model purpose, together with model exposure, determines model materiality." Purpose is the system's function; exposure is how much its output influences decisions. A summarization tool for internal memos and a customer-facing agent quoting fees have different materiality levels.

4. Is it a vendor system? Section VII states model risk management principles "remain applicable" even without access to vendor code, data, or methodology. A foundation-model API is outside the guidance's scope, but understanding its design and performance, validating it, and ongoing monitoring are essential.

Path A: Extend Your MRM Framework Voluntarily

Choose this if your MRM function is mature, your validators can assess non-deterministic systems, and the system's materiality is high (customer-facing, fee or credit related, or supporting a regulatory requirement).

What it looks like: Apply the lifecycle structure (development and use, validation, governance, and inventory) to the LLM system, scaled by materiality. SR 26-2 emphasizes that the quality of validation depends on "the rigor and effectiveness of the review rather than on organizational structure," so your existing validators can qualify if they can effectively challenge the system.

What drives it: Lifecycle sections IV through VII and vendor expectations in Section VII provide a familiar template.

Watch for: Pre-use validation alone is insufficient. SR 26-2 states validation "generally occurs prior to a model's first use," but timing varies with model changes. For systems that change behavior with provider updates, these updates must trigger revalidation. For example, Chen et al. measured GPT-4's accuracy on a prime-number task dropping from 84.0% to 51.1% between March and June 2023. A one-time review can't catch such changes.

Path B: Govern Under a Separate AI Governance Program

Choose this if your AI governance function already manages intake, risk tiering, and monitoring for AI systems, and MRM validators lack tools for prompt-level and tool-call behavior.

What it looks like: The AI governance program manages these systems end to end, providing the controls MRM would otherwise supply:

  • Inventory: Registry entries with owner, lifecycle status, and model version. Revoke a retired agent's tool credentials.
  • Ongoing monitoring: Track drift (same prompts, changed answers after a provider update) and hallucination (a fee or policy the retrieved context doesn't support). Record which tool the agent called, with what arguments, and whether that matched policy. Log system-prompt versions and retrieved documents. Tie each signal to a threshold that triggers an alert or enforcement rule.
  • Inline enforcement: Check requests before they reach the model for PII/PHI and prompt-injection attempts. Score responses for groundedness before they reach the customer. Start with deterministic rules; add model-based scoring where a rule can't assess the behavior.
  • Audit trail: Retain who triggered each enforcement decision and which policy applied, so you can reconstruct what the agent did on a given date for an examiner or a complaint.

Watch for: The boundary. Your MRM policy and AI governance policy need a written statement of which systems each covers and who signs off when a system moves between them.

Path C: Hybrid, with MRM as the Challenge Function

Choose this if you want AI governance to manage operations while MRM provides independent challenge on the highest-materiality systems.

What it looks like: AI governance handles intake, monitoring, and enforcement. MRM reviews only systems above a materiality threshold defined by purpose and exposure. The guidance prescribes no tier names, so document your purpose-and-exposure rationale in writing.

Watch for: Two programs can mean two inventories. Keep one registry with a field showing which program owns each entry.

What to Expect from Regulators

OCC Bulletin 2026-13 states that agencies "plan to issue in the near future a request for information" on MRM and banks' use of AI, including generative and agentic AI. Until then, footnote 3 is the operative text. Federal Reserve Vice Chair for Supervision Bowman noted that banks are "relying on existing risk-management frameworks to guide their use of AI." The guidance doesn't set enforceable standards, but a footnote preserves supervisory action for "violations of law or unsafe or unsound practices stemming from insufficient management of model risk." Out of scope doesn't mean unexamined.

Summary Matrix

Factor Path A: Extend MRM Path B: Separate AI Governance Path C: Hybrid
Best fit Mature MRM, high-materiality systems Mature AI governance, limited MRM tooling Both functions mature
Owner of monitoring MRM AI governance AI governance
Independent challenge MRM validators Within AI governance MRM above materiality threshold
Key driver Lifecycle sections IV-VII; Section VII vendor expectations Footnote 3 handoff to bank practices Section III materiality: purpose plus exposure
Main risk Pre-use validation misses provider updates Boundary with MRM left undefined Duplicate inventories
Required artifact Revalidation triggers tied to provider changes Written boundary and sign-off rule Single registry with ownership field

Whichever path you take, document the choice, the rationale, and the owner. Under footnote 3, that record is your evidence that the decision was made deliberately.

Promotional banner for the Penetration Report Template Kit

You Might Also Like