From Monoliths to Swarms: A Study of Attack Surface Evolution in the Transition to Multi-Agent Web Systems
Abstract—Large Language Model (LLM)-based web agents are increasingly evolving from single-agent systems (SAS) to multiagent systems (MAS). While MAS can lead to improved task performance by decomposing complex tasks across specialized sub-agents, such role decomposition introduces new structural attack surfaces that are absent in SAS. This expanded attack surface remains poorly understood and inadequately categorized. To address this, we propose a taxonomy to categorize attack vectors specific to web-based MAS, accounting for vulnerabilities introduced or amplified by the involvement of multiple agents. We further present a test-bed WEBMASLAB to analyze web agent security against a fully external, web-only adversary. To isolate the effect of architecture, we keep the user task, tool surface, and browser substrate fixed, and compare single- and multi-agent setups. We evaluate three adversarial scenarios, across three conditions (baseline, prompt-hardened, and reasoning-enabled), including a novel MAS-specific Telephone Loop attack that exploits cross-agent delegation to create cyclical task loops.
Introduction. Large Language Model (LLM) agents are increasingly used to perform real-world tasks such as writing code, managing files, and browsing the web [1]. Web agents, that interact with browser environments, have shown particular promise and have moved from research demonstrations to real-world deployment [2], [3], [4]. The success of single-agent systems (SAS) in navigating complex tasks has spawned the development of multi-agent systems (MAS) in which each agent takes on a subset of tasks while collaborating with the others [5], [6]. Such collaboration has enabled MAS to function as a team whose members decompose problems into smaller components, leading to improved task performance [7]. Despite the promise of MAS, research on web agents is centered around SAS [8], [9], [10], [11]. Studies on MAS security [12], [13], [14] analyze generalist agent setups rather than web agents. Therefore, there is a research gap in evaluating the response of web-based MAS to known attack patterns like prompt injection [15] and distributed attacks [16], and emergent patterns that are unique to MAS.
Discussion / Conclusion. Architectural Penalty of MAS. Our findings indicate that while attack success is model-dependent in many cases, MAS does introduce structural vulnerabilities. In Vault Mirage, GPT-5.4 SAS largely resists compromise (11% ASR) unlike in MAS (69% ASR + 6% partial leak). We also find that MAS architectures alter how systems interact with malicious payloads. In Header Heist, prompt hardening applied to SAS reduces payload exposure by 40-75% because the agent preemptively avoids navigating to the malicious site. In contrast, identical hardening in MAS yields no such reduction. This implies that MAS configurations fragment contextual awareness (TV3 in Section 3.2), reducing agent ability to preemptively halt an attack. Non-Adversarial Failure Modes in MAS. Manual analysis of failures in Header Heist show that most failures in GPT-MAS (22/26) were caused by an agent erroneously concluding it lacked access to a tool (Appendix D.
Lines of inquiry this paper opens 24
Research framings built by reading the notes related to this paper — the questions it feeds into.
How do standardized protocols improve coordination in multi-agent systems?- Can message-layer defenses stop prompt injection across multi-agent networks?
- Can protocol bridges introduce new failure modes or security vulnerabilities?
- How does protocol mediation affect determinism in agentic function calls?
- What makes protocols better than free-form prompting for tool coordination?
- How do manipulative prompts exploit the length-accuracy vulnerability?
- How can simple prompt injection attacks extract reasoning trace content?
- Why does attack generation scale faster than defense engineering?
- Can existing web security defenses protect agents from content manipulation?
- Why does workflow position amplify malicious signals downstream?
- Why does workflow position amplify malicious signals in multi-agent relay chains?
- How do workflow-inspecting defenses fail when contamination enters at planning time?
- Do legitimate task signals exploit the same position and framing vulnerabilities as attacks?
- Can human inspection of auto-generated workflows catch harmful or incorrect API compositions?
- Why does pre-computed workflow generation work better than runtime tool discovery for data security?
- Can delegation prevent silent corruption in long delegated workflows?
- What makes planning-time attacks structurally invisible to downstream inspection?
- How does decomposing tasks prevent interference between planning and execution?