Beyond the Model Inventory: Governing Agentic AI Vendor Dependencies

Many financial firms already maintain a model inventory. That is a sensible control for quantitative methods that estimate risk, price instruments, or guide portfolio decisions. It is not, on its own, an inventory of an agentic AI system.

An agentic system can combine a foundation model with retrieval, internal data, third-party APIs, tools, permissions, human review, and automated actions. Knowing the model name does not answer what it can access, which dependencies can stop it, what evidence it retains, or how the workflow continues if a dependency changes or fails.

That distinction has become more important in the recent policy discussion. The Federal Reserve, OCC, and FDIC’s revised model-risk guidance, issued in April 2026, says that generative and agentic AI models are outside the guidance’s formal scope because they are novel and rapidly evolving. The agencies also say a banking organization’s risk-management and governance practices should guide the controls for tools, processes, and systems outside the document’s scope.

This is not an exemption from governance. It is a warning against applying a narrow label to a wider system.

The unit of governance is the system in use

For a traditional model, an inventory might capture purpose, owner, inputs, assumptions, validation status, use, and monitoring. Those fields still matter. An agentic workflow adds control points that a model inventory can easily miss:

• The model and the specific version or service configuration in use.
• Retrieval sources, data permissions, freshness rules, and citation requirements.
• Tools the system may call, including whether it can write, send, file, trade, or alter a record.
• Human approvals, escalation conditions, and the evidence required before an output becomes a decision record.
• External services that provide model access, hosting, search, data, identity, or workflow execution.
• Logging, retention, and the ability to reconstruct a material action after the fact.

The purpose is to make the workflow legible to the people responsible for risk, technology, and the business decision. A public-source research assistant and a system that updates a client record after calling multiple services are not the same risk class, even if both begin with the same model provider.

Scope boundaries create an ownership test

The revised Federal guidance is directed at banking organizations and should not be read as a rule for every asset manager, lender, or real estate firm. Its framing is still useful. When a technology falls outside an established policy category, the right question is not whether the category name applies. The question is who owns the control decision, how rigor is matched to materiality, and who can challenge the workflow before it affects an important outcome.

For an agentic system, ownership should be explicit across at least four roles:

1. Business owner: defines the task, materiality, acceptable output, and when human judgment is required.
2. Data owner: specifies the information the system may retrieve, retain, or transmit.
3. Technology owner: manages models, tools, configurations, service levels, and change control.
4. Risk owner: independently tests the controls, dependency map, incident path, and evidence available to reviewers.

One individual can hold more than one role in a smaller firm. The responsibilities should still be visible. A business team may adopt a tool, technology may manage the vendor, and risk may only see the final output. A system inventory makes those joins inspectable.

Dependency is more than concentration

On June 10, the Financial Stability Board published a consultation report proposing 12 sound practices for financial institutions’ responsible AI adoption. It is a consultation, not a binding standard. Its frame spans organization-wide governance and AI-related cyber, information-and-communication-technology, and third-party risks.

The Investment Company Institute’s July 22 response adds a useful industry perspective. It argues that technical dependency can arise from reliance on a limited set of foundation models, cloud providers, datasets, APIs, and other technology services. It also identifies portability, interoperability, vendor switching, contingency planning, and the continuity of critical operations as issues that need attention. That is a consultation response, not a supervisory requirement, but it describes a practical risk pattern.

Concentration asks whether too many firms rely on the same provider. Dependency asks a closer operational question: what breaks in this workflow if a named provider changes a model version, an access term, a pricing policy, a data format, a rate limit, or service availability? A firm can have several vendors and still have a single point of failure if every critical workflow depends on the same identity service, cloud region, retrieval index, or proprietary tool protocol.

Test the exit before the workflow becomes critical

Vendor diligence often ends with security questionnaires, pricing, and contractual terms. For a material workflow, the more useful test is operational: could the firm continue safely if it had to change a dependency?

An exit exercise does not require a full migration. It requires a credible answer to a bounded set of questions:

• What data, prompts, tool configurations, evaluation sets, and logs can be exported?
• Which portions of the workflow are portable and which are tied to a provider-specific interface?
• What service can operate in a read-only or manual fallback mode?
• How will the firm preserve source provenance and audit trails during a transition?
• Who decides to suspend the agent, and who communicates the change to affected users?
• What is the maximum acceptable downtime for this workflow?

This matters for systems that generate client-facing material, compile investment research, or write into systems of record. A firm may replace a model eventually while still being unable to explain a decision made during the migration. Evidence retention and change control are part of resilience.

Human oversight has to be executable

Who sees a material action before it occurs? What evidence do they receive? Can they reject it, and does the system halt rather than route around the rejection? Who reviews a change in model, retrieval corpus, tool permission, or vendor term? These are architecture questions.

The answer should vary with materiality. A public-source research assistant may require citation display and a reviewer before external use. An agent permitted to change a record, submit a filing, communicate with a client, or influence an investment decision needs tighter permissions, a more complete trace, and a clear stop mechanism. No one control fits every use case. A vague human-in-the-loop claim fits none of them.

A concise inventory that managers can use

The most useful governance artifact is not necessarily a comprehensive policy. It is a current, reviewable record for each material agentic workflow. It should capture:

1. The workflow’s decision purpose, user group, materiality, and prohibited actions.
2. The model, retrieval sources, tools, permissions, and external dependencies.
3. The data classification, retention rules, source-citation requirements, and evidence trail.
4. The owner, independent reviewer, approval gates, monitoring signals, and escalation path.
5. The change-control process for models, prompts, data, tools, and vendor terms.
6. The fallback mode, portability limits, and tested response to a provider disruption.

This document reflects the object the firm actually operates. It can help a team decide which agents should remain drafting tools, which can take bounded actions, and which are too dependent on untested infrastructure for a material workflow.

The governance conclusion

The recent guidance does not settle every question around agentic AI. It does make one point hard to ignore. A control framework that sees only the model will miss the data, tools, people, providers, and action paths that make an agent useful and risky.

Financial institutions and real estate investment teams do not need to wait for a perfect taxonomy. They can govern what is already in use: define the workflow, map the dependencies, assign ownership, retain the evidence, and test whether the system can stop or continue safely when a provider changes. That is a practical response to an evolving technology, and it gives managers a clearer basis for deciding where agents belong in a consequential workflow.