What should security teams do when one agent hands work to another?

Why This Matters for Security Teams

When one agent hands work to another, the risk is no longer just what each agent can do in isolation. The handoff becomes a trust boundary, a logging boundary, and often a privilege boundary. If the chain is incomplete, investigators cannot reliably reconstruct intent, responsibility, or data flow. That matters for incident response, fraud review, compliance evidence, and post-incident containment. Current guidance in the OWASP Agentic AI Top 10 treats agent-to-agent delegation as a real attack surface, not just an implementation detail.

The practical issue is that delegated work can cross identities, tools, and policy scopes without leaving a clear provenance trail. A task may begin with a legitimate request, pass through a planning agent, then be executed by a tool-using agent with broader permissions than the originator intended. If ownership metadata is weak, the security team loses the ability to answer a basic question: which actor actually caused the action?

That is why security teams should treat agent handoffs like controlled service-to-service trust, not informal workflow chaining. In practice, many security teams encounter the failure only after an unauthorized action has already been executed by the receiving agent, rather than through intentional handoff review.

How It Works in Practice

At minimum, each handoff should preserve identity, context, and policy state. Identity means a stable way to name the initiating agent, the receiving agent, and the human or system owner behind them. Context means the task payload, relevant trace identifiers, and enough metadata to reconstruct what was requested. Policy state means the permissions or guardrails active at the time of transfer, including whether the receiving agent was allowed to accept the work at all.

In mature environments, this is implemented as an evidence chain rather than a single log line. The chain should capture who delegated the task, what was delegated, which model or orchestration layer accepted it, and what tools or data the second agent could access. This aligns closely with the accountability and traceability expectations in the NIST AI Risk Management Framework, especially for governance, mapping, and measurement.

• Use stable agent identifiers that do not change across sessions or retries.
• Carry trace context across orchestration layers so the handoff is visible in SIEM or observability tooling.
• Record ownership metadata for each agent, including the business owner and technical operator.
• Tag delegated actions with the policy version and tool scope in force at receipt time.
• Require explicit acceptance or rejection by the receiving agent, rather than silent continuation.

For higher-risk workflows, teams should also validate the handoff content before execution. That may include schema checks, content filtering, tool allow-listing, and step-up approval when the receiving agent receives a task outside its normal role. The point is to make the transfer auditable and bounded, not merely possible. The MITRE ATLAS adversarial AI threat matrix is useful here because it highlights how adversaries abuse orchestration, deception, and model interaction paths rather than only attacking the model itself. These controls tend to break down when agents are chained through ad hoc message buses or plugin calls because the receiving system cannot reliably preserve provenance across intermediate transformations.

Common Variations and Edge Cases

Tighter handoff controls often increase orchestration overhead and can slow automated workflows, so organisations have to balance traceability against operational latency. That tradeoff becomes sharper when agents are used for low-latency support tasks, autonomous remediation, or high-volume triage.

There is no universal standard for exactly how much provenance every agent handoff must carry yet, so current guidance suggests scaling the evidence chain to the sensitivity of the task. For routine, low-impact transfers, a stable identifier and basic trace link may be enough. For privileged operations, customer-facing decisions, or actions that touch secrets, stronger controls are warranted, including explicit delegation records and policy snapshots. This is where the intersection with NHI governance becomes important: an agent can behave like a non-human identity with delegated authority, and that authority should be reviewable just like any other privileged service account.

Edge cases include multi-agent loops, where one agent forwards to several others, and brokered workflows, where an orchestration layer rewrites or splits the task. Those patterns can blur responsibility unless the system preserves parent-child linkage throughout. Teams should also be cautious when a handoff crosses environments or vendors, because provenance often weakens at integration boundaries. The CSA MAESTRO agentic AI threat modeling framework is helpful for thinking about those multi-step trust relationships, while the Anthropic first AI-orchestrated cyber espionage campaign report is a reminder that attackers increasingly exploit agent workflows, not just isolated prompts.

Related resources from NHI Mgmt Group

• How should security teams handle agent delegation when one agent can spawn another?
• How should security teams govern human, machine, and AI agent identities in one programme?
• What do security teams get wrong about replacing one access platform with another?
• How do security teams reduce AI agent data leakage without slowing work?