What should organisations do when one agent hands tasks to another?

When a handoff happens, what is actually being delegated?

A task handoff is not just message passing, it is a transfer of context, authority, and responsibility. The sending agent may know why the work exists, but the receiving agent should be evaluated as a fresh actor for the specific action it is about to take. That is why the boundary matters even when both agents sit inside the same workflow.

Good handoff design separates intent from execution. The intent can survive the transfer, but execution rights should be narrowed to the minimum needed for the next step. In practice, that means the receiving agent may need task context, but not the full standing access, broad tool scope, or open-ended ability to continue every prior action.

One useful mental model is to treat the handoff like a new approval point. If the next agent can write, spend, disclose, delete, or call external tools, those powers should be re-validated rather than assumed from the upstream agent’s authority. That keeps delegation from quietly becoming privilege propagation.

How should context, tool access, and approval be re-checked?

Start by separating the handoff into three decisions: what context can move, what tools the receiver may use, and what actions still need approval. The context should include only what the next agent needs to complete the task safely, while the tool and approval boundaries should be explicit enough that a later agent cannot inherit hidden permissions by default.

The safest pattern is task-scoped delegation with short-lived authority. If the receiving agent only needs to summarise, route, classify, or draft, then it should not receive the ability to execute transactions or chain into more powerful tools. If the work truly requires broader authority, that broader authority should be issued intentionally and logged as a separate decision.

This is where policy enforcement matters more than workflow convenience. A handoff can be technically seamless while still being unsafe if the downstream agent can act as if it were the original requester. Current guidance for agentic systems consistently favours per-action checks, explicit delegation, and human approval for high-impact steps, rather than implicit inheritance of trust.

What makes agent-to-agent delegation risky in practice?

Delegation risk grows when the upstream agent has accumulated context that the downstream agent should not be trusted to reuse blindly. A receiving agent may inherit stale assumptions, overbroad permissions, or a misleading sense of legitimacy, which is especially dangerous when the task spans tools, systems, or organisations. A poor boundary turns one safe action into a longer chain of uncontrolled actions.

Handoffs also create opportunities for permission inflation. If each agent in a chain automatically passes on everything it received, the overall blast radius expands with every step. That is why multi-agent orchestration should be designed around containment, not convenience, and why the boundary should be the place where you intentionally shrink scope before moving work forward.

Risk and Threat Considerations

Agent-to-agent handoffs can turn a narrow task into a distributed abuse path when delegation is assumed rather than verified. The main failure mode is permission carryover: a downstream agent inherits context or tool reach that is broader than the next step actually requires, which can amplify mistakes, prompt-injection effects, or malicious use of the chain.

Failure mechanism: The receiving agent is treated as trusted because it is part of the same workflow, so context, token scope, or action rights are passed forward without re-evaluating whether the next step still needs them. That can enable overreach, unintended side effects, and cascading compromise across agents.

Impact: A compromised or over-authorised receiver can widen the blast radius, perform unauthorised tool actions, or continue a workflow beyond the original intent. In multi-agent systems, that often turns a single boundary failure into a chain of unsafe actions that is harder to trace and contain.

Practitioner Guidance

What to verify: Confirm that every handoff has an explicit policy decision for the next agent, not just a technical relay. The question is whether the receiver needs this context, this tool, and this approval state, not whether it can technically accept them.

Decision rule: If the receiving agent can cause external side effects, treat the handoff as a fresh authorisation event. If the next step is read-only or low impact, keep the delegated scope narrow and time-bound; if it is write or transaction capable, require re-checks and logging at the boundary.

What good looks like: The workflow can continue without silently expanding privilege. Each agent sees only the minimum context needed, tool access expires when the task ends, and any escalation from one agent to another is visible as a deliberate control decision rather than an invisible default.

Practitioner takeaway: Safe agent handoffs are not about trusting the chain, they are about forcing each link to earn its own authority before it can act.

Related resources from NHI Mgmt Group

• When should organisations treat an AI agent as a privileged system?
• What should security teams do when one agent hands work to another?
• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?