AI Agent Inventory for Banks: Keeping It Current Under Revised Model Risk Guidance

What changed in model risk guidance

Many bank teams still frame agent inventories around SR 11-7. That guidance, issued in April 2011, expects an inventory of models in use, under development, or recently retired, with comprehensive information on each. It also expects a specific party to maintain a firm-wide inventory even when business lines keep their own, and it expects each model to be reviewed at least annually.

As of November 2026, the picture has moved. The OCC issued Bulletin 2026-13, Model Risk Management: Revised Guidance, on April 17, 2026. It covers model development and use, validation and monitoring, governance and controls, and vendor and third-party products. The Federal Reserve has also issued revised guidance. Its text applies its principles to traditional statistical and quantitative models and to non-generative, non-agentic AI models, while the OCC describes generative and agentic AI as novel and rapidly evolving.

The inventory concept carries forward. An effective inventory includes enough information to understand model risks individually and in aggregate, and the level of detail may vary. Because the treatment of agents under the revised text is a question for your legal and model risk teams, design the inventory so it holds up under either reading: it should state what each agent can do, not only that the agent exists.

Why point-in-time inventories drift

An inventory built from periodic attestations and spreadsheets is accurate on the day it is signed. An agent that gains a tool, an MCP server, or a permission each sprint can move away from that record within days. The documented inventory describes intended scope, while the agent's real scope is whatever it can call.

This is more than a documentation lag. NIST's agent authorization work asks how data sensitivity should be assessed when an agent gains new tools and aggregates data, and how least privilege can be set when an agent's required actions may not be predictable at deployment. NIST also notes that drift and privilege-escalation risk increases for agents that act across a wide variety of tools. A new read tool and a new write tool can change an agent's risk profile even though the agent's purpose is unchanged.

An annual or quarterly attestation cannot catch that. The practical fix is to stop treating the inventory as a document refreshed on a schedule. Update it when a tool-level change occurs, and verify it against observed behavior.

Inventory attributes that matter at the agent and tool level

Examiner review needs enough information to understand each agent's risk, its purpose, its expected use, and its restrictions. A Federal Reserve OIG report on inventories makes the same point about purpose, use, and restrictions. For agents, those fields have to be supplemented with tool-level detail, because tool access is what changes between releases. The list below is a design proposal, not a regulatory template, and you should scale the depth to the agent's risk.

Record the agent-level attributes once and version them. Record tool-level attributes per tool and per agent, since the same tool may carry different permissions for different agents. Keep a history of every change so a reviewer can see what was permitted on any given date.

• Owner and purpose: A named accountable owner, the agent's intended use, and stated restrictions.
• Permitted tools and MCP servers: Each tool or server the agent may call, with the permission scope granted.
• Data access: Data the agent can reach through each tool, and any sensitivity change from combining tools.
• Autonomy level: Whether the agent acts on its own, proposes actions, or requires confirmation.
• Human approval requirements: Which tools or actions need approval before they execute.
• Change history: Dated record of tool, permission, and configuration changes, including roll-backs.