SR 11-7 asks banks to keep a comprehensive inventory of models in use, in development and retired. For AI agents, each entry should record purpose, actual use, restrictions on what the agent may do, its inputs and their sources, its owners and validators, and how long validation holds. The hard part is keeping actual use in step with intended use.
What does SR 11-7 require of the inventory?
The interagency model risk guidance SR 11-7 expects banks to maintain a comprehensive set of information on models implemented for use, under development for implementation, or retired. In substance, the inventory should describe:
- the purpose and products for which the model is designed;
- its actual or expected usage, and any restrictions on use;
- the type and source of its inputs, and its outputs and their intended use;
- its owners, developers and validators;
- the dates of completed and planned validation work;
- the time frame over which the model is expected to remain valid.
The guidance expects vendor models and models the bank relies on through third parties to be included. The inventory supports reporting of aggregate model risk to senior management and the board. For the whole framework, see SR 11-7 model risk management for AI agents.
Who does it apply to?
Banking organisations supervised by the Federal Reserve and the OCC, with the FDIC applying the same approach. For whether agents belong in the inventory at all, see is an AI agent a model under SR 11-7; the short answer is usually yes.
How do SR 11-7's fields translate for agents?
Each field asks something more of an agent than of a traditional model.
Purpose and products. Name the process and the products: "handles balance transfer requests on consumer credit cards" rather than "customer service agent".
Actual versus expected use. This is the field agents put under most strain. A traditional model's use changes when someone decides to use it differently. An agent's use can widen without a decision: a new tool connected for convenience, a channel added, reviewers who stop reviewing. The entry should record intended use and show actual use from the agent's own records, so differences surface.
Restrictions on use. For agents, restrictions are concrete: which actions it may take, up to what amount, which ones need a person's approval, and which it may not take at all. Record them per capability, and record where they are enforced. A restriction written in the inventory but not enforced in the agent's systems is a gap.
Type and source of inputs. List the sources the agent relies on and how far each can be trusted: the core system, a verified counterparty, the customer's own statements, documents from outside. This field tells a reviewer which inputs could carry manipulation.
Outputs and intended use. Record that the agent's outputs include actions, not only text, and what each action changes.
Owners, developers and validators. Name the business owner of outcomes, the team that configures the agent, the model provider, and the validator.
Validation dates and time frame. Record when each capability was validated and when that validation lapses. For agents, also record that a change of model version, brief, source or tool ends the validity early.
What does a good agent entry look like?
Take an illustrative entry at a US bank holding company. The agent handles small business overdraft fee waiver requests. Purpose and products are specified. Intended use: reviews requests, waives fees under a set amount for customers in good standing, drafts decisions above that for an officer. Actual use for the last quarter: in line, with a small rise in the share of requests escalated. Restrictions: waivers capped, one per customer per period, no waivers on accounts flagged for review; enforced by the control layer. Inputs: account history from the core system, the customer's stated reason. Owners and validator named. Validation completed, next due, and lapses on any component change.
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Comprehensive coverage | Discovery of agents across business lines, including vendor-supplied ones | Discovery records; reconciliation to credentials issued |
| Purpose and products | Specific purpose per agent | Inventory field |
| Actual vs expected use | Intended use recorded; actual use drawn from action records | Usage reports compared to intent |
| Restrictions on use | Per-capability limits, approvals and prohibitions, with enforcement point | Restriction fields; verdict log |
| Inputs | Sources listed with trust level | Source register |
| Outputs | Actions and systems changed listed | Capability list |
| Owners and validators | Named people and model provider | Owner fields |
| Validation timing | Dates and lapse conditions per capability | Validation fields linked to reports |
| Aggregate reporting | Inventory feeds model risk reports to management and board | Reports |
A copy-ready version is in our model risk inventory entry template for an AI agent.
What will examiners ask?
- Are all agents, including vendor agents and those built by business teams, in the inventory?
- For this agent, how does actual use compare with intended use?
- Where are its restrictions enforced?
- Which inputs come from outside the bank?
- When does its validation lapse?
What does the inventory not do?
It records model risk; it does not reduce it. Restrictions have to be enforced in systems, validation has to happen, and monitoring has to run. The inventory also does not decide scope; that is a judgement the bank makes and documents. Our glossary entry on what an AI inventory is covers broader AI inventories that also include systems outside model risk. For binding rules beyond SR 11-7, see our guide to AI agent regulation mapped to controls, and for scope, does SR 11-7 apply to AI agents.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Should the language model have its own inventory entry?
Many banks record it as a vendor model linked to each agent that uses it. That makes it easy to see which agents are affected when the provider changes the model.
How do you find agents that are not in the inventory?
Reconcile the inventory with the credentials, service accounts and platform configurations that let agents act. An agent that can act must have credentials; credentials without an entry point to a missing record.
How often should agent inventory entries be updated?
Whenever a component changes, and at least as often as model risk reporting runs. Linking entries to the agent's configuration means most updates happen without manual effort.