Multi-Agent Pipelines: The New Trust Boundary Problem

Enterprises are moving past single-agent LLM deployments. The architectures now taking hold are multi-agent pipelines: specialized agents orchestrated into structured workflows that pass intermediate outputs from one agent to the next. Planner to researcher to analyst to coder to validator. Frameworks built on LangGraph, CrewAI, AutoGen, and similar systems make this practical. The performance gains are real. So is a structural security gap that single-agent thinking never forced us to confront.

Once content or a compromised agent crosses an inter-agent boundary, downstream agents often treat it as trusted. There is rarely an explicit check. The result is a set of attack surfaces that do not exist—or exist only weakly—in isolated agents.

Recent research frames the problem cleanly. In “Adversarial Attacks in Multi-Agent LLM Pipelines: Unveiling Structural Vulnerabilities in Agentic AI Architectures” (arXiv:2608.00718, accepted to IEEE GLOBECOM 2026), the authors argue that the core vulnerability is the absence of boundary verification.

Boundary verification is the security primitive that enforces explicit validation of data as it crosses inter-agent boundaries. It covers four dimensions:

• Content: Is the payload data or executable instruction? Are the two kept separate?

• Identity: Does the sending agent present verifiable credentials, or is identity inferred only from routing position?

• Intent: Does the claimed execution intent match the authorized plan and the current state?

• State: Has shared or persistent memory been altered in ways that should invalidate downstream assumptions?

Without these checks, pipelines embed implicit trust assumptions. Those assumptions are not adversarially robust.

The paper’s analysis of 147 annotated production traces from GAIA and SWE-Bench showed that the resulting failure modes appear in ordinary, non-adversarial deployments and largely evade existing automated evaluation frameworks. When the same structural attacks were operationalized and run against identical pipeline configurations on GPT-5-mini, Claude Sonnet 4.5, and Kimi K2.5, success tracked pipeline structure far more than model capability. The vulnerability is architectural.

Content injection. Retrieved or intermediate content and executable instructions share the same context window with no enforced separation. An adversary who can influence any resource on the retrieval path embeds directive text. The receiving agent processes it as a legitimate task instruction. The corrupted context then propagates as trusted input to every subsequent agent. This was the most frequent class in the trace analysis.

Agent impersonation. Many systems identify agents by routing position rather than cryptographic or attestation-based credentials. During retries, re-invocations, or dynamic handoffs, a Sybil process can respond at the legitimate agent’s position. Downstream agents accept the forged output because the position matches. Identity is never independently verified.

Plan deviation. Execution plans are typically natural-language strings, not binding contracts. An agent (or an injected instruction) can emit a high-confidence “task complete” signal or a truncated plan. The orchestrator treats the signal as authoritative and skips remaining steps. There is no external enforcement that the realized plan remains a subset of the authorized plan.

Memory poisoning that propagates. Persistent or shared memory turns a one-time injection into lasting influence. A poisoned record written by one agent becomes part of the baseline context for later agents and later sessions. Because memory is treated as trusted state once written, the poison travels with every retrieval. Related work on collusive and query-only memory attacks shows that individually benign-looking fragments can combine into harmful behavior, and that standard prompt-injection defenses often miss these channels.

Cascading failures. Each of the above is locally plausible. The system-level damage appears only when the chain is examined end-to-end. A single compromised hop can instruct a database agent to export, a CRM agent to modify records, and a communication agent to exfiltrate—all while every individual action stays within its local policy. Detection that evaluates actions in isolation sees nothing wrong. The blast radius expands with the length of the pipeline.

These are not theoretical edge cases. They surface in production-style traces and transfer across model families when the pipeline topology stays fixed.

Guardrails, prompt filters, and output scanners calibrated for single-agent use assume a single trust boundary between the user (or external content) and the model. Multi-agent pipelines multiply boundaries and treat internal handoffs as lower risk. The math is unforgiving: a detection rate that works 70 percent of the time at one hop drops sharply across a five-agent chain. Collaboration itself can also raise the success rate of certain attacks because agents can combine capabilities that individually stay within safety limits.

Enterprises adopting these architectures inherit the single-agent security model by default. That model is no longer matched to the threat surface.

Pipeline-level defenses start by treating every inter-agent handoff as a potential trust boundary rather than an internal optimization.

Practical controls include:

• Cryptographic or attestation-based agent identity that travels with every message, independent of routing position.

• Strict separation of data and instruction channels, with content-type enforcement at each boundary.

• Binding of execution plans to verifiable state (signed plans, step-level authorization tokens, or external plan validators).

• Provenance tracking for memory writes so that retrieval can enforce source-authority rules rather than treating every stored record as equally trusted.

• Orchestration middleware that can reject or quarantine a handoff when content, identity, intent, or state checks fail.

Some of these ideas are already appearing in inter-agent trust protocols and governance toolkits. Most production frameworks still default to implicit trust.

Multi-agent pipelines are becoming the default for complex enterprise workloads—security operations, software engineering assistance, research synthesis, and business process automation. The performance argument is settled. The security argument is not.

Treating inter-agent boundaries as soft internal interfaces recreates, at higher speed and scale, the same class of failures that forced us to build network segmentation, zero-trust networking, and mutual authentication years ago. The difference is that the “packets” are now natural-language plans, intermediate reasoning traces, and persistent memory records.

The research is clear: adversarial vulnerability in these systems is fundamentally an architectural property. Model-level hardening alone will not close the gap. Explicit boundary verification of content, identity, intent, and state must become a first-class design requirement, not an afterthought bolted on after the first cascading incident.

Enterprises that design for verification at every handoff will keep the gains of multi-agent architectures. Those that continue to assume trust once content or an agent crosses the boundary will discover that the new trust boundary problem is already inside their pipelines.