Agent-to-Agent Delegation

Agent-to-agent delegation is the handoff of work from one AI agent to another, often across different tools or identity contexts. It expands the governance boundary because the original actor no longer controls every action, and inherited permissions can create risk that the first approval never covered.

Expanded Definition

Agent-to-agent delegation describes a controlled handoff where one NIST AI Risk Management Framework-aligned agent passes a task to another agent that may operate in a different tool, tenant, or identity context. In NHI governance, the key issue is not the handoff itself but the transfer of execution authority, secrets, and policy obligations that can outlive the first agent’s original intent.

Definitions vary across vendors because some products treat delegation as a workflow step, while others treat it as an identity event or an orchestration event. In practice, the boundary matters: if the second agent inherits tokens, API keys, or role membership, the delegation becomes an identity decision as much as an automation decision. That is why it maps closely to agentic threat models in the OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework.

The most common misapplication is treating delegation as a benign internal reroute, which occurs when the receiving agent is granted broader credentials than the original approval covered.

Examples and Use Cases

Implementing agent-to-agent delegation rigorously often introduces latency and policy friction, because each handoff needs its own authorization, logging, and boundary checks. Organisations must weigh automation speed against the risk of uncontrolled privilege inheritance.

• A coding agent completes a ticket, then delegates test execution to a separate QA agent with read-only repo access and no deployment rights.
• A support agent escalates a customer request to a billing agent, but the second agent receives only the minimum account-scoped permissions needed to resolve the case.
• An orchestration agent hands a remediation task to a security agent after a policy trigger, while preserving an audit trail of who approved the transfer and which Non-Human Identity was used.
• A procurement agent delegates vendor verification to another agent that can query records but cannot create or approve payments, reducing the chance of overreach.
• A SOC workflow routes suspicious prompt activity to a containment agent, following lessons reflected in AI LLM hijack breach reporting and agentic control guidance.

Why It Matters in NHI Security

Agent-to-agent delegation expands the attack surface because each handoff can multiply identity exposure, secret reuse, and policy drift. NHI security teams should treat the receiving agent as a distinct governed principal, not as a continuation of the original session. That means checking whether the destination agent has standing access, whether the transfer is time-bound, and whether inherited credentials are automatically revoked after task completion.

This is especially important because NHI programs already struggle with privilege sprawl. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which makes delegated access particularly dangerous when a second agent inherits more authority than required. The same problem appears in agentic abuse patterns documented by OWASP NHI Top 10 and the broader controls philosophy in NIST AI Risk Management Framework.

Organisations typically encounter the consequences only after a delegated agent overreaches, misroutes a secret, or performs an action the first approval never covered, at which point agent-to-agent delegation becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• AI Agent Authentication
• When does agent delegation become an access-control problem?
• What breaks when audit logs do not capture agent delegation and decision context?
• Who is accountable when an AI agent delegation chain causes an unauthorised action?