This is the fifth and final post in our series drawing on a systematic review of 49+ arXiv publications from Q1 2026 on agentic AI security. Posts 1 through 4 covered the alignment gap at the tool-call layer, MCP monoculture risk, active supply chain compromise, and the emergent Viral Agent Loop. This post examines the finding that ties them together architecturally — the counterintuitive result that multi-agent systems, designed in part to limit the exposure of any single agent, produce greater total data exposure than single-agent equivalents. The primary sources are AgentLeak: A Full-Stack Benchmark for Privacy Leakage in Multi-Agent LLM Systems (arXiv:2602.11510), AgenticCyOps (arXiv:2603.09134), Security Considerations for Multi-Agent Systems (arXiv:2603.09002), and Human Society-Inspired Approaches to Agentic AI Security: The 4C Framework (arXiv:2602.01942).
The reasoning behind distributing work across multiple specialized agents is sound on its face. A single agent with access to patient records, billing data, clinical notes, and scheduling information is a large blast radius waiting to happen. Split that work across four specialized agents — each touching only its own domain — and any single compromise is contained. The healthcare agent sees only clinical data. The billing agent sees only financial records. The principle is the same one that drives network segmentation, least-privilege access, and role-based access control in traditional systems.
The AgentLeak paper (arXiv:2602.11510) tested whether this reasoning holds empirically. Across 1,000 scenarios spanning healthcare, finance, legal, and corporate domains, it measured privacy leakage in single-agent versus multi-agent configurations. The per-channel finding confirmed the intuition: individual agents in multi-agent systems did leak less than a monolithic agent would. But total exposure — the aggregate of everything the system leaked across all channels — went up by 60%.
The architecture designed to contain exposure was expanding it. Understanding why requires looking at what multi-agent systems actually create when they distribute work: inter-agent communication channels, shared memory stores, and orchestration layers — none of which were designed as security boundaries, and none of which are monitored as such.
Increase in total data exposure when moving from single-agent to multi-agent configurations — even as per-channel leakage falls. The reduction in individual agent exposure is real. The unmonitored inter-agent communication channels that coordination requires more than offset it. (AgentLeak, arXiv:2602.11510)
Three Mechanisms Behind the Paradox
The 60% figure is not an accident of methodology. It reflects three structural properties of multi-agent systems that combine to produce aggregate exposure greater than the sum of their parts.
The unmonitored inter-agent channel
When agents coordinate, they communicate. That communication happens through channels — API calls, message queues, shared context windows, memory reads and writes — that conventional security monitoring was not built to observe. Security teams instrument API calls from applications to databases. They monitor network egress from servers. They log user-facing outputs. They do not, in current practice, instrument the natural-language messages that a scheduling agent passes to a billing agent in the course of coordinating an appointment confirmation.
Those inter-agent messages carry context. A scheduling agent summarizing a patient’s appointment history for a billing agent will include details about the nature of the appointments — details that, in aggregate, constitute sensitive medical information moving through a channel nobody is watching. The AgenticCyOps paper (arXiv:2603.09134) identifies tool orchestration and memory management as the primary trust boundaries in enterprise multi-agent deployments and the least instrumented. The gap between what gets monitored and what actually carries sensitive data is where the 60% lives.
The Aggregation Effect in Practice
Individual agents, doing their jobs faithfully, pass summaries rather than raw data. A billing agent summarizes a patient’s payment history. A clinical agent summarizes their diagnosis trajectory. A scheduling agent summarizes their appointment patterns. Each summary is a legitimate, scoped output from an agent doing exactly what it was designed to do.
When an orchestrator agent receives all three summaries to coordinate a downstream response, it now holds a synthesized record more comprehensive than any individual agent was authorized to construct. When that combined summary is passed to the next stage, stored in shared memory, or written to an audit log, the aggregated sensitive profile propagates through channels that were never designated as high-security data paths.
Shared memory as an aggregation point
Multi-agent architectures frequently use shared memory stores so agents can coordinate without redundant computation. An orchestrator writes its current understanding of the task; specialized agents read it, update it with their own findings, and pass control back. The pattern is efficient and practically necessary for coherent long-horizon tasks.
It is also a data aggregation point by design. Every agent writes its relevant context to the shared store. Every agent can read the full contents. The privacy boundary between agents — the principal benefit of the distributed architecture — collapses at the memory layer. A compromise of the shared memory store is not bounded to any single agent’s data domain. It reaches everything every agent has written, which is everything the system collectively knows.
Memory Poisoning Compounds the Problem
The memory security problem is not only about what gets read out of shared memory — it is also about what gets written in. The Memory Poisoning Attack and Defense paper (arXiv:2601.05504) demonstrated 95%+ injection success rates through query-only interactions with memory-based agents. In a multi-agent system with shared memory, a single successful poisoning does not affect one agent’s future behavior. It affects every agent that subsequently reads that memory store — which is all of them.
The coverage gap in existing frameworks
The Security Considerations for Multi-Agent Systems paper (arXiv:2603.09002) evaluated 16 security frameworks against 193 identified multi-agent threats across nine categories. The result is striking: no framework achieves majority coverage of any single threat category. The two most under-addressed domains are non-determinism — scoring 1.231 out of 5 across frameworks — and data leakage, scoring 1.340. These are precisely the domains through which multi-agent data exposure operates.
Non-determinism matters because the leakage path in a multi-agent system is not fixed. It depends on which agents happen to be active, which memory contents happen to be in scope, and which inter-agent communications happen to carry which context — all of which vary across runs of the same workflow. A security framework that cannot reason about non-deterministic systems cannot reliably constrain the paths through which data moves in a multi-agent deployment.
The security perimeter in a multi-agent system cannot be drawn around individual agents. It must be drawn around the communication topology — the channels between agents, the shared memory stores, the orchestration layer. That is a perimeter current tooling was not built to enforce.
— Synthesis from AgentLeak (arXiv:2602.11510) and AgenticCyOps (arXiv:2603.09134)What Effective Defense Requires
The AgenticCyOps paper proposes the most concrete architectural response in the corpus. It formalizes five defensive principles and applies them to a security operations center workflow using MCP. The core move is to treat inter-agent communication as a security-critical surface rather than an implementation detail — instrumenting it, enforcing trust boundaries within it, and requiring consensus validation for high-stakes agent decisions. In testing, explicit trust boundary decomposition reduces exploitable trust boundaries by a minimum of 72% compared to flat multi-agent architectures.
Agents Share, Trust Is Implicit
Agents communicate freely through unmonitored channels. Shared memory is accessible to all agents. Orchestration passes context without security classification. Trust between agents is implicit — messages from peer agents are treated as trusted by default.
Result: per-channel leakage falls, total exposure rises 60%. Inter-agent channels carry sensitive aggregated data through surfaces nobody is watching. A single memory compromise reaches all agents simultaneously.
60% Exposure IncreaseChannels Instrumented, Trust Earned
Inter-agent communication is logged and classified. Shared memory is partitioned by sensitivity domain with access controls enforced at read and write. Orchestration applies data minimization — agents receive only the context required for their specific subtask. Inter-agent authority claims require cryptographic attestation.
Proposed by AgenticCyOps. Reduces exploitable trust boundaries by 72%. Does not yet exist as standard practice in any deployed framework.
72% Boundary ReductionThe 4C Framework paper (arXiv:2602.01942) from CSIRO Data61 and UNSW takes a complementary angle, drawing on societal structures — law, norms, institutional accountability — to argue that multi-agent security requires governance operating at the system level, not the agent level. Individual agents cannot be made to enforce security boundaries they have no architectural basis to perceive. The boundaries must be enforced by the infrastructure around them.
What This Means for Architecture Decisions Today
The practical implication of the 60% finding is not that multi-agent architectures should be abandoned — they solve real problems and deliver real value. It is that the security assumptions imported from single-agent deployments do not transfer. An organization that has instrumented its single-agent deployment for data leakage cannot assume that adding agents while preserving the same monitoring approach will maintain or improve its security posture. It will degrade it, for exactly the reasons the AgentLeak paper documents.
The instrumentation gap is the most immediately actionable finding. Organizations deploying multi-agent systems today need to treat inter-agent communication channels — message queues, shared context stores, orchestration APIs, memory read/write operations — as first-class security surfaces with the same monitoring attention given to external API calls and database queries. In most current deployments, they receive none.
This series has documented five ways agentic AI systems break: alignment does not transfer to tool calls, protocol standardization creates monoculture risk, supply chains are already under active attack, agents can harm each other without any adversary involved, and distributing work across agents quietly expands the data exposure it was meant to contain. None of these are speculative. All are documented in empirical research from the first quarter of 2026 alone. The field is building faster than it is securing, and the 49+ papers reviewed for this series are the clearest signal yet of how wide that gap has grown.
