SR 26-2 AI Model Risk Banking 2026: Federal Reserve OCC FDIC Joint Guidance, SR 11-7 Superseded After 15 Years, and the Agentic AI Governance Gap

The headline is what the guidance doesn't cover, not what it adds

Reports indicate the Federal Reserve, OCC, and FDIC jointly issued an update to US bank model risk management guidance in 2026 — the first substantive revision to SR 11-7 in roughly fifteen years — and that it explicitly places generative and agentic AI outside its scope, describing them as "novel and rapidly evolving." If accurate, that's the detail that matters most to a US-exposed institution: not what the update adds to model inventory and validation practice, but the live gap it leaves around exactly the AI deployments growing fastest in production right now.

So what: don't treat "generative and agentic AI are out of scope" as regulatory permission to under-govern them. It means examiners will apply judgment in the absence of formal guidance, and judgment-based examination is harder to prepare for than a numbered rule, not easier.

SR 11-7's core disciplines are the baseline every successor framework will keep

SR 11-7's enduring contribution — model inventories, independent validation, ongoing monitoring, third-party model governance — became the de facto global standard, adopted in substance by regulators from the RBI to the MAS. Whatever formally succeeds it, expect those four disciplines to survive largely intact, extended to explicitly cover ML/AI model definitions, strengthened third-party AI due diligence, and validation testing for distributional shift and fairness metrics that SR 11-7's original 2011 text never anticipated.

So what: build your AI model inventory and validation program around these four disciplines now, regardless of exactly how the formal successor guidance lands. They're not going away; they're being extended.

Why agentic AI breaks the traditional validation model, independent of which guidance eventually covers it

Traditional model validation assumes one model, one output, one thing to check for accuracy. An agent doesn't work that way — it's a sequence of decisions, tool calls, and intermediate outputs that collectively produce an outcome, and there's no single point in that sequence that traditional validation methodology was built to inspect. That's a structural problem with the validation methodology itself, not a gap that any specific numbered guidance document will close by definition alone.

Banks aren't waiting for the gap to close. Loan origination agents, compliance-review agents, treasury-management agents, and customer-service agents are already running in production at major US institutions, ahead of any framework purpose-built to govern them — which means examiner judgment, not a settled rule, is what's actually being applied to these systems today.

So what: document your own approach to applying existing model-validation principles to agentic AI now, explicitly, with dated evidence. An examiner evaluating a bank that can show a principled, pre-existing approach treats that very differently from a bank improvising an answer in the exam room.

Building an agentic AI model inventory that actually reflects how agents work

A traditional inventory entry is one model, one line. An agent typically needs several: the orchestration layer itself, each tool or API it calls that carries a consequential sub-decision — a credit check, a sanctions screen, a document classifier — and the final output-generation model. Each entry should additionally document the agent's authorization scope, its tool-access catalogue, its escalation triggers, and whether it persists state across sessions, since state persistence creates its own governance question about what carries over between interactions.

Validating an agent means testing whether it can be manipulated into exceeding its own scope

Agentic validation needs three tests traditional model validation doesn't: adversarial testing of whether prompt injection, goal hijacking, or context manipulation can push the agent into acquiring capabilities or permissions beyond what it was authorised for; multi-step decision-integrity testing, checking whether intermediate decision quality degrades across a sequence of steps even when the final output looks fine; and human-escalation trigger testing, measuring both false-escalation rates (operational burden from over-escalation) and missed-escalation rates (governance risk from under-escalation). Any silent update to the underlying LLM from a vendor should trigger re-validation — a model that behaves differently after a vendor-side update is, functionally, a different model.

So what: if your current validation plan for an agentic system is "test the underlying LLM the way we'd test any model," you haven't validated the agent. You've validated one component of it and left the authorization-boundary and escalation-trigger risks completely untested.

Monitoring has to track the whole workflow, not just the final answer

Ongoing monitoring for agentic AI needs three dimensions traditional monitoring doesn't capture: task completion quality against a human-review sample, continuous authorization-adherence monitoring that logs any action exceeding the agent's defined scope as an MRM incident in its own right, and escalation-pattern monitoring, where a sudden rate increase may signal degradation and a sudden decrease may signal the agent is quietly missing cases it should be escalating.

Third-party agentic AI concentration is a risk every bank running on a handful of LLM providers already carries

Banks building agentic AI on hyperscaler or LLM-provider platforms need model-update notification commitments, architecture documentation sufficient to assess authorization risk, and an explicit concentration-risk assessment — most large financial institutions now depend on a small number of foundation-model providers for the bulk of their LLM API usage. An outage or policy change at one of those providers would hit every dependent bank at once if no fallback architecture exists.

So what: ask your LLM vendor, in writing, what notice you get before a model update that could change your agent's behaviour, and whether you have a tested fallback if that provider becomes unavailable. If the answer to either question is "we haven't discussed it," that's your next governance gap to close.

A four-point action checklist

1. Build (or extend) your model inventory to cover agentic systems as multi-entry records — orchestration layer, each consequential tool call, and the output model — not a single line item.
2. Add adversarial authorization-boundary testing and escalation-trigger testing to every agentic AI validation plan, not just output-accuracy testing.
3. Log every agent action that exceeds its defined authorization scope as its own MRM incident, with monitoring that tracks escalation-rate drift over time.
4. Get concentration-risk and model-update-notification commitments from every LLM/agentic-platform vendor in writing, and test your fallback plan at least once a year.