What breaks when one agent can pass untrusted work to a more privileged agent?

When a less-trusted agent can hand work to a more privileged one, what actually fails?

The core failure is not the handoff itself, but the assumption that an internal request is trustworthy because it came from inside the workflow. Once a less-privileged agent can influence a higher-privilege agent, the boundary between “who is asking” and “what is being asked” stops being reliable. That turns delegation into an attack path.

In practice, the privileged agent may still be acting correctly on its own policy, but the policy is being triggered by a request that should have been subjected to stronger scrutiny. The risk is the same pattern seen in confused-deputy style failures: a trusted component performs an action on behalf of a source that should not have been able to request it.

That is why multi-agent systems need explicit trust boundaries, not just functional handoff logic. A workflow can be operationally correct and still be security-incorrect if the receiving agent does not distinguish between verified delegation and mere receipt of an internal message. The distinction matters most when the second agent has broader tool access, can reach production systems, or can spend credentials and tokens that the first agent should never control.

Why delegated privilege abuse is a security problem, not just a design smell

The security issue is privilege amplification through trust transitivity. If the lower-trust agent can shape the higher-trust agent’s action, then the attacker can route an untrusted instruction through a path that inherits the receiving agent’s authority. That is especially dangerous when the system treats multi-hop delegation as equivalent to first-party intent.

This is where identity and authorization become material to the answer. The important question is not only whether an agent is authenticated, but whether the receiving agent can verify the original principal, the scope of delegated authority, and the action being requested. The AI Agent Authorisation Guide is useful here because it frames the control problem as per-action authorization, not blanket trust in the workflow.

In agentic systems, the failure mode often shows up as overbroad delegation, implicit trust in intermediate services, or tokens that are reusable beyond the context they were meant for. If the privileged agent can act on behalf of the workflow without checking the provenance of the request, then a compromised or manipulated agent can become a delivery channel for unauthorized action. That is why the receiving side must treat each handoff as a fresh security decision, not as a continuation of an already-approved task.

What controls stop the trust boundary from collapsing?

Controls need to constrain both delegation and tool use. The first line is least privilege for the receiving agent, so that a bad handoff cannot reach more systems than necessary. The second line is action-level authorization, so the privileged agent evaluates the request before each sensitive operation rather than inheriting trust from a prior step. The Zero Trust for AI Agents guide is directly relevant because it treats the principal, the request, and the action as separate verification points.

Handoff provenance also needs to be visible. If you cannot tell which agent originated the request, which permissions were in force, and whether the request crossed a trust boundary, you cannot reliably detect delegated abuse after the fact. The AI Agent Observability, Audit and Incident Response Guide helps with that by focusing on attribution, logging, and kill-switch design for agent actions.

For teams building multi-agent workflows, the safest pattern is to reduce implicit chain trust. Verify the original principal where possible, narrow the delegated scope, and make the privileged agent reject requests that are valid syntactically but untrusted contextually. If a system cannot express and enforce that distinction, it is effectively assuming that every internal message is benign, which is exactly the condition attackers exploit.

Risk and Threat Considerations

The risk is that a low-trust agent becomes an access path into a higher-trust control plane. Once that happens, the attacker no longer needs direct access to the privileged agent, only influence over the lower one. That can lead to unauthorized tool execution, data exposure, destructive actions, or lateral movement through the workflow.

Failure mechanism: The receiving agent fails to validate delegated authority and treats intra-system traffic as inherently safe, so an attacker can launder an untrusted request through a trusted intermediary.

Impact: Privilege is effectively escalated by delegation, and the privileged agent may execute actions that appear legitimate in logs but were not trustworthy in origin.

Practitioner Guidance

What to verify: Check whether the receiving agent can prove who originated the request, what scope was delegated, and whether the action exceeds the original intent. If those three cannot be reconstructed, the workflow is too permissive for sensitive operations.

Decision rule: If a downstream agent can reach production systems, secrets, or privileged APIs, require explicit per-action authorization and reject blind pass-through from upstream agents. If the action is low impact, you may tolerate broader delegation, but only where the blast radius is genuinely bounded.

Practitioner takeaway: Do not trust the workflow just because it is internal; trust only the specific principal, scope, and action that can be independently verified at the point of execution.

Related resources from NHI Mgmt Group

• When does an AI agent become a privileged access problem?
• When should organisations treat an AI agent as a privileged system?
• What breaks when an AI agent can turn untrusted content into privileged actions?
• What is the difference between human identity governance and AI agent governance?