Mapping LangGraph Agent Controls to FINRA Rule 3110 and SR 26-2 in One Control Matrix

Why a single matrix

FINRA Rule 3110(a) requires a member to establish and maintain a system to supervise the activities of each associated person, reasonably designed to achieve compliance with applicable securities laws and FINRA rules. Rule 3110(b) requires written procedures that identify supervisory personnel and their responsibilities. FINRA states that its rules are technology neutral and apply to generative AI as to any other technology, whether a firm builds the tool or uses third-party technology. Its 2026 oversight report describes AI agents as able to plan, decide and act toward goals, and lists the question of how to establish control mechanisms that limit or restrict agent behaviors, actions or decisions.

The model risk side is usually documented elsewhere. SR 26-2, the Federal Reserve's revised guidance on model risk management (attachment dated April 17, 2026, as of November 2026), describes effective policies that set a monitoring and control process, ongoing monitoring plans, and a model inventory with enough information to understand risk individually and in aggregate. Compliance typically owns the first set of obligations and model risk management the second.

The practical result is two control lists with overlapping statements and no shared link to how the agent is built. An examiner who asks what stops an agent from taking an unapproved action receives two documents and no answer at the tool call, which is where the agent acts. One matrix, keyed to LangGraph constructs, closes that traceability gap. It does not settle legal questions. Whether SR 26-2 applies to a particular firm or agent is a determination for that firm's compliance and model risk functions.

Matrix structure: six column groups

Keep one row per control point and per control objective. If a single tool call needs both a redaction and an approval, write two rows. This keeps ownership and evidence unambiguous. The columns below are a design recommendation, not a regulator-published format.

• 1. Row ID and control objective: A plain statement of what must not happen or must be assured, for example 'the agent cannot submit an order above an approved limit without a supervisor decision'.
• 2. LangGraph control point: The node, conditional edge, tool call, interrupt or checkpoint where the control applies. A conditional edge routes on state. An interrupt pauses execution for human input. A checkpoint persists graph state.
• 3. Control type and enforcement location: Allow, redact, block, rate limit or escalate for human approval. Then state whether it is implemented in application code and graph design or enforced at runtime in the execution path.
• 4. Regulatory anchors: The Rule 3110(a) system, 3110(b) written procedures or Rule 3120 testing expectation, and the SR 26-2 policy, monitoring or inventory expectation the row supports.
• 5. Owner and independent tester: The supervisory person named in the written procedures, the model risk contact, and who tests the control. Rule 3110(b)(6) bars supervisory personnel from supervising their own activities, so the tester should not own the agent.
• 6. Evidence artifact and inventory reference: The specific record an examiner would request, its retention period, and the model inventory entry for the agent the row covers.

Worked example rows

These rows are illustrative. Each firm must set its own thresholds, owners and anchors with compliance. The order-limit row borrows an example from FINRA's AI report, which cites amount or threshold limits on trade orders where models trigger actions autonomously. That example is not a requirement for LLM agents.

• R1: Tool allowlist per node: Objective: the agent can call only approved tools. Control: allow or block. Anchors: 3110(a) system; SR 26-2 policies and controls. Owner: named supervisory principal with model risk review. Evidence: per-call policy decision and the policy version in force.
• R2: Order or amount limit on a tool call: Objective: no action above an approved threshold without a decision. Control: rate limit, block, or escalate. Anchors: 3110(a); FINRA threshold example. Owner: business supervisor. Evidence: the call arguments evaluated, the limit applied and the outcome.
• R3: Human approval interrupt: Objective: a qualified person decides before a consequential action proceeds. Control: escalate for human approval. Anchors: 3110(b) responsibilities of supervisory persons. Owner: designated supervisor. Evidence: approver identity, time, the payload shown, the decision.
• R4: Client data in tool inputs and outputs: Objective: sensitive fields do not reach the model or leave the firm unredacted. Control: redact or block. Anchors: recordkeeping and communications areas FINRA says GenAI can implicate. Owner: compliance with security. Evidence: a record of the redaction applied to each interaction.
• R5: State persistence and periodic review: Objective: agent behavior is reviewed over time against expectations. Control: scheduled review of retained state and decisions. Anchors: SR 26-2 ongoing monitoring and inventory; Rule 3120 testing. Owner: model risk with an independent tester. Evidence: dated review reports and test results.

Graph design versus runtime enforcement

Some controls belong in the graph. Routing a high-value action through an approval interrupt, limiting which tools are bound to which node, and shaping state so that decisions are recorded are design choices. They are reviewed before deployment, which fits FINRA's Regulatory Notice 24-09 statement that firms should evaluate GenAI tools before deployment. Their weakness is that they are only as strong as the code path that implements them. A new node, a changed prompt or a revised tool binding can alter behavior, and the control record then shows intent, not operation.

Other controls are better enforced where the call is made. Tool-call policy enforcement at runtime evaluates each call against current policy before it executes, whatever graph version issued it, and produces a record of the decision. That separation also helps with ownership. Engineering owns graph design, and the supervisory and model risk owners in the matrix own the policy that is enforced. Column 3 should state which side each row relies on. A row that relies only on application code needs a test that shows the code path cannot be bypassed.

Trussed is one example of the runtime approach. It enforces policy in the execution path of agent and tool interactions (allow, redact, block, rate limit, escalate for human approval) and generates audit-ready evidence from that enforcement. Its scope is individual interactions and tool calls. It does not provide transaction-level governance, end-to-end tracing of agentic workflows or model lineage, so the matrix should not claim those.

Ownership, testing and the gaps the matrix cannot close

Rule 3110 requires written procedures to name supervisory personnel and their responsibilities, and a record of designated supervisory personnel and designation dates must be preserved for at least three years. The owner column should therefore match the names and titles in the written procedures, not a team alias. Rule 3120 requires supervisory control procedures that test and verify that the written procedures are reasonably designed, and an annual report to senior management. Whether agent controls feed that report is a firm decision, but the matrix gives the testers a defined list to sample.

FINRA also lists formal review and approval involving both business and technology experts as a governance practice for GenAI. Record in each row who from each function reviewed it. Because compliance and model risk are separate functions, state which one accepts residual risk for the row.

The matrix has limits. It covers individual interactions and tool calls, not the full business transaction across tasks and agents. It cannot show that the model's reasoning was sound, only that actions were constrained and decisions recorded. It does not replace the model inventory, the written procedures or independent testing. List known gaps in a final section of the matrix with a named person who has accepted each one. An examiner will find an acknowledged gap more credible than an apparently complete table.