When a developer builds a multi-agent pipeline, the primary security focus is typically on the boundary between the human user and the first agent. That boundary gets authentication tokens, API keys, rate limiting, and input validation. The communication between agents in the pipeline — once inside the trusted boundary — is often treated as an internal concern that doesn't need the same level of protection.

This mirrors the historical "hard shell, soft interior" network security mistake: strong perimeter controls, weak internal controls. The assumption is that anything inside the pipeline is already authorized. But "inside the pipeline" is exactly where a compromised component, a supply chain attack, or an insider with network access operates.

When an LLM agent receives a message via its input channel — whether a JSON task payload, a tool result, or a natural language instruction — it typically treats the content as accurate based on position in the prompt, not based on cryptographic proof of origin. If the message arrives in the part of the prompt designated for "orchestrator instructions," the agent treats it as orchestrator instructions.

This means the agent's trust model is entirely dependent on the integrity of the channel that delivers the message. There is no "show me your cryptographic identity" step in most current agent frameworks.

In a single-agent system, a compromised message affects one agent. In a multi-agent pipeline, a forged or tampered message delivered to the orchestrator may cascade into instructions dispatched to every sub-agent the orchestrator manages. The trust granted to orchestrator messages is transitive — sub-agents trust instructions that appear to come from the orchestrator, and the orchestrator's authority extends to everything downstream.

An attacker who can impersonate the orchestrator doesn't control one agent. They control the entire pipeline.