LangGraph Supervisor Agent Tool Delegation Control at a Broker-Dealer, Under Current Model Risk Guidance

How delegation paths to restricted tools arise

In a supervisor pattern, one agent receives a task and routes it to specialist sub-agents. Each sub-agent carries its own tool set. A research agent might read market data, a client-service agent might read customer account data, and an operations agent might reach order entry. The supervisor typically does not hold those tools itself, but it decides who gets control next. That decision is made by a model, dynamically, from the input prompt and intermediate outputs.

OWASP's guidance on Excessive Agency (LLM06:2025) makes the same point: the choice of which extension to invoke can be delegated to an LLM agent that decides dynamically. In a multi-agent graph, that choice is stacked. The supervisor chooses an agent, and the agent chooses a tool. A request that begins in a workflow never meant to touch customer accounts, order entry or material non-public information can reach those tools through a handoff.

NIST material names delegation as a privilege-escalation path. Cached credentials, inherited roles and unintended delegated scopes can carry authority across agents, and tokens can propagate to allow access beyond the original scope. The risk is structural, not a model defect that better prompting removes.

Why native mechanisms and prompts are not enough on their own

LangGraph offers useful building blocks: tools bound per agent, handoff tools, conditional edges that constrain routing, and interrupts that pause for human input. Use all of them. They shrink the reachable surface and make the intended design explicit. The limitation is where they operate. They live inside the graph, are configured by the same team that builds the agents, and depend on the graph being wired correctly after every change. A new handoff, a shared tool list or a refactored sub-agent can widen reach without anyone deciding to.

Prompt instructions are weaker still. NIST guidance recommends not trusting prompt instructions from users or other agents as a control, because a supervisor's instruction to a sub-agent is itself model output. A rule such as "never call the order tool" is a request to the model, not an enforced boundary.

The implication is that graph design should reduce exposure, while a separate check in the execution path decides whether a specific call may proceed. That check should not depend on the agent's own reasoning.

What a tool-call authorization policy looks like

A usable policy is small and explicit. For each sub-agent identity, list the tools it may call and the permitted scope for each. Express restrictions as conditions on arguments, not only on tool names, because a permitted tool can still be misused through altered parameters. The OWASP Agentic Threat Auditor treats parameter mutation and lateral delegation escalation as test classes for this reason.

Also apply separation of duties. No single agent path should combine conflicting privileges, such as reading customer account data and entering orders. Because the check sees the calling agent's identity, it can deny a call even when the supervisor legitimately handed off to that agent.

Outcomes should be defined in advance. Allow permits the call. Redact permits it but removes fields the caller is not entitled to see, for example account identifiers in a response. Block denies it and returns a controlled error the graph can handle. Escalate pauses the call for human approval. Default to deny for any tool not listed.

Test the policy adversarially before and after graph changes. Exercise lateral handoffs, mutated arguments and requests for tools outside a sub-agent's list, and confirm each is blocked or escalated. Monitor for unexpected tool use in production, since agents should not run without telemetry.

Model risk, examiner scrutiny and where Trussed fits

On model risk, the guidance has moved. SR 26-2 updates the model risk management guidance first issued as SR 11-7 in April 2011. The agencies state that the update clarifies principles and emphasizes a risk-based approach tailored to a model's risk profile and the size and complexity of operations. Align your agent controls to a risk-based reading: tools touching customer data, order entry or MNPI warrant stricter entitlements and approval thresholds than read-only reference tools.

FINRA Regulatory Notice 15-09 addresses trading algorithms, not LLM agents. It is useful as an analogy: it expects policies to review and test algorithms, including post-implementation monitoring, and refers to security measures that limit code access and control system entitlements. Per-call authorization and retained evidence answer a similar supervisory question for agents.

Trussed enforces policy in the execution path across agents, tools and MCP servers, with allow, redact, block, rate limit and escalate-for-human-approval outcomes applied to individual tool calls. Enforcement is at runtime, not reviewed after the fact, and it generates audit-ready evidence mapped to frameworks including NIST. It can be self-managed in your cloud, with configurable retention and data residency. Trussed does not provide transaction-level governance or end-to-end tracing of agentic workflows. Its scope is the individual interaction and tool call, which is the point where the authorization decision in this guide is made. Insurance is where Trussed is deepest, and the same enforcement model applies to the controls described here.