SR 11-7 meets agentic AI: model risk management for AI agents in banking

For more than a decade, model risk management at US banks has been shaped by one document: SR 11-7, the Federal Reserve’s Supervisory Guidance on Model Risk Management, issued in April 2011. The OCC issued the same guidance in substance as Bulletin 2011-12, and the FDIC adopted it in 2017. Most banks have built their model risk policies, inventories and validation teams around it.

Generative AI and AI agents now test that framework in ways its authors could not have anticipated. The good news is that SR 11-7 was written in principles, not rules, and much of it applies well. The challenge is knowing where it stretches and where it stops.

What SR 11-7 asks of banks

SR 11-7 rests on three pillars:

• Sound development, implementation and use. Models should have a clear purpose, sound design, appropriate data and documented limitations, and should be used as intended.
• Validation with effective challenge. Models should be reviewed by people who are independent of development and have the competence and influence to question assumptions and results.
• Governance, policies and controls. Boards and senior management set policies, define roles and responsibilities, and maintain an inventory of models in use.

The guidance also defines a model broadly, as a quantitative method that turns input data into estimates, and makes clear that model risk comes both from errors in the model and from using a model incorrectly. That breadth is what makes it relevant to AI today.

What counts as a model, and how to tier it

A traditional credit scorecard is easy to identify as a model. An AI agent is harder. It typically combines a large language model, a set of prompts and instructions, retrieval from internal documents, tools that call other systems, and business rules that decide what happens next.

We recommend banks answer the question in layers rather than all at once:

• The foundation model. The underlying LLM is usually a third-party component. It belongs in the inventory, even if the bank cannot inspect how it was built.
• The configured application. The prompts, retrieval sources, parameters and guardrails that turn a general model into a specific use case. This is where most bank-specific risk is created, and it is what validators should focus on.
• The agent’s actions. The tools and system permissions that let the application change records or trigger processes. As we discuss below, this layer needs controls that SR 11-7 was not designed to supply.

Some banks will treat certain generative AI uses as “tools” or “non-models” rather than models. That can be reasonable for low-risk use, but the decision should be documented, consistent and subject to the same challenge as any other classification. Undocumented exclusions are a common finding in reviews.

Once AI uses are identified, they need tiering. Most banks already tier models by materiality, so that validation depth matches risk. The same logic should apply to AI, but the tiering criteria need updating. A generative AI use that drafts internal meeting notes and one that answers customer questions about fees may use the same underlying model and carry very different risk.

Useful tiering factors for AI and agents include:

• whether outputs reach customers or affect customer outcomes;
• whether the system can take actions or only makes recommendations;
• the financial, conduct and compliance impact of an error;
• the degree of human review before outputs are relied on;
• the sensitivity of the data it can access.

An agent that can change records in core banking or payment systems should sit in the highest tiers almost by definition, whatever the sophistication of its model.

Validating systems that do not give the same answer twice

Traditional validation relies on replicating results, testing assumptions and benchmarking against alternatives. Large language models are non-deterministic: the same input can produce different outputs, and behavior can shift when a vendor updates the model. Validation has to adapt without abandoning effective challenge.

In practice, that means combining several techniques:

• Use-case test sets. Curated sets of realistic inputs with expected outcomes, run repeatedly to measure accuracy and consistency across many runs rather than a single one.
• Benchmarks. Comparison against a baseline, such as the existing manual process or a simpler rules-based approach, so the bank can judge whether the AI is fit for purpose.
• Red-teaming. Deliberate attempts to make the system fail, including prompt injection, attempts to extract confidential data, and inputs designed to trigger biased or harmful outputs.
• Ongoing monitoring. Because behavior can drift, validation cannot be a point-in-time exercise. Production monitoring of output quality, override rates, complaints and incidents becomes part of the validation evidence.

Validators will also need new skills. Effective challenge requires people who understand how these systems fail, not only statistical model theory.

Third-party models and vendor risk

SR 11-7 already expects banks to manage vendor models, even when the vendor will not share full details of design and data. That principle is now central, because most generative AI in banks rests on models the bank did not build and cannot fully inspect.

Banks should connect model risk management with third-party risk management so that, for each AI vendor, they understand:

• what documentation and testing evidence the vendor provides;
• how and when the vendor changes or retires models, and how the bank is notified;
• where data is processed and whether it is used to train the vendor’s models;
• what contractual rights the bank has to audit, test and exit.

Where vendor transparency is limited, the bank’s own testing and monitoring of the configured application has to carry more of the weight.

The gap: SR 11-7 validates models, not actions

This is the most important point for banks deploying agents. SR 11-7 is about whether a model’s outputs are sound and used appropriately. It does not tell a bank how to control a system that acts on its own: what it is allowed to change, who approves those changes, and how to reverse them.

A well-validated model can still cause harm if the agent around it has excessive permissions or no approval step. Closing that gap means bringing in controls from operational risk and IT general controls:

• Identity and access. Each agent has its own identity with least-privilege permissions, included in access reviews.
• Approvals. Human approval thresholds set by the risk of each action, not applied uniformly.
• Change management. Changes to prompts, tools and model versions follow controlled release processes, just as code changes do.
• Logging and audit trails. Every action is attributable, reconstructable and linked to the record it changed.
• Incident response. A tested way to suspend an agent and roll back its actions.

The practical answer is not to stretch SR 11-7 to cover everything, but to define clearly which function owns which control, so that model risk, operational risk, technology risk and the business line each know their part.

Supervisory expectations are evolving

Supervisors have made clear that existing expectations on model risk, third-party risk and operational resilience apply to AI, and those expectations continue to evolve. Banks that extend their current frameworks thoughtfully, document their reasoning and close the gap between model validation and action controls will be in a strong position whatever comes next.

This article is general information, not legal or regulatory advice.