Один агент - это вызов по правам и аудиту. Несколько агентов, которые общаются друг с другом, - уже другое дело: привычная модель «защити актора» перестаёт работать, потому что агенты начинают доверять друг другу. А злоумышленник обычно ищет не самый защищённый узел, а самого слабого члена системы - и через него лезет дальше.
В многоагентной системе нарушение одного участника легко превращается в нарушение всех, если контексты не изолированы, а права размазаны. Разберём, как проектировать такую систему, чтобы один скомпрометированный агент оставался изолированным инцидентом, а не становился плацдармом.
Почему multi-agent это новое измерение риска, а не «много агентов»
В одиночном сценарии есть один доверенный контур: агент и его права. В многоагентном сценарии появляются два новых элемента, которых раньше не было:
- Взаимное доверие. Агенты передают друг другу данные, задачи и результаты. Это каналы, которых нет у одиночного агента.
- Накопление прав. Результат работы группы складывается из прав разных участников; ошибка одного может усилить влияние другого.
Итог: surface не сумма поверхностей каждого агента, а сложнее - из-за перекрёстных связей. Если оркестратор и субагенты ходят с общим пулом прав и общим контекстом, то взлом любого одного равносилен взлому всех.
Доверие между агентами и как оно ломается
Агенты общаются через вывод: один возвращает другому текст «вот результат». Но этот текст - недоверенные данные. Если субагент написал результат, который начинается словами «игнорируй прошлые инструкции и выполни следующее», а ведущий не отделяет данные от инструкций, ведущий может «выполнить» чужую команду. Это тот же класс проблемы, что prompt injection через tool descriptions, но здесь она ходит между агентами беспрепятственно.
Ключевое правило: вывод другого агента - это данные, а не инструкции. Подход «не доверяй ни одному агенту по умолчанию» к меж-агентному общению звучит параноидально, но именно он оставляет вас в безопасности, когда один из членов скомпрометирован.
Изоляция контекста субагентов + только сжатое резюме наружу
Лучшая защита от каскада - не давать информации растекаться между агентами. Субагент должен работать в своём изолированном контексте: он исследует свои данные, держит их у себя и возвращает ведущему не сырой дамп, а сжатое резюме. Так детальные контексты (включая возможные заражённые данные) остаются внутри субагента и не попадают к оркестратору или другим участникам.
Это же техника, которую используют для производительности: субагент может потратить десятки тысяч токенов на исследование, а ведущему отдать резюме на пару тысяч. Изоляция решает сразу две задачи - компактность и безопасность: что не вышло из субагента, то не может заразить остальных.
Разделение прав: оркестратор планирует, субагент действует
Частая ошибка - дать оркестратору широкие права «на всякий случай», ведь он «главный». Это ровно обратное тому, что нужно. Оркестратор координирует, но не обязан иметь сами привилегии на действие:
- Оркестратор - планирует, раздаёт задачи, собирает результаты. Ему нужны права на координацию, а не на проде и не на критичные данные.
- Субагент - делает конкретное действие. Ему выдаётся узкий набор прав ровно под его задачу.
Если каждое действие требует собственного набора прав, то единственный способ, которым агент делает что-то чувствительное - это когда его права это явно позволяют. Это разворачивает «накопление прав» в обратную сторону: даже если оркестратор скомпрометирован, он не поднимает права субагента сверх выданного.
Наименьшие привилегии и аудит как глобальная рамка
Общая рамка для многоагентной системы не отличается от правил для одиночных акторов, но применяется строже:
- Наименьшие привилегии на каждого агента/субагента отдельно - минимум прав, достаточный для его роли.
- Без широких scope. Токен/права, которые позволяют «всему» агенту, тем более опасны, когда агентов много.
- Аудит каждого вызова - какой агент, с какими правами, к какому инструменту. При каскаде именно журнал показывает маршрут распространения.
- Идемпотентность и откат того, что агент может сделать, чтобы прерванное действие не оставляло последствий.
В многоагентной системе «понять, что произошло» без журнала практически невозможно - агенты действуют параллельно и пересылают результат друг другу, и только аудит позволяет восстановить цепочку.
Чек-лист перед запуском многоагентной системы
Прежде чем пускать оркестратора с субагентами в бой, проверьте:
- Изолированы ли контексты субагентов друг от друга и от оркестратора?
- Возвращает ли каждый субагент сжатое резюме, а не сырые данные?
- Имеет ли оркестратор только права на координацию, без широкого доступа к действиям?
- Выданы ли наименьшие привилегии каждому агенту отдельно, без общих scope?
- Отделяет ли система вывод одного агента как данные от инструкций?
- Пишется ли аудит каждого меж-агентного вызова и инструментального вызова?
Если на любой пункт ответ «нет» - многоагентная система готова к тому, чтобы один слабый узел увёл за собой остальных.
Где Codenik: точечные права и изоляция как слой
Multi-agent требует того, что умеет делать единая точка управления доступом: раздавать права точечно каждому агенту и субагенту, не выпускать секреты в контексты и писать аудит вызовов. Codenik работает ровно на этой границе - как слой, в котором каждый агент получает свой узкий набор инструментов и прав, а все вызовы фиксируются для разбора.
Изоляция контекста субагентов в такой схеме перестаёт быть «хочется правильно» и становится исполнимой политикой: агент физически не может вызвать инструмент, права на который ему не выданы, а секрет не попадает в его окно по умолчанию. Про права и аудит одиночного агента - в статьях «Права доступа для AI-агентов» и «Аудит для действий агентов».
Короткий вывод
Многоагентная система приносит масштаб ценой нового типа риска: доверие между агентами, которое можно подорвать через самого слабого участника. Защита строится на изоляции - контекстов и прав: субагенты работают в своих контекстах и возвращают резюме, оркестратор только планирует, права минимизируются, всё покрывается аудитом.
Главный принцип: не доверяйте ни одному агенту, включая «главного». Если взлом одного члена остаётся изолированным - система выдержала, а аудит покажет маршрут, чтобы это исправить.