Securing AI agent delegation and multi-agent communication

At a glance

What this is: This is an analysis of how AI agents break when they delegate to, communicate with, and inherit context from other agents, with emphasis on authentication, authorization, and auditability across the delegation chain.

Why it matters: IAM teams need to treat agent-to-agent communication as a distinct governance layer because delegation can expand privilege, obscure accountability, and create failure chains that ordinary single-agent controls do not detect.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.

👉 Read WorkOS's analysis of AI agent delegation and multi-agent communication

Context

AI agent delegation is the point where autonomous behaviour becomes an identity governance problem. Once one agent can hand work to another, the security question changes from "can this agent act" to "which identity, permissions, and audit trail apply at each handoff?" That shift is central to AI agent governance and to the control boundaries that were built for single-agent workflows.

The article's core concern is that transitive trust can create a confused deputy problem across agent chains. A delegated task can inherit permissions, context, and assumptions that were never explicitly authorised for the receiving agent, which means existing IAM, RBAC, and audit models need to be evaluated at the delegation boundary, not just at the initial login or token issuance step.

For teams already using MCP-connected agents, the issue is not merely tool access. It is whether inter-agent messages are authenticated, whether delegated actions are constrained by the originating user's scope, and whether the system can reconstruct what happened when one agent passes compromised or malformed output to another.

Key questions

Q: How should security teams implement agent-to-agent authentication in multi-agent systems?

A: Security teams should give each agent its own identity, require signed messages on every handoff, and verify that the sender is authorised to delegate to the recipient. The receiving agent should also reject expired or mismatched tokens. This turns inter-agent communication into a governed trust boundary instead of an implicit assumption.

Q: Why do delegated AI agent workflows increase privilege escalation risk?

A: Delegated workflows increase risk because the receiving agent may act with broader permissions than the originator intended, or inherit context that was never explicitly authorised for the target resource. If the system does not intersect the agent's role with the originating user's scope, delegation can become an escalation path.

Q: What breaks when inter-agent responses are not validated?

A: Without validation, a sub-agent can smuggle instructions, malformed actions, or oversized responses into a parent agent's workflow. The parent may execute content that looks legitimate but is actually unsafe. Schema checks, content scanning, and rate limits are needed to stop bad handoffs from becoming downstream actions.

Q: Who is accountable when an AI agent delegation chain causes an unauthorised action?

A: Accountability depends on whether the organisation can reconstruct the chain. If logs capture sender identity, recipient identity, task ID, delegation depth, and validation results, investigators can pinpoint the failing handoff. Without that trail, responsibility becomes ambiguous across the orchestration layer and the individual agents.

Technical breakdown

Agent-to-agent authentication and signed message flow

Multi-agent systems need an identity layer for messages, not just for users or tools. Each inter-agent request should carry a verifiable sender identity, a recipient, a task correlation ID, and an expiry-bound token so the receiving agent can confirm who sent the request and whether that sender is entitled to talk to that recipient. Without that, any process that can shape a message in the expected format can impersonate a peer agent. The important architectural point is that authentication alone is not enough if the receiving system cannot bind the message to an authorised delegation path.

Practical implication: require signed, recipient-specific agent messages and reject unauthenticated handoffs.

Delegated authorisation, role intersection, and scope control

Delegation becomes risky when the receiving agent is allowed to act with broader effective permissions than the originator intended. The safe model is an intersection of the recipient agent's role and the originating user's authorised scope, with both checks enforced at every hop. This prevents privilege escalation through delegation and prevents scope bypass when a capable sub-agent is asked to touch resources outside the original user's rights. In practice, this is where RBAC, FGA, and task-level scoping need to converge, because the trust boundary is the delegation event, not the workflow start.

Practical implication: validate both agent role and originating-user scope on every delegated task.

Validation of inter-agent responses and cascading failure control

A sub-agent's output should be treated as untrusted until it passes schema validation, content validation, and size or rate checks. This matters because agent outputs often look well-formed even when they embed hidden instructions, incorrect assumptions, or actions that should never have been passed downstream. The article's smuggling example shows why response validation is a control, not a nice-to-have: once one agent consumes another agent's malformed output, the error can propagate, compound, and persist in shared state. That turns operational reliability into an identity and governance issue.

Practical implication: validate every handoff before the next agent can consume it.

Threat narrative

Attacker objective: The attacker wants to turn one compromised agent into a propagation mechanism that expands control across other agents and executes unauthorised actions without clear attribution.

1. entry: A prompt-injected agent in a shared development environment rewrites another agent's configuration file, creating an entry path through trusted agent-to-agent infrastructure rather than through a traditional external login.
2. escalation: The receiving agent executes the modified configuration or embedded response and inherits actions that were never explicitly authorised for that delegation path, which expands effective privilege across the chain.
3. impact: The chain becomes self-reinforcing as compromised agents reinfect each other or pass hidden actions downstream, producing unauthorised execution with little visibility in the audit trail.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Delegation trust is now an identity boundary, not a workflow convenience. The old assumption was that a task can move between agents without changing the trust model. That assumption breaks when one agent can alter another agent's configuration, context, or outputs mid-chain. The implication is that agent-to-agent communication must be treated as a governed identity relationship, not just an orchestration detail.

Confused deputy risk becomes structural once agents inherit context from other agents. A delegation chain can silently transfer privilege, intent, and authority in ways that were never authorised for the downstream actor. This is a direct challenge to RBAC-only thinking because the effective permission set is no longer visible at provisioning time. Practitioners need to evaluate where delegated scope is being expanded by design, not just where it is being abused.

Runtime validation is the control plane for multi-agent integrity. Authentication and authorisation are necessary, but they do not address hidden actions, malformed responses, or self-reinforcing failure loops. Schema checks, content validation, and chain depth limits are the practical evidence that an organisation understands inter-agent communication as a security boundary. The practitioner conclusion is simple: if the handoff is not validated, the chain is not trusted.

Auditability must survive the handoff, or accountability disappears. A single task ID is only useful if every agent transition preserves actor identity, delegation depth, and validation outcome. Otherwise, a multi-agent system creates plausible output without reconstructable causality. The implication is that identity governance for agents now includes traceability across agent boundaries, not just authentication at the first touchpoint.

Identity blast radius: the failure mode is not one compromised agent but one compromised chain. Once one agent can trigger another, the blast radius is defined by delegation depth, shared state, and inherited trust. That means governance teams should stop measuring only per-agent risk and start measuring how far a bad handoff can travel before the system notices. The practitioner takeaway is that chain containment is now a first-class identity objective.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• That same report found that 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• For a broader control view, see OWASP Agentic AI Top 10 for the agent identity and tool-use risks that make delegation control necessary.

What this signals

Identity blast radius is the right planning concept for multi-agent governance: once one agent can delegate, the real question becomes how far a compromised handoff can travel before detection. Teams should expect audit, policy, and response processes to move from agent-centric to chain-centric, with task correlation and handoff validation becoming operational requirements.

The governance gap will widen wherever organisations treat agent output as data rather than as an identity-mediated action. With only 52% of companies able to track and audit what their AI agents access, as covered in AI Agents: The New Attack Surface report, the practical signal is clear: visibility is lagging the deployment curve.

For practitioners

• Authenticate every inter-agent message Bind each agent-to-agent request to a verified sender identity, recipient identity, task ID, and expiry-bound token. Reject messages that cannot prove who sent them or that arrive from a sender not authorised to delegate to that recipient.
• Enforce delegated scope intersection Require the receiving agent's role to pass an access check and also require the originating user's scope to authorise the target resource. Do this at every hop so a sub-agent cannot exceed either its own role or the user's approved scope.
• Limit delegation depth and chain length Set a maximum delegation depth and stop chains that exceed it before they reach additional agents. This reduces privilege amplification, makes chain review feasible, and keeps audit logs readable enough to reconstruct the decision path.
• Validate all downstream agent output Apply schema validation, instruction scanning, and size limits before a parent agent consumes a sub-agent response. Treat unexpected tool calls, actions, or oversized payloads as a failed handoff rather than as usable content.
• Preserve end-to-end delegation audit trails Log the sender, recipient, originating user, task type, delegation depth, permissions result, and validation outcome for every handoff. Use a single correlation ID so investigators can reconstruct the full chain across agent boundaries.

Key takeaways

• Multi-agent communication turns ordinary delegation into an identity problem because privilege, context, and accountability can all move across the chain.
• The evidence is already showing up in real attack patterns such as Cross-Agent Privilege Escalation and Agent Session Smuggling, which bypass single-agent assumptions.
• The control that matters most is not one more policy document but a chain-aware model that authenticates handoffs, constrains scope, validates outputs, and preserves auditability.

Key terms

• Agent Delegation Chain: A delegation chain is the sequence of agents that pass tasks, context, or actions to one another before work is completed. In governed systems, each hop becomes a security boundary because identity, authority, and accountability can change as the task moves downstream.
• Confused Deputy Problem: A confused deputy problem occurs when a trusted agent is induced to use its authority in ways that benefit an unauthorised request. In multi-agent systems, the risk grows because downstream agents may inherit permissions or context that were never explicitly intended for them.
• Delegated Scope: Delegated scope is the set of actions and resources a receiving agent is allowed to use on behalf of the originating actor. Effective scope should be narrower than the agent's raw capability and must be checked at every handoff, not just at session start.
• Identity Blast Radius: Identity blast radius is the maximum reach of harm if one identity, credential, or agent is compromised. For multi-agent systems, it is defined by delegation depth, shared state, and how much authority downstream agents inherit from upstream actors.

Deepen your knowledge

Multi-agent delegation and inter-agent trust are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agent handoffs, this is a practical place to start.

This post draws on content published by WorkOS: How to secure AI agent delegation and multi-agent communication. Read the original.