Inventorying MCP Servers and Agent Tools Alongside Models Under the Revised Model Risk Guidance

What the revised guidance says, and what is inference

On April 17, 2026, the OCC, the Federal Reserve Board and the FDIC issued revised model risk management guidance (SR 26-2, OCC Bulletin 2026-13 and an FDIC issuance). It supersedes SR 11-7 and SR 21-8. The agencies describe it as risk-based, tailored to a banking organization's model risk profile and the size and complexity of its operations. The guidance also states that it does not set forth enforceable standards, so the attributes in this guide are sound practice and not stated mandates.

Three points matter for agentic systems. First, the guidance defines a model narrowly, as a complex quantitative method, system or approach that applies statistical, economic or financial theories to process inputs. An MCP server or tool definition is unlikely to meet that definition on its own. Second, it calls generative and agentic AI models novel and rapidly evolving, and says an institution's own risk management and governance practices should guide controls for tools, processes or systems it does not cover. Third, it says an effective inventory includes enough information to understand model risk at the individual and aggregate levels, with detail varying by complexity and usage. Vendor and third-party products remain within the principles.

None of this mentions MCP servers or tools. Extending the inventory to them is an inference. The defensible position is to record your scoping rationale: why these components are inventoried, whether inside the model inventory or in a linked register, and how the choice follows from your own governance practices. Do not assume how an examiner will treat the question as of November 2026.

Attributes to capture for each MCP server and tool

Neither the guidance nor the public material in this area prescribes a schema, so the list below is a practitioner synthesis. It is built around what an examiner would need to answer: what can this component do, what does it reach, who answers for it, and has it changed. Scale the depth to risk and usage, as the guidance allows for models.

• Owner and change approver: A named accountable person for the server and for each tool, plus who approves changes to tool descriptions and schemas.
• Origin and provider: Internal, third-party or public registry. Public registries are a documented vector for rogue MCP servers, and third-party components stay within the guidance's principles.
• Exposed capabilities: What each tool can do, split into read, write and consequential actions such as moving money or changing a customer record.
• Data and systems reached: The data classes and downstream systems behind the tool, since identical calls carry different risk depending on what they touch.
• Authentication and identity: The credential and the human or service identity the tool acts under when called.
• Version and description hash: A version plus a hash of the tool description and schema, so a silent change can be detected against the approved record.

Link tools to the models and agents that call them

A list of tools is not an inventory of risk. The useful record is the relationship: for each production agent, which models it uses, which tools and MCP servers it is permitted to call, and under which identity. One public comment to the Federal Reserve argues that for AI services the useful inventory unit is the calling surface and not the contract, and that recording the identity behind each call shows where risk sits. That is a commenter's view, not agency guidance, but it fits the problem. A single model API sends public marketing copy in one application and customer records in another, and a contract-level line item shows neither.

Tool descriptions deserve particular attention. A draft NIST publication on adversarial machine learning notes that agents decide which tools to invoke based on natural-language descriptions and schemas supplied by tool providers. It also describes a rug pull, in which a server silently changes its tool descriptions after installation without new user approval. A changed description can alter agent behavior while the model itself is untouched, so a model-only change process will not catch it. Versioning the description and routing description changes through the named approver closes part of that gap.

In practice this means three linked entity types: models, agents, and tools grouped under MCP servers, with an explicit permission edge between each agent and each tool it may call. Whether these sit in the model inventory or a linked register matters less than keeping the links current and queryable in one place.

Apply risk tiering and ownership

Tier tools by the consequence of the action and the sensitivity of the data they reach, not by the model that happens to call them. A read-only lookup over public reference data and a tool that can write to a customer account belong in different tiers even if one agent uses both. A federal request for information on AI agent security lists approvals for consequential actions, data and tool restrictions, and network access permissions among the controls it asks about. These are topics the request raises, not requirements, but they are practical reference points for tier criteria, including which tiers require human approval before execution.

Tier the agent as well, using its highest-tier permitted tool as a floor. This keeps aggregate reporting honest: the guidance expects inventory information to support risk management in aggregate, and an agent holding one high-consequence tool should not be reported as low risk because most of its tools are benign.

Ownership needs the same rigor as tiering. Record a named owner for every model, agent, tool and MCP server, including third-party servers, where the owner is the internal person accountable for the vendor relationship and the approval of changes. Unowned tools are the most common source of inventory drift, because nobody is responsible for noticing that a server was added, versioned or retired.

Where the inventory ends and runtime evidence begins

An inventory is a statement of what exists and what is permitted at a point in time. It cannot show what was invoked, with which arguments, under which identity, or whether a control applied. When an examiner asks what an AI system was allowed to do and what it did, the first half is answered by the inventory and the permission links. The second half needs per-call records.

The practical test is reconciliation. Take the runtime record of tool calls over a period and compare it with the inventory. Every call should map to an inventoried tool, a permitted agent and a known version. Calls to tools that are not in the inventory, calls by agents without a permission edge, and calls against a description that no longer matches the approved hash are exceptions to investigate. Equally, tools that are inventoried but never called are candidates for removal, which reduces what the inventory must defend.

For higher tiers, the runtime record should also show the control decision that applied to each call, and where human approval was required, who approved it. Without that, the inventory remains a description of intent. Systems that do not enforce anything at call time can only report what happened afterward, so decide early whether your evidence will come from enforcement or from reconstruction.

Policy enforcement in the execution path

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Each interaction or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval, and the enforcement itself produces audit-ready evidence at the level of individual interactions and tool calls. Because the control is enforced at runtime, not reviewed after the fact, the record shows the decision that applied to the call, which is what can be reconciled against the inventory described above.

The scope is specific. Trussed does not replace the inventory, the tiering decisions or the ownership assignments, which remain the institution's responsibility. It supplies the runtime side of the comparison: what was invoked and which policy decision governed it. It is deployed self-managed in the customer cloud, with configurable retention and data residency. Trussed is not presented here as a tracer of whole agentic workflows or as a source of model lineage.