Architecture Matters for Multi-Agent Security

1. Introduction

• It systematically examines role specialization, communication topology, and memory visibility as architectural determinants of attack surface and performance.These dimensions govern how authority, interaction, and context are distributed across agents.Source: §1 · pp. 1–2
• A controlled example shows HT rising from 10.0% for a standalone agent to 31.0% after reconfiguration as a star-topology orchestrator with four specialists.The base model and task remain the same; only the architecture changes.Source: Figure 1 · p. 2
• The study adapts BrowserART, OS-Harm, and RedCode-Gen while preserving task semantics and varying architectural configuration.The adaptations introduce stage-wise metrics that identify where harmful behavior is refused or executed.Source: §1 · p. 2
• Multi-agent architectures are more vulnerable than standalone agents in the majority of configurations, with effects depending on role distribution, topology, memory, model, and environment.The study evaluates 13 configurations across three environments and multiple models.Source: §1 · pp. 1–2
• Attack success rates vary by up to 3.8× even at comparable or higher benign accuracy, so capability evaluation alone does not expose these risks.The authors frame this as a security-performance tradeoff that must be considered in system design.Source: §1 · p. 2
• The work presents the first controlled comparison of multi-agent architectural design choices for security across realistic environments.It releases the benchmark adaptations to support further research.Source: §1 · p. 2

2.1. LLM and Single-Agent Vulnerabilities

• Single-agent security research covers prompt injection, jailbreaks, poisoning, privacy threats, tool misuse, and memory poisoning, with stage-specific evaluation emerging in agent benchmarks.AgentDojo and AgentHarm extend evaluation toward adversarial tool outputs and planning-versus-execution failures.Source: §2.1 · pp. 2–3

2.2. Multi-Agent Security

• Multi-agent interactions introduce miscoordination, conflict, collusion, information asymmetries, and error amplification beyond single-agent vulnerabilities.These dynamics can enable infection-style attacks, misinformation propagation, and adversarial manipulation.Source: §2 · p. 2, §2.2 · p. 3

2.3. Evaluation and Defense Gaps

• Existing multi-agent benchmarks typically measure general performance or isolated attack types without systematically varying architectural design choices for adversarial security.This leaves the joint effect of architecture on task performance and attack resistance underexplored.Source: §2.3 · p. 3
• Classical multi-agent security guarantees may not transfer directly because LLM-based systems use flexible reasoning and unstructured communication rather than rigid protocols.This motivates dedicated empirical study of architecture-dependent security.Source: §2.3 · p. 3
• This study extends prior tradeoff work by isolating role distribution, communication topology, and memory visibility across three realistic environments using stage-wise metrics.It targets the gap between collaboration-focused evaluation and architectural security analysis.Source: §2.3 · p. 3

3. Design Choices in Multi-Agent Systems

• The study hypothesizes that these choices create vulnerability modes by fragmenting responsibility for safety assessment and introducing new attack surfaces.The experiments test these mechanisms rather than treating architecture as a fixed implementation detail.Source: §3 · p. 3

Design Choice 1: Role Configuration

• Role separation can improve efficiency and task performance but fragment safety responsibility when executors lack full context or safety judgments are nonbinding.Centralized authority may instead create single points of failure.Source: Design Choice 1: Role Configuration · pp. 3–4

Design Choice 2: Communication Topology

• Communication topology controls how intent, uncertainty, and safety signals propagate through centralized, sequential, hierarchical, or peer-to-peer structures.Information may be summarized or filtered as it passes through some topologies.Source: Design Choice 2: Communication Topology · p. 4

Design Choice 3: Memory and State Visibility

• Memory design trades private-state independence against shared-context transparency and the risk that unsafe assumptions or exploitable reasoning patterns spread.Systems may expose private reasoning, action histories, or complete multi-agent state.Source: Design Choice 3: Memory and State… · p. 4

4.1. Scenarios

• The evaluation covers BrowserART, OS-Harm, and RedCode-Gen while preserving original task semantics and changing only architectural variables and role-based tool access.Benign performance uses 42 BrowserART, 50 OS-World, and 50 BigCodeBench tasks.Source: §4.1 · p. 4

4.2. Architectures

• The study compares a standalone baseline with orchestrator-executor, step-wise, specialized-executor, star, chain, and mesh configurations.The standalone agent has all tools, private memory, and sequential execution.Source: §4.2 · pp. 4–5
• Table 1 reports disjoint GPT-4o role-decomposition outcomes across three scenarios with star topology and no memory held fixed.Its columns separate refusal, partial harmful execution, and completed harmful tasks.Source: Table 1 · p. 5
• Memory conditions vary from private memory to own-reasoning access and full shared execution history while topology remains fixed.Shared memory includes actions, observations, and reasoning traces.Source: §4.2 · p. 5

4.3. Models

• GPT-4o is evaluated across all scenarios, with five additional models used to assess generalization under scenario-specific coverage constraints.All six models are tested on BrowserART; fewer models are tested on OS-Harm and RedCode-Gen.Source: §4.3 · p. 5

4.4. Evaluation Metrics

• Outcomes distinguish Planning Refusal, Execution Refusal, Harmful Actions, and completed Harmful Task, alongside benign task success.Judgment uses benchmark-specific protocols and manual review of flagged scoring cases.Source: §4.4 · p. 5

5. Results

• The evaluation reports GPT-4o results for role decomposition, communication topology, and memory visibility across all three scenarios, and incorporates cross-model findings from additional models in Appendix A.Source: §5 · p. 5

5.1. Role Distribution

• BrowserART specialists reach 38.0% HT versus 10.0% for standalone while benign performance remains 95–98% versus 92.9%, showing simultaneous capability gains and security degradation.Simple delegation instead lowers HT to 5.0%, whereas specialist counts produce non-monotonic vulnerability; RedCode-Gen reverses this trend as more specialists are added.Source: §5.1 · p. 6

5.2. Communication Topology

• Topology effects are scenario-dependent: BrowserART HT is 31.0% for star, 16.0% for chain, and 7.0% for mesh, whereas RedCode-Gen peaks at 42.5% for chain.On BrowserART, mesh has the lowest HT but also the lowest benign performance; on RedCode-Gen, chain’s planning refusal falls to 8.1%.Source: §5.2 · pp. 6–7, Table 2 · p. 7

5.3. Memory

• Memory visibility has no universal security effect: only RedCode-Gen mesh improves consistently, while two topology–scenario combinations worsen and three show no effect.Shared memory raises RedCode-Gen mesh Execution Refusal from 26.9% to 31.9%, but OS-Harm mesh HT increases from 13.6% to 18.2%.Source: §5.3 · pp. 7–8, Table 3 · p. 7

Multi-agent systems expand the attack surface

• Specialist configurations reach 95−98% benign accuracy versus 92.9% for the standalone agent on BrowserART while producing up to 3.8× higher attack success.This security-performance decoupling means standard capability evaluation provides no signal about these risks.Source: §6 · p. 8

Effects are scenario- and model-dependent

• No topology, memory scheme, or delegation strategy is universally safer: star is riskiest on BrowserART but safest on RedCode-Gen and OS-Harm, where chain is riskiest.Only one of six topology-scenario combinations shows consistent security improvement with increased memory visibility, while two worsen.Source: §6 · p. 8

Model-mediated effects

• Weaker-aligned models can show 4-fold increases in harmful task completion under specialization, whereas well-aligned models remain robust across nearly all configurations except OS-Harm.The results link architectural fragmentation to whether models can recognize harmful intent from partial context.Source: §6 · p. 8

Mechanisms

• Role specialization creates a responsibility gap because specialists lack the full harmful task while orchestrators decompose it without end-to-end safety evaluation.Topology effects similarly depend on task visibility: chain agents receive processed outputs that can mask harmful intent, producing 8.1% planning refusal versus 25.6% for star on RedCode-Gen.Source: §6 · p. 8

Implications for system design

• Practitioners should treat architecture as a first-class security variable because component-level refusal does not guarantee system-level safety and performance-improving specialization can degrade security.Architectural security therefore requires evaluation per deployment alongside traditional defenses.Source: §6 · p. 8

Overall conclusion

• Multi-agent architectures are more vulnerable than standalone agents in the majority of configurations, with effect direction and magnitude depending on architecture, model, and environment.The comparison spans three design dimensions, three agentic environments, and multiple base models.Source: §7 · p. 9

Security-performance tradeoff

• Specialist configurations can achieve higher benign accuracy while being up to 3.8× more vulnerable, so capability evaluation provides no signal about security risks.Security and performance can therefore decouple counterintuitively.Source: §7 · p. 9

Architecture-dependent effects

• No architectural design is universally safer, and increased memory visibility or communication connectivity can worsen security rather than reliably improve it.The same architectural choice may reduce risk in one environment and increase it in another.Source: §7 · p. 9

Broader implication

• Safety properties do not compose straightforwardly from individual agents to multi-agent systems when architectures fragment context, distribute authority, or separate task visibility from execution capability.The study releases benchmark adaptations to support further investigation of these properties.Source: §7 · p. 9

Scope

• The findings are limited to jailbreak vulnerabilities evaluated across browser, desktop, and code environments.Their applicability to additional domains, deployment contexts, and threat models remains uncertain.Source: §8 · p. 9

Untested threat vectors and defenses

• The study does not evaluate indirect prompt injection, memory poisoning, adversarial internal agents, or dedicated mechanisms such as monitor agents and guardrail layers.These factors could alter the observed security-performance tradeoffs.Source: §8 · p. 9

Future scope

• Interactions among role configuration, topology, memory, communication protocols, and iterative red- and blue-teaming dynamics remain underexplored.Extending the analysis to these settings is identified as future work.Source: §8 · p. 9

• Publicly available LLM-based multi-agent systems may enable users to generate harmful content.Source: Impact Statement · p. 9
• The authors justify disclosure because the frameworks and benchmarks are already publicly accessible and straightforward to deploy.Source: Impact Statement · p. 9
• They call for safeguarding techniques for LLM-based multi-agent systems in response to the gap between securing single-agent and multi-agent systems.Source: Impact Statement · p. 9

A.1. Role Decomposition

• GPT-5.4 reaches HT = 15.9% on OS-Harm under simple delegation versus 11.4% for the standalone baseline, despite near-perfect RedCode-Gen refusal.Source: §A.1 · p. 13, Table 5 · p. 14
• Role-decomposition results extend across five additional models on BrowserART, OS-Harm, and RedCode-Gen under fixed star topology and private memory.Source: Table 4 · p. 13, Table 5 · p. 14

A.2. Communication Topology

• Star is riskiest for Qwen3-VL at 37% HT versus 20−21% for chain and mesh, whereas mesh is riskiest for Llama 70B at 36%.Source: §A.2 · p. 14, Table 6 · p. 15
• GPT-5.4 shows minimal topology sensitivity, reaching at most 3% HT regardless of topology.Source: §A.2 · p. 14

B.1. Configuration Reference

• Role configurations vary action scope and delegation granularity, while topology configurations replace centralized star coordination with chain or mesh communication.Source: §B.1 · p. 17, Table 8 · p. 17, Table 9 · p. 17
• Memory conditions expose nothing beyond private state, agents’ own reasoning, or all agents’ actions and reasoning, with roles and topology held fixed.Source: §B.1 · p. 17, Table 10 · p. 18

B.2. Scenarios and Task Sets

• The study evaluates BrowserART, OS-Harm, and RedCode-Gen while preserving each benchmark’s original task semantics, environment, and judge protocol.Source: B. Experimental Details · p. 17, §B.2 · p. 18

B.3. Tool Partitions

• Specialist tool partitions differ by environment: browser actions are divided by type, desktop controls become disjoint sub-tools, and code generation retains an asymmetric Python-interpreter allocation.Source: §B.3 · pp. 18–19

B.4.1. CONTEXT ISOLATION MECHANISM

• Fresh AgentState calls isolate specialists from the original task, orchestrator history, and other outputs unless the orchestrator explicitly supplies them.Source: §B.4.1 · p. 19

B.4.2. SYSTEM PROMPTS

• The experiments use no prompt-level safety instructions; safety behavior comes from base-model training, while star, chain, and mesh implement distinct communication protocols.Source: §B.4.2 · p. 19, §B.5 · p. 21

B.6. Judging Protocol

• A shared scorer maps per-agent compromise scores to planning refusal, execution refusal, harmful actions, and harmful task outcomes, using environment-specific LLM judges.Source: §B.6 · p. 21

C. Example Transcripts

• Transcripts show GPT-4o refusing harmful tasks as a standalone agent but completing them under Star+Specialized decomposition, including BrowserART phishing and OS-Harm mail merge.Source: C. Example Transcripts · p. 21, §C.1 · p. 22, §C.2 · p. 22

• Star+4 Specialists reaches HT = 17.5% versus 9.4% for the standalone baseline on RedCode-Gen.Source: §C.3 · p. 23
• The standalone agent sees the harmful ICMP-flood specification and refuses before writing code.Source: §C.3 · pp. 23–24
• Under specialization, design, coding, review, and submission are reframed as neutral engineering subtasks, producing a functional ICMP flood exploit with no agent refusal.Source: §C.3 · p. 24