TL;DR
TG-CI — способ защиты личных данных в системах из нескольких агентов с памятью. Перед тем как отдать агенту факт из памяти, отдельная модель-судья смотрит на всю запланированную цепочку (кто получит факт дальше) и на журнал того, что каждый получатель уже знает. Если где-то в цепочке передача недопустима, факт не выдаётся совсем или выдаётся только до этого места.
Привычная проверка смотрит только на текущую передачу, и у неё три слепые зоны. Факт может быть безобидным для первого агента, но уйти дальше к тому, кому его видеть нельзя. Два безобидных факта могут вместе раскрыть то, что скрывали. Третий случай — передача допустима «в одиночку», но не с учётом того, что получатель уже знает. В исследовании такая локальная проверка с журналом оставляла около двух третей нарушений базовой системы без защиты. Основная часть остаточных утечек — «по цепочке».
Метод работает в два режима. Full-Scope: факт выдаётся, только если допустима вся цепочка после получателя, иначе блок. Auto-Region: факт идёт по цепочке, пока передачи допустимы, и останавливается на первой недопустимой, а остальные агенты работают без него. В обоих режимах нарушений на 86–94% меньше, чем у локальной проверки с журналом, а точность ответов падает лишь на 4–6%.
Схема метода
ШАГ 0: Зафиксировать граф задачи: кто кому передаёт и какую подзадачу решает
ШАГ 1: Разложить ответ памяти на отдельные факты (субъект, тип, значение)
ШАГ 2: Для каждого факта составить цепочку: кому он уйдёт дальше
ШАГ 3: Судья проверяет каждую передачу в цепочке с учётом журнала раскрытия получателя
├─ Full-Scope: вся цепочка допустима → ВЫДАТЬ, иначе → БЛОК
└─ Auto-Region: идти вперёд до первой недопустимой передачи → ВЫДАТЬ до границы
ШАГ 4: Ведение журнала: записывать, что реально ушло каждому получателю
ШАГ 5 (Auto-Region): на границе стоит шлюз: убирает защищённый факт из сообщений
Шаги 1–3 — запросы к судье (LLM). Шаг 5 в исследовании сделан кодом, но его можно заменить инструкцией агенту.
Пример применения
Задача: Вы автоматизируете сеть частных клиник (в духе «СМ-Клиника» или «Медси»). Агенты работают цепочкой: Агент-регистратор → Агент-расписание → Агент-напоминания (шлёт SMS и сообщения в Telegram) → Агент-страховой партнёр. В памяти лежит: «пациент К. записан к онкологу», «К. застрахован по ДМС в компании X», «телефон К.». Агент-напоминания подключён к внешнему сервису рассылки и считается самым рискованным: его могут скомпрометировать.
Промпт для судьи (режим Auto-Region):
Ты — судья приватности. Решай, можно ли выдать факт из памяти и докуда он может дойти.
<Граф_задачи>
Регистратор → Расписание → Напоминания → Страховой_партнёр
Подзадачи:
- Регистратор: оформить запись пациента
- Расписание: подобрать слот и врача
- Напоминания: отправить пациенту напоминание о визите
- Страховой_партнёр: подтвердить покрытие по ДМС
<Журнал_раскрытия>
- Расписание уже получило: ФИО пациента К., дату визита
- Напоминания уже получило: телефон К.
- Страховой_партнёр уже получил: номер полиса
<Факт>
Субъект: пациент К. | Тип: специальность врача | Значение: онколог
Источник: память. Первый получатель: Регистратор.
<Логика>
1. Для каждой передачи в цепочке, начиная с первой, проверь:
- нужен ли этот факт получателю для его подзадачи?
- не раскроет ли он вместе с тем, что получатель уже знает (журнал), то, что раскрывать нельзя?
2. Иди вперёд, пока передачи допустимы. Остановись на первой недопустимой.
3. Если недопустима самая первая передача — БЛОК.
4. Иначе — РЕЛИЗ с границей: до какого агента факт дойдёт и кому его нельзя передавать дальше.
<Формат_ответа>
Для каждой передачи: «получатель — допустимо/недопустимо — причина в одну строку».
Итог: РЕЛИЗ до {агент} / БЛОК.
Запрещено передавать дальше границы: {список}.
Результат: Модель пройдёт по цепочке передача за передачей и выдаст вердикт по каждой с короткой причиной. Вероятный итог: факт нужен Регистратору и Расписанию, а Напоминания получают его только в обобщённом виде или не получают совсем. Вместе с телефоном из журнала он уже раскрывал бы диагноз. В конце будет граница выдачи и список, куда факт передавать нельзя. Конкретные решения зависят от ваших правил: судья применяет то, что вы напишете в политике.
Почему это работает
Слабость. Проверка «по месту» отвечает на вопрос «можно ли отдать это следующему». Но решение на первом шаге определяет судьбу факта на всех последующих. Если проверять только следующую передачу, ошибка «по цепочке» заметна только тогда, когда факт уже ушёл. Журнал раскрытия защищает от одной из трёх проблем (накопление), но не от пересылки дальше.
Сильная сторона LLM. Модель хорошо судит, уместна ли передача информации в контексте задачи: нужен ли факт для этой подзадачи, не раскрывает ли он лишнего вместе с уже известным. Это работа с текстом и смыслом, не с формальными метками «секретно / не секретно».
Как метод это использует. Судье дают то, чего ему не хватало: весь граф и журнал получателей. Он оценивает каждую передачу в цепочке и сводит решение к «допустима вся цепочка» (Full-Scope) или «допустима до такого-то агента» (Auto-Region). Модель по-прежнему отвечает на простой локальный вопрос, но задаёт его в нужных местах.
Рычаги управления: - Режим. Full-Scope строже: один «неудобный» получатель вдали блокирует факт, даже если ближний мог бы им воспользоваться. Auto-Region мягче: задача идёт дальше без факта. Для медицины и финансов берите Full-Scope, где важнее полезность — Auto-Region. - Состав журнала. Чем подробнее записано, что получил каждый агент, тем лучше ловится накопление. - Подзадачи агентов. Чем конкретнее описана подзадача получателя, тем точнее вердикт «нужно ли ему это». - Подозрительные агенты. Помечайте в графе, кто подключён к внешним сервисам: их стоит ставить в конец цепочки или в Full-Scope.
Шаблон промпта
Важно: в статье (в том фрагменте, что доступен) готовых промптов судьи нет. Ниже реконструкция по описанному в статье алгоритму: те же сущности (граф, журнал, факт, цепочка, граница) и тот же выбор из двух режимов.
Ты — судья приватности в многоагентной системе. Перед выдачей факта из памяти
реши, можно ли его выдать, и докуда он может дойти.
<Граф_задачи>
{агенты_и_связи: A → B → C ...}
Подзадачи:
- {агент_1}: {подзадача_1}
- {агент_2}: {подзадача_2}
...
Особые агенты (внешние сервисы, повышенный риск): {список}
<Политика>
{правила: что нельзя раскрывать, какие комбинации фактов опасны}
<Журнал_раскрытия>
- {агент_1} уже получил: {список}
- {агент_2} уже получил: {список}
...
<Факт>
Субъект: {кто} | Тип: {что за данные} | Значение: {значение}
Первый получатель: {агент}
<Режим>{FULL_SCOPE или AUTO_REGION}
<Логика>
1. Составь цепочку: все агенты, до которых факт может дойти по графу после первого получателя.
2. Для каждой передачи в цепочке проверь:
а) нужен ли факт получателю для его подзадачи?
б) не раскроет ли он вместе с журналом получателя то, что запрещено политикой?
в) не уйдёт ли он дальше к тому, кому нельзя?
3. Если режим FULL_SCOPE: выдай факт, только если допустима КАЖДАЯ передача в цепочке. Иначе — БЛОК.
4. Если режим AUTO_REGION: иди вперёд, пока передачи допустимы. Остановись на первой недопустимой.
Если недопустима первая передача — БЛОК. Иначе РЕЛИЗ до границы.
<Формат_ответа>
По каждой передаче: «получатель — допустимо / недопустимо — причина в одну строку».
Итог: РЕЛИЗ (до {агент} / вся цепочка) или БЛОК.
Запрещено передавать дальше границы: {список агентов}.
Обновление журнала: {что записать каждому получателю}.
Что подставлять. {агенты_и_связи} — реальный план вашей автоматизации. {политика} — ваши правила (например, «диагноз и специальность врача знают только регистратор и врач»). {журнал} — то, что вы реально передали каждому агенту к этому моменту. Если журнала нет, начните с пустого и вносите после каждой выдачи.
🚀 Быстрый старт — вставь в чат:
Вот шаблон судьи приватности для многоагентной системы (метод TG-CI).
Адаптируй под мою задачу: [опиши свою цепочку агентов и какие данные у них в памяти].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит: кто из агентов кому передаёт данные, какая подзадача у каждого, какие данные в памяти и какие комбинации опасны. Это нужно, чтобы судья проверял передачи по реальному графу, а не по абстрактной схеме. Она возьмёт структуру из шаблона и соберёт готовый промпт под вашу цепочку.
Ограничения
⚠️ Нужна инженерная сборка: в исследовании метод встроен в код (LangChain, память Mem0, шлюз сообщений, локальные модели для проверки). В чате вы получаете только судью-промпт. Чтобы он реально блокировал передачи, нужно вставить его в оркестрацию вашей автоматизации перед каждой выдачей из памяти.
⚠️ Дороже в токенах: судья работает почти в три раза больше по токенам, чем простая локальная проверка (около 133–145 тысяч против 44 тысяч за запуск). Auto-Region экономит примерно 8% к Full-Scope. Для задач без чувствительных данных это перебор.
⚠️ Граф должен быть известен заранее: метод предполагает, что план «кто кому передаёт» фиксирован на время задачи. Если агенты на ходу меняют маршрут, цепочка в проверке устареет. Авторы прямо оставляют это на будущее.
⚠️ Скрытые каналы вне защиты: метод работает, только если вся передача идёт через контролируемые каналы (память и сообщения). Если агенты кодируют данные внутри допустимых текстов или есть обходной канал, судья этого не увидит.
⚠️ Остаётся небольшой процент утечек и потеря полезности: Full-Scope иногда блокирует то, что ближнему агенту можно было бы отдать. Точность ответов в основном режиме падает на несколько процентов.
⚠️ Синтетическая проверка: все данные в бенчмарке выдуманные, графы из четырёх агентов, всего пять вопросов на кейс. На реальных данных и длинных цепочках результат может быть слабее.
Как исследовали
Авторы собрали бенчмарк MAPLE-Bench: 144 кейса в четырёх сценариях (здравоохранение, финансы, HR, быт). В каждом кейсе четыре агента, три формы графа (цепочка, дерево, ветвление) и один-два скомпрометированных агента. У каждого агента 30 выдуманных записей в памяти. Из них семь нужны для ответов на пять вопросов, остальные 23 — отвлекающий шум, как в реальной памяти. Для каждой записи заранее разметили, кому её можно, а кому нельзя видеть.
Сравнили пять вариантов: без защиты; локальная проверка с журналом; проверка каждой передачи по мере выполнения; и два режима TG-CI. Среднее число неразрешённых раскрытий: без защиты 15,84, локальная проверка с журналом 10,47, проверка «по ходу» 6,11, Auto-Region 1,49, Full-Scope 0,62. Вывод сильнее всего удивляет в средней строке: даже проверка каждой передачи по мере выполнения оставляет много утечек, потому что она замечает проблему уже после того, как факт ушёл. Главное преимущество TG-CI — именно в утечках «по цепочке».
Основные результаты получены на связке «агенты на Claude Haiku 4.5, судья на GPT-5.6 Luna», остальные комбинации вынесены в приложение. Данные в статье обрезаны на сравнении режимов, поэтому детали про стоимость и разницу между режимами известны не полностью.
Адаптации и экстраполяции
🔧 Техника: добавить «журнал раскрытия» как отдельный блок → ловить накопление
Если ваша система хранит всё в одном чате или в одной памяти, заведите явный блок <Журнал_раскрытия> и обновляйте его после каждой выдачи:
<Журнал_раскрытия>
- Агент_напоминания получил: телефон К. (шаг 3)
- Агент_напоминания получил: дата визита (шаг 5)
→ Проверь: телефон + дата + тип клиники = раскрытие диагноза?
Явная запись «что уже ушло» помогает судье заметить опасную комбинацию, а не оценивать каждый факт по отдельности.
Экстраполяция: правило в инструкции для субагентов (CLAUDE.md / AGENTS.md)
Авторы не проверяли это на агентных инструментах, это перенос идеи:
## Передача данных субагентам
Перед делегированием подзадачи:
1. Выпиши, какие данные пользователя нужны субагенту именно для этой подзадачи.
2. Проверь, кому субагент передаст результат дальше. Если в цепочке есть внешний сервис
(отправка писем, веб-запросы, сторонние API) — не передавай персональные данные,
которые ему не нужны.
3. Передавай минимум. Если сомневаешься — спроси пользователя.
Это упрощённая версия Auto-Region: остановись на границе, где начинается внешний или рискованный получатель.
Ресурсы
- Judging Before Propagation: Task-Graph Contextual Integrity for Multi-Agent Privacy (препринт).
- Авторы: Hengyu Wu, Blaise Delattre, Yang Cao — Institute of Science Tokyo.
- Бенчмарк: MAPLE-Bench (Multi-Agent Privacy Leakage Evaluation Benchmark).
- Опорные работы: теория контекстной целостности (Nissenbaum, 2004; Barth et al., 2006); AgentSCOPE; AirGapAgent; AgentLeak; The Sum Leaks More Than Its Parts.