Is a LangChain Agent a Model Under SR 26-2? Scoping Chains, Tools, and Retrievers

Why the unit of scoping matters

Teams often inventory a LangChain application as a single entry, or skip it because the underlying model belongs to a vendor. Both approaches produce inconsistent inventories. One team lists the application, another lists the foundation model, and a third lists nothing. Validation boundaries become unclear, and there is no stated reasoning to show an examiner.

Industry security guidance already separates the layers. An AI system is described as the complete stack that delivers a capability: the model, the data it draws on, the orchestration logic that manages its actions, the integrations to other systems and the user interfaces. The model is one part of that stack. Agent systems are described in similar terms, as at least one generative model plus scaffolding software that gives the model tools to take discretionary actions.

That decomposition suits a scoping exercise. The SR 26-2 definition is the test. LangChain's architecture is the subject. Apply the test to each component, not to the application as a whole, and write down why each one lands where it does.

Component-by-component screening

The table gives the technical role of each LangChain component and the question to put to it when reading the SR 26-2 definition. The questions are screening prompts. The outcome depends on the text of the definition and your institution's interpretation of it.

• Foundation model call: Generates output from a prompt. Ask whether the output is an estimate, classification or recommendation that the business relies on, and whether the model is vendor-hosted or internal.
• Prompt templates: Parameterized instructions and context. Ask whether they transform inputs into outputs themselves or only shape the model call. Version them either way.
• Chains: Fixed sequences of steps. Ask whether any step does quantitative processing of its own or only passes data between components.
• Agent loop: Lets the model choose tools and make repeated calls, using prior outputs to guide later actions. Ask whether the loop produces a decision output, or whether the decision sits in the model call.
• Tools: Functions that call APIs, write records or trigger transactions. Ask whether they compute estimates. Most execute deterministic logic and are better treated as software with action-level controls.
• Retrievers: Fetch documents or records for the prompt. Ask whether ranking or scoring is relied on as an output, and what enterprise data the retriever can reach.

Applying the definition with stated reasoning

For each component, write the scoping decision as a short record: the component's role, the specific language of the definition you applied, the conclusion, and who approved it. A conclusion without reasoning cannot be reviewed. The same conclusion with reasoning can be challenged, refined and defended.

The foundation model call is the natural first candidate because it produces the generated output the application depends on. Inventory it separately from the orchestration built around it, and state whether it is accessed through an API or hosted internally, since the ownership and validation access differ.

Orchestration is the harder case. A chain that passes text between steps does little that resembles estimation. An agent loop that chooses tools and decides when to stop shapes outcomes without computing anything itself. Reasonable reviewers can reach different conclusions. If you scope the loop out, record that the model call it relies on is in scope, and that the loop is covered by software change control and runtime enforcement.

Tools and retrievers are usually deterministic software and data access. Scoping them out of the model definition does not take them out of control. A tool that changes external state carries risk because of what it can do, not because of how it calculates. A retriever carries risk because of what data it can reach and return.

Where interpretation is still required

Several questions turn on judgment, and a scoping record should say so rather than imply certainty.

The first is whether the combination is more than its parts. An agent whose model call is in scope may still be a distinct object once orchestration decides which tools run and in what order. Some institutions will inventory the composite application as a parent entry that links to its in-scope components. Others will inventory only the model and treat the rest as dependencies. Either can be defended if it is applied consistently.

The second is the effect of delegated tool selection. Where an LLM agent decides which extension to invoke based on the prompt or on earlier output, the model's output directly determines an action. That raises the weight of the model call in validation and argues for controls on the action itself.

The third is whether a retriever-only application differs from an action-taking one. Security guidance treats retrieval-augmented systems that are not orchestrated to act autonomously differently from agent systems that can change external state. Record whether each application can take actions, because the answer affects both scoping and control design.

The fourth is vendor-hosted models. Your visibility into a model you access by API is limited, so the validation approach differs from that for an internal model. Document that difference in the inventory entry.

Controls and evidence for in-scope and out-of-scope components alike

A component judged out of scope still needs controls. The useful principle is to enforce in execution code outside the model, next to the component that creates the side effect. Model output should be treated as untrusted at every downstream use, and checks placed at the agent's input and output cover only part of the risk.

For tools, grant each agent the minimum tools its task requires, and keep separate tool sets for different trust levels. Validate proposed tool arguments and enforce the caller's permissions outside the model. Require action-specific approval before high-risk operations run. LangChain's human-in-the-loop middleware can pause configured tool calls for review. Where you set agent budgets for tokens, money or time, document them as a control on resource use.

For retrievers, define which enterprise data stores each retriever can reach and under what permissions, and keep evidence of what was retrieved.

This leads to the evidence question. Approvals, pauses and blocks on tool calls and retrieval actions should each leave a record. Examiners will look for what a component was permitted to do and what it did. Produce that record for every component, so it does not depend on how the component was scoped.

Where Trussed fits

Scoping decides how a component is inventoried and validated. It does not enforce anything at runtime. Trussed addresses that part. It enforces policy in the execution path on individual interactions and tool calls, across models, agents, tools and MCP servers. Each interaction or tool call can be allowed, redacted, blocked or escalated for human approval, and the enforcement is applied at runtime, not reviewed after the fact.

Each decision produces audit-ready evidence of what was permitted and what happened. That evidence is generated the same way for a component scoped as a model and for one scoped as surrounding software. Trussed does not decide your scoping and does not replace validation of in-scope components. It covers the runtime control and evidence requirements that apply to both.