Agent Hand-offs: Accountability and Least Privilege

When one agent hands work to a sub-agent, the child should hold less authority than the parent, and the parent should see a summary. Where hand-offs leak authority and how to check.

By Harinderpal Hanspal on October 2026

OWASP lists excessive functionality, permissions and autonomy as the causes of excessive agency, and names a compromised peer agent as one trigger. A hand-off should narrow authority to the task, fixed where the parent cannot widen it, with a named person accountable for the whole chain.

A hand-off passes down less authority than the parent holds, and only a summary comes back upSketch of a parent agent holding three tools, passing a task to a child agent that holds two. A red mark shows the parent cannot widen the child's tools. A return arrow labeled summary only goes back up, and a person is drawn above the parent as the one who answers for the whole chain.answers for the chainparent agent- read calendar- write order- close orderchild agent- read calendar- write orderno close ordertasksummary onlyset by the deployer,not by the parent
A hand-off passes down less authority than the parent holds, and only a summary comes back up

OWASP names three causes of excessive agency in LLM applications: excessive functionality, excessive permissions and excessive autonomy. Its prevention advice is to limit the tools an agent can call, and the permissions those tools hold, to the minimum necessary. Among the triggers it lists is a malicious or compromised peer agent in a multi-agent system (OWASP LLM06:2025).

A hand-off is where that advice meets a design decision. When agent A passes work to agent B, something travels with it, and nobody wrote down what.

What travels when an agent hands off work

Picture a planning agent that owns next week's maintenance schedule. It hands "move Friday's pump inspection" to a scheduling sub-agent. The sub-agent needs to read technician calendars and write one work order. Does it also get the planner's other tools, such as closing orders or releasing a quality hold?

One vendor's documentation shows how a default can answer that. In Claude Code, a subagent's tools field is an allowlist, and omitting it means the subagent "Inherits every tool available" in the session. When the main conversation runs in a mode that skips permission prompts, the subagent runs in that same mode and ignores the one set for it. A subagent can spawn its own subagents, up to three layers down by default, and the parent gets back only a summary (Claude Code docs). The same page gives the controls to narrow all of this, so the defaults are a place to look, not a verdict on one product.

The protocols point the other way. The MCP authorization specification says a server must not pass through the token it received from a client; a call to an upstream API uses a separate token issued by that API's own authorization server (MCP specification, 2025-11-25). The A2A specification says agents collaborate without sharing their internal plans or tool implementations, and requires authorization scoping so a client reaches only the tasks it is authorized for (A2A v1.0.0). Both treat authority as granted per hop. Neither says how a person's authority should shrink as it passes down a chain, and that gap is the design work.

Three rules for a hand-off

The child's tool set is set by the deployer, not the parent. If the parent can widen what the child holds, then compromising the parent compromises every child. The allowlist belongs in configuration the parent cannot edit.

Authority is the overlap, not the sum. The child gets what the task needs and what the requesting person may do, whichever is smaller. A scheduling sub-agent working for a planner has no business holding the planner's write access to quality records.

The parent sees a summary, and treats it as untrusted input. Seeing only a summary keeps the parent's context small. It also means "done, no conflicts" is the child's claim, so the record of what the child actually called must exist outside the summary, under the child's own identity. A compromised child can put instructions in its summary, and the parent will read them.

Who answers for the chain

Accountability does not delegate. Anthropic's framework says humans "should retain control over how their goals are pursued" (Anthropic, 4 August 2025). Singapore's IMDA framework, voluntary guidance released 22 January 2026, asks organizations to limit agents' powers, including autonomy and access to tools and data, and to make humans meaningfully accountable through approval checkpoints (MDDI release). NIST's AI Agent Standards Initiative, launched 17 February 2026, lists an agent identity and authorization concept paper; it is an initiative, and no standard for hand-offs has come out of it (NIST).

Questions to put to a vendor about hand-offs

  1. Does a sub-agent inherit the parent's tools by default, or start with none?
  2. Can the parent widen the child's tool set at run time? Who can?
  3. Whose identity appears on the child's actions in the log: the child's, the parent's or the person's?
  4. What does the parent receive back, and is the child's full call record kept somewhere the parent cannot rewrite?
  5. How many layers deep can sub-agents spawn, and who sets that limit?
  6. Which named person answers if a sub-agent's write causes harm?

Drawn from OWASP LLM06:2025, the MCP authorization specification (version 2025-11-25), the A2A protocol specification (v1.0.0), Anthropic's Claude Code subagent documentation, Singapore IMDA's agentic AI framework release (22 January 2026), NIST's AI Agent Standards Initiative (17 February 2026) and Anthropic's agent framework (4 August 2025), all read on 6 October 2026. The reasoning about hand-offs is ours.

Related notes

Related paper: Governing agents in production: what to ask before an agent acts