Trust propagation and structural containment in Multi-agent LLM pipelines

Paper · arXiv 2609.17648 · Published September 15, 2026
Multi-Agent Architectures

Abstract— Multi-agent LLM systems increasingly automate tasks involving agents with different levels of privilege, creating a security risk in which a compromised low-privilege agent can influence a higher-privilege agent and trigger an unauthorized action. We study attack propagation in a four-agent LangGraph pipeline comprising a Supervisor, Researcher, Validator, and Executor. We evaluate shared-memory poisoning and indirect prompt injection through a forged approval embedded in a retrieved document. We compare the Validator’s judgment with an independent authorization layer using task-bound signed tokens and a separately verified policy oracle. Our contribution is an empirical study of attack propagation, a component-level ablation of the authorization boundary, and the Judgment Bypass Rate (JBR), which measures compromise at the attacked agent rather than at the final action. Across three seeds and 60 labeled tasks, memory poisoning reaches execution in every undefended trial. With authorization enabled, it achieves 100 % JBR but 0 % Unsafe Action Rate, showing that the Validator can remain compromised while execution is contained.

Introduction. I. INTRODUCTION Multi-agent large language model (LLM) systems increasingly combine specialized agents, such as orchestrators, retrieval agents, reasoning agents, and execution agents, to perform tasks on behalf of users [1]. This separation allows low-privilege agents to retrieve information, review agents to evaluate it, and high-privilege agents to perform consequential actions. However, this delegation chain introduces a security risk. The confused deputy problem, first described by Hardy, occurs when a less-privileged component causes a more-privileged component to misuse authority it legitimately holds [2]. A similar pattern can arise when an agent retrieves, summarizes, and forwards untrusted content to a more privileged agent. Prior work has shown that LLMs can be manipulated through adversarial prompts and indirect prompt injection [3], [4], including in tool-using agents where injected content can influence behavior despite an unchanged system prompt [5].

Discussion / Conclusion. We evaluate the pipeline using controlled ablations on a single codebase, keeping agents, graph topology, prompts, task corpus, and attack injections fixed while varying only the protection layers. T0 disables the token check and policy oracle, whereas T1 enables both. We use 60 tasks (36 safe, 24 unsafe) across three seeds (1, 7, and 42), giving n = 180 trials per cell unless otherwise stated. Because UAR is 0% for most defended conditions, we focus on FPR, LTC, F1, and JBR. Values are means across three seeds, with 95% confidence intervals computed as Student’s t intervals (df = 2). Intervals are reported over seeds because trials within a seed share the same task corpus and are not independent. A. Attack Effectiveness At T0, memory poisoning succeeds in every trial: the compromised Validator forges an approval and the resulting action is executed. With T1, UAR falls to 0% while JBR remains at 100%. Thus, the Validator remains compromised, but the Executor independently prevents unauthorized action (Table I). Agent hijacking produces a different outcome.

Lines of inquiry this paper opens 24

Research framings built by reading the notes related to this paper — the questions it feeds into.

Can single-point security defenses protect multi-agent systems from multi-step attacks? How can infrastructure records verify actual agent behavior? How should agent systems validate and persist generated code artifacts? How can we detect and prevent harm propagation through multi-agent delegation workflows? Why do agents falsely report success on failed tasks? How do coordinated agents balance protocol compliance with reward maximization? How does misalignment propagate through agent communication networks? Do multi-agent systems introduce security vulnerabilities that single-agent architectures avoid? How do we enforce security boundaries in evaluation environments?