LangGraph Agent Inventory: One Entry for Model Risk Management and FINRA Supervision

What changed in model risk guidance

Many inventory templates still cite SR 11-7 and OCC 2011-12. OCC Bulletin 2026-13, dated April 17, 2026, announced updated interagency model risk management guidance from the OCC, the Federal Reserve (as SR 26-2) and the FDIC. The bulletin rescinds prior model risk management guidance and other issuances, and it describes generative AI and agentic AI models as novel and rapidly evolving. The agencies also said they plan to issue a request for information on banks' use of AI, including generative and agentic AI. As of November 2026, an inventory that treats the older documents as the current standard needs its references updated.

The inventory concept itself remains. The revised guidance says banking organizations commonly maintain comprehensive information on models under development or in use, and that an effective inventory holds enough information to understand model risks at individual and aggregate levels. Earlier guidance listed purpose, products, actual or expected usage, restrictions on use, the type and source of inputs, underlying components and outputs with their intended use. Those categories are still a sensible starting point for field design.

On the FINRA side, Rule 3110 requires a supervisory system reasonably designed to achieve compliance, tailored to the firm's business, and leaves final responsibility for supervision with the member. Regulatory Notice 24-09 states that FINRA rules apply to AI, including generative AI, as they do to any other technology. The 2026 Annual Regulatory Oversight Report notes that AI agents carry notable risks and challenges. Neither regime prescribes a LangGraph schema, so the firm has to translate its obligations into fields.

Treat the entry as a shared data contract

Separate model risk and supervision inventories drift apart. The same agent ends up with two owners, two descriptions of its tools and two versions of its change history. Neither inventory usually records how the agent is built, so a reviewer cannot tell which node calls which model, which tools are bound to it or where a human can interrupt it.

A shared contract fixes this by keying every field to a question and to a LangGraph construct. Model risk asks what the agent is for, how material it is, what assumptions and limitations apply, whether it has been validated and how changes are controlled. Supervision asks who is accountable, what the agent may do, what it can reach, how outputs are reviewed and how records are kept. Most fields answer both, and a single record per agent keeps the answers consistent. It also supports the idea that a specific party maintains a firm-wide inventory while business lines contribute to it.

Field-level schema for one LangGraph agent entry

The table groups fields by the LangGraph construct they describe. Each row names who relies on it and how it can be verified. Treat it as a starting schema to adapt to the firm's own tiering and supervisory procedures.

• Identity, ownership and supervision (the agent as a whole): Serves both. Agent identifier, business purpose, accountable owner, named supervisor, materiality tier, restrictions on use, status including in development and retired. Static declaration, changed only through change control.
• Graph and nodes (graph definition): Serves both. Graph version, entry points, and for each node whether it calls a model, calls a tool, or pauses for a human. Static and versioned with the code. The declared version is the reference for later comparison.
• Tool bindings and data reach (tools): Primarily supervision, also model risk for inputs. For each tool: capability, permission, usage policy, data classes reachable. Declared, then enforced at runtime on each tool call.
• Model endpoints (model configuration): Primarily model risk. Each endpoint called, version, parameters, input sources and data provenance, assumptions, limitations, validation status. Declared, with calls to unlisted endpoints enforceable at runtime.
• State and checkpointing (state schema, checkpointer): Serves both. Fields held in state, whether client or customer data enters it, where checkpoints persist, retention period. Declared, and checked against what actually passes through interactions.
• Human-in-the-loop interrupts (interrupts): Primarily supervision, also model risk as a compensating control. Which actions require approval, who may approve, what is recorded. Enforced by escalation and evidenced by approval records.

Static declarations versus runtime-backed fields

Some fields describe a decision that does not change unless someone changes it: purpose, tier, owner, validation status and the graph version. These need review and change control, not runtime machinery. Others make a claim about behavior: this agent may call these tools, reach these data classes, use these endpoints and stop for approval before these actions. A claim about behavior is only a declaration until something in the execution path enforces it.

This matters because parts of a LangGraph agent's effective behavior can change without a code redeployment. Model endpoint names, prompts and tool configuration are often read from external settings, and state persisted by a checkpointer reflects whatever the agent encountered. An inventory that was accurate at registration can diverge from what the agent does. Without a control point that checks each model call and tool call against the entry, there is no way to show the divergence did not occur. The same logic appears in agentic security guidance, which notes that without an inventory of tools, their capabilities, permissions and usage policies, controls cannot be enforced and exposure cannot be assessed.

Human approval has a similar shape. Because the member retains final responsibility for supervision under Rule 3110, an interrupt that is declared but not evidenced does little for a supervisor. The entry should name who approves and the runtime should record that the approval occurred before the action proceeded.

The tradeoff is granularity. Per-tool permission data and approval rules take effort to maintain, and tiering should decide how much. A low-materiality internal summarization agent may need a short entry. An agent that can act on customer accounts needs the full schema and strict enforcement.

Where runtime enforcement and evidence fit

Trussed enforces policy in the execution path on individual interactions and tool calls. For a LangGraph agent, that means a model call or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval according to the permissions declared in the entry. Enforcement is applied at runtime, not reviewed after the fact, and it generates audit-ready evidence of each decision. That evidence is what lets a reviewer compare the declared tool list, data reach and approval points with observed behavior.

The scope is deliberate. Trussed does not trace entire agentic workflows end to end, record model lineage or govern at the level of a business transaction. The inventory remains the firm's own record of ownership, purpose, tiering and validation. Enforcement and evidence close the gap between that record and what the agent did. Trussed runs self-managed in the customer cloud, with configurable retention and data residency, so the firm sets how long evidence is held.

The schema above is useful with or without any particular tooling. The practical first step is to rebuild one high-materiality agent's entry in this format and test whether each behavioral field can be checked against runtime records.