Представим обычную корпоративную задачу: сотрудник поручает ИИ-агенту подготовить закупку оборудования на сумму до €20 000. Агент привлекает помощников для анализа поставщиков, проверки бюджета и отправки писем. На пятом шаге возникает главный вопрос: кто именно действует и почему ему это разрешено?

У каждого агента может быть собственная служебная учётная запись и набор инструментов. Но идентичность агента и полномочия конкретной задачи — не одно и то же.

Если агент финансового контроля технически умеет утверждать платёж на €100 000, это не значит, что такое право становится частью каждой цепочки, в которой он участвует.

Я считаю опасной модель «наши агенты доверенные, поэтому они могут доверять друг другу». Это та же ошибка, которую компании годами исправляли в корпоративных сетях: доверенная среда быстро превращается в большую зону неявного доверия.

Один скомпрометированный агент, подмена межагентского сообщения или внедрённая в него инструкция могут расширить последствия далеко за пределы исходной задачи.

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

Если хотя бы одно из них запрещает операцию, цепочка должна остановиться. Вместе с поручением нужно передавать не только текст команды. Нужен «конверт делегирования»: — кто инициировал задачу; — какова бизнес-цель; — какие действия и данные разрешены; — каковы лимиты суммы и ресурсов; — что запрещено; — когда полномочия истекают; — где требуется одобрение человека; — скольким агентам ещё можно передать задачу; — как выглядит уже пройденная цепочка.

Контекст при этом должен быть достаточным для проверки цели, но минимальным по объёму. Передавать следующему агенту всю историю диалога «на всякий случай» — прямой путь к лишнему раскрытию данных.

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

OWASP рекомендует проверять личность отправителя, полномочия инструкции и сохранять класс обратимости при каждом переходе между агентами.

Многоагентное взаимодействие также выделяется как самостоятельная поверхность атаки. Нужны и технические предохранители: проверяемая идентичность отправителя, подписанный контекст полномочий, ограничение глубины делегирования, срок действия поручения и остановка при отклонении от ожидаемого маршрута.

Журнал должен восстанавливать полный граф: человек → основной агент → вспомогательные агенты → инструмент → бизнес-действие.

Это уже не только задача команды управления доступом или разработчиков ИИ-платформы. Руководитель ИБ должен добиться, чтобы правила делегирования, одобрения и расследования стали частью архитектуры до запуска автономных сценариев.

NIST в 2026 году выделил идентификацию и авторизацию программных и ИИ-агентов в отдельное направление, включая безопасное взаимодействие человека с агентом и агентов между собой.

Зрелая многоагентная система должна уметь доказать не только то, какой агент выполнил действие, но и то, откуда у него появилось право это сделать.

Как ваша система докажет, что пятый агент всё ещё действует в пределах полномочий, которые пользователь дал первому?