Secure Multi-Agent
Workflows

Single-agent deployments are the simpler case. A well-scoped, well-instrumented agent running a defined task against a defined set of tools is a contained problem. Multi-agent workflows are fundamentally different: they compose multiple agents into a coordinated system where each agent can invoke others, pass data through inter-agent messages, and take actions whose authorization was determined by an upstream agent the downstream agent cannot independently verify. The security properties of the system are no longer determined by the security of the weakest individual agent — they are determined by the security of every trust transition in the chain. This chapter describes how to secure those transitions. The underlying risk pattern maps to OWASP Agentic ASI08 (Agent Communication Integrity Failures) and ASI06 (Orchestrator Manipulation), and the controls here build directly on the multi-agent tracing and least-privilege scoping infrastructure from earlier chapters.

Why trust does not transfer automatically between agents

The intuitive assumption in multi-agent systems is that if the orchestrating agent is trusted, its sub-agents can be trusted transitively — the orchestrator was authorized, so the work it delegates must also be authorized. This assumption is wrong in security terms, and the consequences of relying on it are significant. An orchestrator agent can be compromised by prompt injection, manipulated by a rogue peer agent, or simply issue instructions outside its own authorized scope. If the sub-agent that receives those instructions executes them without independent authorization, the sub-agent has effectively laundered the orchestrator's compromise into privileged action. The correct model is that trust does not transfer at agent boundaries: each agent independently verifies the authorization of the instruction it receives, issues its own scoped credentials for the actions it takes, and does not treat provenance from an agent peer as automatically equivalent to provenance from a human principal. This is what Anthropic's model specification describes as agents maintaining safe behavior regardless of the instruction source, including other agents.

The four security primitives for multi-agent systems

Orchestrator security: the highest-value attack surface

The orchestrator is the highest-value compromise target in a multi-agent system. If an attacker can manipulate the orchestrator — through prompt injection in its context, through a malicious sub-agent sending crafted responses, or through manipulation of the task description it receives — they gain control over the entire downstream workflow. The orchestrator's scope of action is typically the union of all the scopes of its sub-agents, which means a compromised orchestrator has access to the full attack surface of the system. For this reason, orchestrators should apply the same prompt injection defenses as any other agent (provenance-tagged inputs, trust-tier-gated actions), but with heightened vigilance: the orchestrator's context regularly includes outputs from sub-agents, which are themselves a source of potentially injected content. An orchestrator that treats sub-agent outputs as fully trusted inputs is a single-hop escalation path to full workflow compromise.

The defensive principle is to treat sub-agent responses with the same skepticism as any other external content: validate them against expected schemas, apply provenance labels (sub-agent output is not human principal input), and refuse to execute instructions embedded in them without explicit authorization. The Anthropic multi-agent guidance makes this explicit: an orchestrator should not assume that instructions arriving through agentic pipelines are legitimate just because they arrive on an expected channel.

Authorization at handoff points

Every point at which one agent passes work to another is an authorization decision point. The three questions to answer at each handoff are: Is the sending agent who it claims to be (authentication)? Is it authorized to request this task (authorization)? Is the task description it is passing consistent with what it was authorized to do (scope validation)? The third question is the one most often skipped: teams verify agent identity and check authorization in general, but don't validate that the specific task being delegated is within the scope of what was approved. An orchestrator authorized to "analyze customer data" should not be able to delegate a task to a sub-agent to "export customer data to an external endpoint" — the delegation has changed the action type, and the authorization decision needs to reflect that change.

Human oversight in multi-agent workflows

The human-in-the-loop design principles from the guardrails chapter become more complex in multi-agent systems because the action that needs human review may be several agent hops removed from the human-facing interface. A multi-agent system that routes all interrupts through the orchestrator to a human interface is operationally simpler but may suppress critical signals from sub-agents that have detected anomalies the orchestrator does not know about. The architectural requirement is that any agent in the system can escalate to human oversight directly, not just via the orchestrator, and that escalations from sub-agents include enough context (agent identity, task description, the specific action that triggered the escalation, and enough trace to reconstruct why) for the human to make an informed decision.