AI Component Inventory Versioning for Banks Under the 2026 Interagency MRM Guidance

What changed in the supervisory baseline

On April 17, 2026, the OCC, the Federal Reserve Board and the FDIC issued updated interagency model risk management guidance (OCC Bulletin 2026-13). It clarifies model risk management principles, sets out a risk-based approach and rescinds prior model risk management guidance and other issuances. Risk teams whose policies still cite the 2011 guidance, including SR 11-7 and OCC 2011-12, should reconcile those references with the 2026 text.

The 2026 guidance states that practices appropriate for one banking organization may be inappropriate for another, depending on risk profile and model purpose. It describes effective practices in development and use, validation and monitoring, and governance and controls, including clear policies, roles and responsibilities. As of November 2026, the agencies have said they plan a request for information on model risk management, including banks' use of generative AI, agentic AI and AI-based models.

The 2011 guidance asked for an inventory of models that describes purpose, usage and restrictions, and that may list underlying components. That is useful historical context for extending the inventory below the model level. The practical consequence is that the inventory entry for a generative AI system is only as reliable as its record of the components that determine behavior.

Three components, three inventory records

A system prompt is the instruction set that frames a model's behavior for a given application. A retrieval corpus is the body of content the system can draw on at query time, together with the processing that prepares it. A tool manifest is the declaration of which tools, functions or servers the system may call, with their parameters and permission scopes. Each can change system behavior without any change to the model, and each is routinely edited by people outside the model development team.

Define each as a distinct inventory record linked to the parent generative AI system entry, not as an attribute buried in a free-text field. NIST AI 600-1 asks that inventory entries for generative AI systems consider provenance information such as source, signatures and versioning, and record underlying foundation models, their versions and access modes. Recording the model version alongside the prompt, corpus and manifest versions means a prompt change is never assessed in isolation from a model change. The set of four versions forms the approved configuration record.

The mechanics below are practitioner design options rather than regulatory requirements.

Versioning mechanics by component

The scheme should make each component uniquely referenceable and reproducible. If a version cannot be reconstructed byte for byte, it cannot be evidenced.

• System prompt: Stable prompt ID, semantic version, SHA-256 content hash, template variables listed separately from fixed text, linked parent system and model version. Owner: the business or model owner. Restrict read access to content and history, since prompt instructions can be exposed if poorly protected.
• Retrieval corpus: Corpus ID and immutable snapshot ID, a manifest of document identifiers and hashes, plus the chunking and embedding settings used to build the index. Owner: a named content owner, separate from the system owner. Record source systems and refresh cadence.
• Tool manifest: Manifest ID, version, hash of a canonical serialization, and a diff against the prior version. Record each tool, parameter schema, permission scope and data access. Owner: the system owner, with security approval for any added write or external-facing capability.

Change approval and mapping to model risk management

Route changes to all three components through the bank's existing change management and model risk processes, tiered by risk. The 2026 guidance is explicitly risk-based, so a wording change to an internal drafting assistant's prompt need not receive the same scrutiny as a new write permission in a manifest for a customer-facing system. Define tiers by purpose, data sensitivity and the actions the system can take, and state which tiers need independent validation before release.

Each approval record should name the requester, the approver, the validator where required, the diff, the rationale, the test evidence and the resulting version. Sign or hash the approval record so it cannot be edited after the fact. This follows the logic of NIST's attention to signatures and OWASP's recommendation for signed component inventories, applied by analogy to these component types.

Assign accountable owners per component, and define who approves and who validates. NIST guidance on generative AI inventories also points to human oversight roles and known issues, which belong in each record.

Before relying on the scheme, run a reconstruction test on one production use case. Pick an interaction and ask the owning team to state the prompt version, corpus snapshot and tool permissions in force, and who approved each. Then check which edits to these components bypass change control today. Findings from this test usually set the implementation priority.

Showing the approved version was the one in use

Deployment-time review leaves a gap between the approved configuration and the configuration actually running. Closing it requires two separate records. The approved configuration record lives in the inventory. The runtime record is created for each interaction and references the approved configuration by identifier and hash. Keeping them separate also keeps approved-configuration evidence distinct from runtime user input, which matters because prompt injection is a case of user input altering model behavior in unintended ways.

A useful runtime record contains an interaction identifier, a timestamp, the parent system ID, the configuration ID with model, prompt, corpus snapshot and manifest versions and hashes, the policy decisions applied, and, for each tool call, the tool, the parameters category and the outcome. Where a human approval was required, the approver and decision belong in the record. A mismatch between the hash observed at runtime and the approved hash is a detectable event.

Enforcing policy in the execution path is what makes this record dependable. Evidence generated at the point where a request is allowed, redacted or blocked is stronger than evidence reconstructed from application logs afterward.

Some parts of the problem sit outside what runtime enforcement can evidence. These include the quality and accuracy of corpus content, the provenance of upstream data, edits made to prompts or corpora through paths that never pass through the enforced execution path, and the decision about whether an approved configuration was appropriate in the first place. Those remain with validation, content governance and access control.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Policy decisions are allow, redact, block, rate limit or escalate for human approval, enforced at runtime, not reviewed after the fact. That enforcement produces continuous audit-ready evidence, mapped to frameworks including NYDFS and NIST. Trussed can be self-managed in the customer's cloud, with configurable retention and data residency.

Trussed is not an inventory system of record and does not provide model or dataset provenance. It supplies the runtime side of the link described above. The platform has run continuously in production at a regulated enterprise for more than 18 months, with insurance as the regulated financial sector where it is deepest.