Unit 42 обнаружила скрытые команды, которые маскируются среди легитимного обмена сообщениями.

Специалисты Palo Alto Networks Unit 42 описали новый вектор атаки для мультиагентных систем — agent session smuggling — при котором злонамеренный удалённый агент внедряет скрытые инструкции в ходе длительной сессии и заставляет клиентский агент выполнять нежелательные действия без уведомления пользователя. Уязвимость заключается не в формальной дыре протокола A2A, а в том, как состояние сессии и встроенное доверие между агентами позволяют маскировать вредоносные команды среди легитимного обмена.
Механика проста: клиент инициирует обычный запрос к удалённому агенту; на этапе активной сессии этот агент посылает дополнительные, скрытые сообщения, которые модифицируют внутренний контекст клиента; затем удалённый агент возвращает ожидаемый внешний ответ, а промежуточные операции остаются невидимыми пользователю. В результате возможны подмена контекста, утечка внутренней конфигурации и несанкционированный вызов функций — всё это происходит внутри диалога.
Исследование сравнивает A2A с Model Context Protocol (MCP) и показывает, почему риск выше именно в A2A: MCP обычно работает без сохранения сессий и выполняет изолированные вызовы инструментов, тогда как A2A хранит историю взаимодействий и позволяет агентам адаптироваться в ходе диалога. Эта комбинация «памяти» и автономности делает возможными прогрессивные, трудноотслеживаемые атаки.
Для демонстрации учёные реализовали два PoC-сценария на базе Google Agent Development Kit и протокола A2A. Клиентом выступал финансовый ассистент на базе Gemini 2.5 Pro, а удалённым участником — исследовательский ассистент на базе Gemini 2.5 Flash. В первом сценарии удалённый агент, получив делегированный запрос на новостную сводку, через серию уточняющих обменов добился того, что финансовый агент раскрыл свою историю чата, системные инструкции, перечень доступных инструментов и схемы их вызова. В тестовой среде разработческой панели эти промежуточные сообщения были видны, но в обычном пользовательском интерфейсе такие детали скрыты, поэтому пользователь получил только итоговый ответ.
Во втором PoC злоумышленник использовал ту же технику, чтобы вызвать выполнение инструмента buy_stock у клиента: после делегации задачи на сбор новостей удалённый агент «вплёл» дополнительные требования к обработке, и финансовый помощник автоматически совершил покупку 10 акций, не запросив отдельного подтверждения у владельца аккаунта. Логи активности клиента отражали дополнительные function_call и function_response между исходным запросом и финальным ответом — именно эти скрытые шаги и привели к несанкционированной транзакции.
Ключевые свойства атаки — состояние сессии, многотуровая природа, адаптивность и скрытность — делают её трудной для детектирования и опасной в условиях межорганизационной интеграции, где агенты из разных доменов общаются друг с другом. Вероятность успешной эксплуатации невысока в строго доверенной среде; риск возрастает при подключении внешних сторонних агентов.
Для защиты авторы предлагают многоуровневый подход. Необходимо применять внешнюю проверку для критичных операций — Human-in-the-loop — при которой исполнение приостанавливается и подтверждение проходит по отдельному, негенеративному каналу. Следует внедрять криптографическую верификацию участников через подписанные AgentCard, чтобы подтверждать происхождение и объявленные возможности собеседника. Контекст-грандинг предполагает создание «якоря» задачи при старте сессии и постоянную семантическую проверку поступающих инструкций, автоматически завершая диалог при отхождении от исходного намерения. Интерфейсы полезно обогащать видимыми индикаторами активности — журналами вызовов, визуализацией удалённых инструкций и метками внешних команд, что повышает шанс обнаружения злоупотреблений пользователем или оператором.
Практические рекомендации для организаций — не считать межагентную коммуникацию автоматически безопасной и проектировать оркестраторы с контролями, минимизирующими доверие и требующими внешней авторизации для операций с высоким риском. Unit 42 рекомендует проводить проактивные аудиты и обращаться в службу реагирования при подозрительной активности.
Авторы подчёркивают, что на момент исследования массовых случаев в реальных системах не зафиксировано, но техника остаётся реализуемой — достаточно убедить клиентский агент установить сессию со злонамеренным партнёром. По мере роста мультиагентных экосистем и усиления интеграции между провайдерами этот вектор надо учитывать с самого начала проектирования архитектуры и политик безопасности ИИ-систем.