FINRA Readiness Checklist for LangGraph and LangChain Agent Deployments

What FINRA expects when agents reach production

FINRA states that its rules are technology neutral and continue to apply when member firms use generative AI or similar technologies. That holds whether a firm builds the tool for proprietary use or relies on a third party, including embedded features in existing third-party products. Rule 3110 requires a supervisory system reasonably designed to achieve compliance, and FINRA's AI report ties supervisory control systems to Rules 3110 and 3120. A firm is expected to evaluate a tool before deploying it and to confirm it can keep complying with the rules that apply to that business use.

Which rules apply depends on how the agent is deployed, and FINRA has said it may issue further guidance on specific use cases. Its 2026 oversight report names four agent risks: autonomy (acting without human validation and approval), scope and authority (acting beyond the user's actual or intended scope), data sensitivity, and limited domain knowledge for complex, industry-specific tasks.

Frameworks such as LangGraph and LangChain define how an agent sequences model calls and tools. The checklist below is framework-agnostic because the examiner's question is the same either way: what was this agent allowed to do, and what did it do? As of November 2026, proposed changes to Rule 2210 on communications are out for comment under Regulatory Notice 26-14, with no adoption to assume. Track them, but build against current requirements.

Which controls belong in the execution path

Review after the fact can detect a problem. It cannot prevent one. The two agent risks with the most direct consequences, autonomy and scope and authority, point toward controls that act before an action completes: a tool-call decision to allow or block, and an approval step ahead of any consequential action. FINRA's AI report gives a parallel example, describing amount or threshold limits on trade orders where models trigger actions autonomously. That pairing of agent risks with in-path controls is an inference from FINRA's materials, not a stated requirement.

A practical sorting test is to ask of each tool call: if this action were wrong, could it be undone, and who would notice? Calls that move money, change client records, or send content to a client belong in the enforced-before-execution group. Lower-consequence read operations can often rely on sampling and supervisory review.

There are tradeoffs. Every approval point adds latency and reviewer workload, and too many of them push reviewers toward rubber-stamping. Keep the approval list short, tied to defined thresholds, and revisit it as the agent's behavior becomes better understood.

Documenting model risk and supervisory ownership

FINRA's AI report lists model risk management, data governance, customer privacy and supervisory control systems as factors for firms adopting AI applications. It says model validation should be updated for the complexity of machine learning, covering input data, algorithms, parameters (for example, verifying risk thresholds) and output explainability.

Those four areas line up with the execution stages above. Input data validation corresponds to the inputs stage. Algorithm and parameter review corresponds to model calls and to the thresholds set on tool calls. Explainability corresponds to being able to reconstruct why an output was released or an action was blocked. Assign a named owner to each, and state who validates agent actions and where human approval is required.

A useful test for the documentation is whether a reviewer who was not on the build team could trace a single agent action from the permission that allowed it, through the threshold that applied, to the record of what happened.

Where runtime enforcement capability closes gaps

Orchestration frameworks decide how an agent runs. They do not, by themselves, give a firm policy enforcement at the tool-call level, approval before consequential actions, or evidence organized for supervisory review. If the checklist shows those gaps, they need a control that sits in the execution path rather than another review process.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Enforcement actions include allow, redact, block, rate limit and escalate for human approval. Enforced at runtime, not reviewed after the fact, each decision produces audit-ready evidence, which maps to frameworks including NIST. Trussed can be self-managed in the customer's cloud, with configurable retention and data residency. It has run continuously in a production regulated enterprise for more than 18 months, and its deepest regulated-sector footprint is in insurance.

It does not replace the firm's supervisory procedures, pre-deployment evaluation or model validation. It supplies the enforcement and evidence layers that those documents refer to.