How should security teams handle agent-to-agent delegation in approval workflows?

Treat it as a separate trust boundary, not as a convenient relay. If one session can forward blocked intent to another session, the organisation has created a privilege laundering path. The right test is whether the second agent can independently justify the request without relying on a denied action from the first.

Why This Matters for Security Teams

Agent-to-agent delegation changes approval workflows from a simple request-and-verify pattern into a chain of independently acting identities. That creates a trust boundary between the original agent and the downstream agent, and that boundary must be enforced explicitly. If a denied request can be repackaged and forwarded, the workflow can become a privilege laundering channel rather than a control point. Guidance from OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework both point to the same operational reality: delegation must be treated as a distinct security event, not a convenience feature.

This matters because approval workflows are often built for human escalation, where intent remains visible and accountability is easier to preserve. Agentic systems are different. They can chain tools, rewrite context, and reframe the same request until a downstream approval path accepts it. NHIMG research on agentic risk shows how quickly these patterns become real in production, especially when teams assume that a single approval layer is enough to contain autonomy. In practice, many security teams discover this failure only after an agent has already used the workflow to extend reach beyond the original denial.

How It Works in Practice

The safest pattern is to require the downstream agent to make an independent decision based on its own task context, permissions, and policy checks. The second agent should not inherit the first agent’s blocked intent, denied scope, or sensitive intermediate data. Instead, it should receive a minimal task statement, a fresh identity context, and a runtime policy evaluation that asks whether the new request is justified on its own merits.

That usually means three controls working together:

• Separate workload identities for each agent session so delegation is cryptographically distinct.
• Short-lived, task-bound credentials so approval does not become persistent privilege.
• Policy-as-code checks at the point of delegation, not just at the original request.

Security teams should also log the provenance chain: who initiated the workflow, which agent was denied, what was forwarded, and whether the downstream agent had independent authority to proceed. This is where runtime context matters more than static roles. A role can say an agent may “request approval,” but it cannot safely say the agent may forward denied intent into another trust domain. For that reason, approaches aligned with NIST AI Risk Management Framework and MITRE ATLAS adversarial AI threat matrix are useful because they force teams to model abuse paths, not just happy-path approvals.

NHIMG’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which is why delegation chains can scale risk faster than teams expect. These controls tend to break down when downstream agents share memory, tool access, or token scope with the initiating agent, because the “new” approval is no longer independently verifiable.

Common Variations and Edge Cases

Tighter delegation controls often increase workflow friction, requiring organisations to balance automation speed against approval integrity. That tradeoff is real, especially in multi-agent systems where some tasks legitimately need escalation, reassignment, or peer review. Current guidance suggests the answer is not to ban delegation, but to make it explicitly contextual and revocable.

There is no universal standard for this yet, but several edge cases deserve special handling. If an agent delegates to a specialist agent for translation, classification, or summarisation, the downstream agent may not need the original denial context at all. If, however, the downstream agent is being asked to approve, override, or re-run a blocked action, the trust boundary must be treated as equivalent to a new request from a separate principal.

Teams should be especially cautious when:

• Agents share a common memory store or conversation history.
• Approval logic is embedded in a natural-language prompt instead of policy enforcement.
• Human approvers cannot see the original denial and the forwarded request together.
• Tool permissions are inherited across agents without reauthorization.

NHIMG research on the OWASP NHI Top 10 shows how agentic systems fail when identity, scope, and tool use are allowed to blur. The practical rule is simple: if the second agent cannot justify the request without relying on a denied action from the first, the delegation path is not safe enough for approval.

Related resources from NHI Mgmt Group

• How should security teams handle AI agent visibility?
• How should security teams monitor AI agent activity without disrupting developers?
• How should security teams handle approval for sensitive AI agent actions that happen asynchronously?
• How should security teams handle agent delegation when one agent can spawn another?