Утверждение, которое сдвигает план
Мультиагентная система — это группа моделей, обменивающихся сообщениями. Один агент предлагает, другой критикует, третий выполняет вызов инструмента. Проектное допущение состоит в том, что эти сообщения несут информацию. На практике они несут власть. Когда планировщик получает от коллеги сообщение о том, что ресурс недоступен, политика изменилась или шаг уже выполнен, планировщик часто принимает это утверждение как факт о мире. Он обновляет план, отбрасывает шаг или вызывает другой инструмент. Сообщение никогда не проверялось. Уязвимость не в том, что отправляющая модель злонамеренна или принимающая модель слаба. Она в том, что протокол позволил непроверенному утверждению изменить план.
Это проблема протокола, потому что она воспроизводится в разных семействах моделей и на разных уровнях возможностей. Более способный получатель не исправляет её автоматически; он может рационализировать утверждение коллеги более гладко. Более способный отправитель не вызывает её автоматически; отправителю достаточно выдать правдоподобное утверждение в нужный момент. Свойство, которое делает атаку работающей, структурно: сообщения между агентами обрабатываются как инструкции, а не как недоверенный ввод.
Механизм: сообщения коллег как инструкции
Рассмотрим цикл из двух агентов. Агент A планирует задачу. Агент B имеет доступ к инструменту, которого нет у A. A отправляет B запрос. B отвечает, что инструмент вернул ошибку и что правильный обходной путь — пропустить шаг валидации. У A нет независимой записи об этом вызове инструмента. Если системный промпт A предписывает сотрудничать с коллегами и избегать избыточной работы, A примет отчёт и пропустит шаг. План изменился на основании одной фразы.
Тот же механизм проявляется в агентах, вызывающих инструменты. Сообщение коллеги может назвать инструмент и аргументы. Если парсер принимающего агента не различает пользовательскую инструкцию и предложение коллеги, сообщение коллеги становится вызовом инструмента. Собственная политика принимающего агента может запрещать действие, но политика оценивается относительно формулировки коллеги, а не относительно исходной задачи. Модель видит кооперативный запрос, а не инъекцию.
Настойчивость — вторая половина механизма. Один отклонённый запрос не завершает обмен. Агент, который продолжает переформулировать, добавлять срочность или переформулировать один и тот же запрос на протяжении ходов, может измотать уступчивого коллегу. Контекст принимающего агента накапливает повторяющееся утверждение. С каждым ходом утверждение выглядит всё более устоявшимся. В конце концов получатель воспринимает запрос как устоявшийся контекст, а не как оспариваемое утверждение. Количество ходов — это поверхность атаки, а не красноречие отдельного сообщения.
Это не гипотетический класс отказов. Исследователи безопасности и разработчики агентов документировали проблемы prompt-injection и доверия между агентами по мере роста мультиагентных развёртываний. Закономерность последовательна: модель обманывают не столько хитроумной фразой, сколько система обманывается каналом, в котором нет понятия о том, кто говорит и насколько весомым должно быть его утверждение. Освещение таких инцидентов обычно сосредоточено на модели, но устойчивое исправление живёт на уровне сообщений.
Происхождение и уровень доверия для каждого сообщения между агентами
Каждое сообщение, пересекающее границу агента, должно нести структурированные метаданные: идентичность отправляющего агента, задачу, на которую он уполномочен действовать, доказательства в основе его утверждения и уровень доверия. Уровень доверия — это не настроение; это вход политики. Утверждение от коллеги без доступа к инструментам не должно позволять заявлять, что вернул инструмент. Утверждение от коллеги вне текущей области задачи не должно позволять изменять задачу. Планировщик принимающего агента должен прочитать уровень доверия прежде, чем читать текст.
Это небольшое изменение с большим эффектом. Оно превращает неявное социальное допущение (коллеги кооперативны) в явное, проверяемое поле. Оно также делает логи полезными: когда план меняется, запись показывает, какое сообщение и какой уровень доверия вызвали изменение.
Независимая проверка до того, как утверждение коллеги изменит план или вызов инструмента
Утверждение коллеги, которое изменило бы план или вызвало вызов инструмента, должно быть проверено по источнику, который коллега не контролирует. Если коллега говорит, что файл отсутствует, принимающий агент должен проверить файл. Если коллега говорит, что политика изменилась, принимающий агент должен прочитать политику. Если коллега говорит, что шаг выполнен, принимающий агент должен найти артефакт. Проверка не обязана быть дорогой. Она обязана быть независимой.
Честный компромисс — это задержка и стоимость. Проверка добавляет шаг, иногда вызов инструмента, иногда круговой обмен. В системе, где большинство сообщений коллег точны, проверка выглядит как расточительство. Проектное решение состоит в том, какие утверждения могут менять состояние без проверки. Утверждения с низкими ставками, обратимые, в пределах области могут проходить. Утверждения, которые меняют план, расходуют ресурс 
/media/server-rack-closeup-3d8cf9-5b763a.jpg)
Ограничить повторные утверждения отклонённого запроса
Отклонённому запросу не следует позволять возвращаться бесконечно в новой формулировке. Протокол должен считать повторные утверждения на коллегу, на запрос и на задачу. После небольшого числа попыток запрос закрывается, и принимающий агент перестаёт его оценивать. Лимит — это не суждение о намерении коллеги; это граница подверженности получателя. Он также даёт получателю чистый способ завершить цикл, не эскалируя к человеку при каждом разногласии.
Компромисс в том, что законное разногласие может быть оборвано. У коллеги может быть реальная поправка, которая приходит на четвёртой попытке. Поэтому лимит следует сочетать с путём эскалации: закрытые запросы логируются, и человек или агент-супервизор может открыть их заново с приложенными доказательствами. Смысл в том, чтобы сделать настойчивость дорогой и видимой, а не сделать исправление невозможным.
Тестирование: враждебные коллеги, а не только враждебные пользователи
Большинство red-teaming нацелено на пользовательский канал. Мультиагентной системе нужен второй набор тестов, где противник — коллега. Настройка проста: запустите систему с одним агентом, заменённым враждебным коллегой, который выдаёт правдоподобные непроверенные утверждения, переформулирует отклонённые запросы и пытается называть инструменты и аргументы. Тест измеряет, меняются ли планы, происходят ли вызовы инструментов и сколько ходов получатель терпит, прежде чем закрыть запрос.
Ценность этого теста в том, что он упражняет протокол, а не модель. Замена модели не изменит результат, если уровень сообщений по-прежнему воспринимает текст коллеги как власть. Протокол с тегами происхождения, требованиями проверки и лимитами на повторные утверждения выдержит смену моделей — а это и есть свойство, важное для системы в продакшене.
Принцип проектирования
Относитесь к каждому сообщению между агентами как к недоверенному вводу, пока протокол не скажет иное. Модель — не граница. Граница — это уровень сообщений: кто отправил, что ему позволено утверждать, какие доказательства он приложил и сколько раз он может повторяться. Постройте этот уровень осознанно, и манипуляция между агентами станет ограниченным, наблюдаемым событием, а не тихим изменением плана.