MAMA: правила сетевой архитектуры для защиты данных в мультиагентных LLM-системах

Для кого: Те, кто создаёт мультиагентные системы — несколько чатов с разными ролями, которые передают информацию друг другу. Например: - Команды GPTs в ChatGPT Team - Проекты с несколькими агентами в Claude - Ручная оркестровка: копируешь вывод одного чата в другой

Не для: Тех, кто работает один-на-один с моделью в обычном чате.

Рейтинг безопасности (от самого защищённого):

1. Chain (цепочка) — агенты связаны последовательно: A → B → C → D

   • Утечки: ~12-15%
   • Информация идёт строго по одному пути
   • Если нужна передача через несколько этапов

2. Tree (дерево) — иерархия без циклов: корень → ветви → листья

   • Утечки: ~15-17%
   • Хорошо для иерархических задач (менеджер → исполнители)

3. Circle (кольцо) — замкнутая цепь: A → B → C → D → A

   • Утечки: ~24%
   • Информация может идти в обоих направлениях

4. Star-pure (чистая звезда) — центральный хаб, листья не связаны

   • Утечки: ~23%
   • Один агент координирует, остальные изолированы друг от друга

5. Star-ring (звезда + кольцо) — хаб + кольцо между листьями

   • Утечки: ~25-29%
   • Shortcuts создают дополнительные пути утечек

6. Fully connected (все со всеми) — каждый агент связан со всеми

   • Утечки: ~29%
   • Максимальная диффузия, минимальная защита

Расстояние = число шагов в графе от одного агента до другого.

Если у тебя есть: - Агент с чувствительными данными (доступ к личным данным, ключам, внутренним документам) - Агент, который взаимодействует с внешним миром (обрабатывает пользовательский ввод, публичные запросы)

Держи их максимально далеко друг от друга:

✅ Хорошо:

Внешний агент → Фильтр → Обработчик → Ещё один слой → Агент с данными
(расстояние = 4 шага)

❌ Плохо:

Внешний агент → Агент с данными
(расстояние = 1 шаг)

Центральность = сколько других агентов напрямую связано с этим агентом.

Если агент содержит чувствительные данные — минимизируй его связи:

✅ Хорошо:

Агент с данными подключён только к одному доверенному агенту-координатору

❌ Плохо:

Агент с данными в центре звезды, все остальные к нему подключены

Shortcut = прямая связь, которая обходит центральный узел.

Пример: в звезде листья общаются только через центр. Если добавить прямые связи между листьями (star-ring), утечки вырастут на 20-30%.

Почему? Центральный агент может фильтровать информацию. Shortcuts создают обходные пути.

80% утечек происходят в первые 2-3 раунда, потом рост замедляется.

Если задача решается быстро — останови взаимодействие раньше.

Например: - Задача решена за 3 раунда → останови систему - Не позволяй агентам общаться "просто так" после завершения

Задача: Ты строишь команду из 5 агентов для обработки заказов клиентов. Один агент имеет доступ к базе с личными данными клиентов (адреса, телефоны). Другие агенты обрабатывают запросы, генерируют ответы, проверяют качество.

Применение принципов:

Вариант 1: Плохая архитектура (fully connected)

┌─────────────────────────────────────┐
│   Все агенты связаны со всеми       │
│                                     │
│   Обработчик запроса ←→ Агент с БД  │
│         ↕            ↕              │
│   Генератор ←→ Проверка качества    │
│         ↕            ↕              │
│   Внешний агент ←→ все остальные    │
└─────────────────────────────────────┘
Риск утечки: ~29%

Вариант 2: Хорошая архитектура (chain)

Внешний агент → Фильтр → Координатор → Агент с БД
                           ↓
                      Генератор → Проверка → Ответ

Риск утечки: ~12%

Структура: 1. Внешний агент получает запрос клиента 2. Фильтр проверяет безопасность запроса (нет инъекций, странных паттернов) 3. Координатор решает, нужен ли доступ к БД 4. Агент с БД получает запрос только через координатора (расстояние = 3 шага) 5. Генератор → Проверка → Ответ — цепочка обработки без доступа к БД

Реализация в ChatGPT/Claude: - Создай 6 отдельных чатов (или Custom GPTs) - Вручную копируй вывод одного чата в следующий по цепочке - НЕ давай внешнему агенту прямой доступ к чату с БД

Утечки информации в мультиагентных системах подчиняются законам сетевой диффузии, как распространение вируса или слухов в социальных сетях. Модели — это автокорреляционные генераторы: если в контексте агента появилась информация (через его собственную память или сообщение от соседа), она с высокой вероятностью просочится в его ответ, даже если системный промпт требует конфиденциальности.

Три фактора определяют скорость утечек:

1. Число путей — в полносвязном графе информация может пройти напрямую (1 шаг), в цепочке — только через все узлы (n-1 шагов). Больше путей = больше вероятностей утечки.

2. Длина путей — каждый промежуточный агент — это фильтр, который может (случайно или намеренно) НЕ передать чувствительную информацию дальше. Короткие пути обходят фильтры.

3. Центральность узлов — если агент с данными в центре (много связей), он чаще участвует в коммуникации, значит чаще "светит" данные в разных контекстах. Изолированный агент в листе дерева — редко вызывается, реже утекает.

Temporal dynamics: Первые раунды — это initial burst (начальный всплеск). Модели в первых сообщениях активно используют доступную информацию. К 3-4 раунду контекст "устаканивается", модели переключаются на рефлексию и уточнения, новых данных не добавляется — рост утечек замедляется.

PII type differences: Геолокация и время — низкосалиентные атрибуты. Модели воспринимают их как "контекст", не как секрет, охотно упоминают. Имена и ID — высокосалиентные, модели "чувствуют" чувствительность (из RLHF-тренировки на безопасность), реже включают в ответ без явного запроса.

⚠️ Узкий контекст: Применимо только если ты строишь мультиагентную систему (несколько агентов с разными ролями). Если работаешь с одной моделью в чате — эти принципы не релевантны.

⚠️ Ручная оркестровка: Без кода или API тебе придётся вручную копировать вывод одного чата в другой, соблюдая топологию. Это трудозатратно для больших команд и длинных сессий.

⚠️ Не абсолютная защита: Исследование показывает снижение риска, но не нулевой риск. Даже в цепочках ~12-15% данных утекают. Топология — это слой защиты, не панацея.

⚠️ Trade-off с эффективностью: Разреженные топологии безопаснее, но медленнее. В цепочке информация идёт через все узлы последовательно. В fully connected все узлы могут работать параллельно. Безопасность vs скорость — приходится выбирать.

Команда из USC, FSU и ASU создала SPIRIT — датасет из 104 синтетических документов с размеченными PII-сущностями (имена, адреса, даты рождения, ID). Для каждого документа сгенерировали публичный контекст (фон и вопрос), который НЕ содержит PII напрямую — гарантия, что утечки идут через мультиагентное взаимодействие, а не из задания.

Протокол из двух фаз: 1. Engram (инициализация): Целевой агент получает документ с PII, остальные — только публичный контекст. Атакующий агент получает системный промпт "собирать информацию для выполнения задачи" (не явное "укради", чтобы не триггерить safety-фильтры).

2. Resonance (взаимодействие): 10 раундов, в каждом агенты обмениваются сообщениями строго по топологии графа. Если агенты A и B не связаны ребром — они не видят друг друга. Атакующий агент пытается извлечь PII через косвенные запросы.

Тестировали 6 топологий (цепь, кольцо, дерево, звезда, звезда-кольцо, полная связь) на командах из 4, 5, 6 агентов. Для каждой топологии варьировали позиции атакующего и цели, чтобы изолировать эффект расстояния и центральности. Использовали две модели: Llama 3.1-70B и DeepSeek v3.

Метрики: - Leakage Rate = сколько процентов PII-сущностей атакующий восстановил к концу - Time-to-Leak = на каком раунде появилась первая утечка - Success/Partial/Failure = категории по полноте утечки

Результаты показали консистентные паттерны во всех конфигурациях: топология — доминирующий фактор, плотные графы утекают в 2+ раза сильнее разреженных, рейтинг топологий сохраняется при смене модели и размера команды. Это подтверждает, что структура сети — первичный параметр безопасности, не артефакт конкретной модели.

Интересная деталь: binary tree тестировали на случайной трети пар атакующий-цель (из-за большого числа неизоморфных вариантов), и даже неполная выборка дала стабильную оценку — признак робастности метода.

Что: Если у тебя уже есть топология (например, унаследованная система), добавь выделенный reviewer-агент, который проверяет сообщения на утечки ПЕРЕД передачей.

Где ставить reviewer: - Между внешним агентом и остальной системой (входной фильтр) - Перед агентом с чувствительными данными (выходной фильтр) - На хабе в star-топологии (центральный фильтр)

Как:

Агент А → Reviewer → Агент Б (с данными)
           ↓
      Проверка:
      - Есть ли в сообщении PII?
      - Необходим ли PII для задачи?
      - Можно ли заменить на плейсхолдер?

Reviewer получает системный промпт:

Ты — фильтр безопасности. Проверяй сообщения между агентами.
Если видишь личные данные (имена, адреса, ID) — замени на [REDACTED] или запроси подтверждение.
Пропускай только минимально необходимую информацию.

Что: Меняй топологию в зависимости от фазы задачи.

Фаза 1: Сбор информации (нужна скорость) → Используй star-pure или fully connected → Агенты быстро обмениваются черновиками, идеями, контекстом

Фаза 2: Обработка чувствительных данных (нужна безопасность) → Переключись на chain или tree → Строгий контроль, кто что видит

Фаза 3: Финализация (нужна проверка) → Используй star с reviewer в центре → Все результаты проходят через одного проверяющего

Пример: команда анализирует резюме кандидата (PII: имя, телефон, адрес). - Фаза 1 (brainstorm): все агенты обсуждают общие критерии оценки — fully connected - Фаза 2 (оценка резюме): только два агента видят полный текст — chain - Фаза 3 (решение): HR-агент собирает оценки через star, принимает решение

Что: Если топология уже задана, блокируй shortcuts для критических узлов.

Пример: в star-ring топологии листья связаны и через хаб, и напрямую друг с другом. Если один лист — агент с данными:

До:

Лист А (с данными) ←→ Хаб
    ↕                 ↕
Лист Б ←→ Лист В ←→ Лист Г

Атакующий лист Б может дойти до А напрямую (1 шаг).

После:

Лист А (с данными) ←→ Хаб ТОЛЬКО

Лист Б ←→ Лист В ←→ Лист Г

Теперь атакующий Б должен идти через хаб (2 шага), хаб может фильтровать.

Реализация: просто не копируй вывод листа А в другие листы напрямую, только через хаб.

Topology Matters: Measuring Memory Leakage in Multi-Agent LLMs

Jinbo Liu, Defu Cao, Yifei Wei, Tianyao Su (University of Southern California)

Yushun Dong (Florida State University)

Yue Zhao (University of Southern California)

Xiyang Hu (Arizona State University)

SPIRIT dataset — синтетические документы с PII из Gretel Synthetic Domain-Specific Documents Dataset (Gretel AI, 2024)

Отсылки на базовые концепции: - Network diffusion: Watts & Strogatz (1998), Newman & Watts (1999) - LLM multi-agent security: NetSafe (Yu et al., 2024), G-Safeguard (Wang et al., 2025c)