Всем привет! Меня зовут Борис, я веду канал «Борис_ь с ml» про информационную безопасность и машинное обучение. Сейчас мой основной вектор исследований - мультиагентные системы и их безопасность. Поэтому в мае выступал на эту тему на III Форуме «Технологии доверенного искусственного интеллекта» с докладом «Протоколы MCP и A2A - безопасность для мультиагентных систем или новые угрозы?». По этой ссылке - презентация с выступления.
В этой статье раскрою и в чем-то углублю свое выступление, охватив сначала основы функционирования AI-агентов и мультиагентных систем (МАС), и заканчивая угрозами безопасности и мерами противодействия им.
В этой статье вы узнаете:
определения AI-агентов и МАС
устройство агентов с точки зрения MCP и A2A
основные угрозы для AI-агентов на основе MCP и A2A
что делать в первую очередь для обеспечения безопасности таких AI-агентов
AI-агенты - магия вызовов
Казалось бы, есть LLM, есть набор инструментов, и связать эти сущности между собой не должно быть сложно. Инструменты ведь написаны на том же самом коде, который LLM понимают; описаны тем же самым языком, который модели тоже понимают.
Но если спуститься на уровень реализации, то собственно возникает вопрос - в какой момент LLM узнает, что, например, погода сегодня в Иркутске - +18°C?
AI-агент - это программное приложение, то есть чистый код. Соответственно, вызов инструментов тоже описан алгоритмически, и зависит от фантазии художника разработчика.
Однако предлагаю рассмотреть базовый вариант этой логики, работающих на двух обращениях к LLM.
Все просто, и показано на схеме.
Ключевые моменты схемы:
Системный промпт модели содержит, помимо прочего, название функций/инструментов, описание работы и аргументов на вход. Соответственно, запрос потребителя снабжается таким системным промптом.
В первом обращении AI-агента к модели та генерирует запрос на вызов тех функций, что ей известны из п.1 и подходят для запроса потребителя.
Во втором обращении AI-агент в какой-то форме представляет результаты вызовов модели, и та генерирует окончательный ответ потребителю.
Благодаря такой механике, кстати, могут работать и некоторые агентные свойства.
А именно - "память" и "межагентские коммуникации". В первом случае достаточно реализовать функции на чтение, запись или изменение памяти. Сама память же является частью системного промпта. При чем хранилище можно настроить по разному: FIFO, LIFO, настроить TTL для промптов, и т.д. Во втором случае - возможно сделать функцию как на простую отправку сообщения и синхронное ожидание ответа от другого агента, так и продумать поведение агента при асинхронных функциях (например, опрос других агентов о статусе выполнения задач). Такое взаимодействие, кстати, заложено в протоколе A2A.
А теперь, чтобы перейти к следующему разделу, приведу еще раз свое опорное определение AI-агента - это ПО, использующее GenAI-модель для решения задачи и обработки сигналов внешней среды, способное производить действия во внешней среде без подтверждения человеком в 100% случаев, сохраняя в памяти и используя историю сигналов и действий.
Мультиагентные джунгли
Деревья в джунглях бывают столь сильно взаимосвязаны, что одно дерево от другого почти не отличить.
С AI-агентами мне видится аналогичная ситуация.
Как мы уже выяснили, технически агент - программа. Перекладывая на уровень инфраструктуры, это отдельный микросервис. Другой отдельный элемент инфраструктуры - сервер с моделью. Третий - любое приложение, являющееся для агентом внешней средой, пусть будет СУБД.
Что такое мультиагентная система (МАС)?
Определение этого понятия, с моей точки зрения, должно соответствовать некоторым принципам.
Что агентов в составе МАС объединяет друг с другом?
Как агенты в составе МАС взаимодействуют друг с другом?
Как агенты в составе МАС отличаются друг от друга?
Как две разные МАС можно отличить друг от друга? Можно даже вспомнить философию: свойство эмерджентности систем, например (система элементов имеет больше возможностей, чем сумма возможностей элементов).
Представим себе несколько вариантов, как можно сделать несколько агентов.
И для этого рассмотрим, что будет различать агентов одного и того же множества, если, при прочих равных:
Сделать несколько AI-моделей, например, ChatGPT и DeepSeek. Агент "А" обращается к первой, Агент "Б" ко второй.
Подтверждать у Агента "А" 10% случайных действий, а у Агента "Б" - 50%.
Написать несколько программ (агентов), которые по разным алгоритмам производят работу LLM с промптами, по-разному организуют память
Дать агентам разные наборы тулов/функций/действий
Сделать агентам разные промпты с ролью и задачами агента
Во многом на это размышление меня натолкнула статья Yoav Goldberg от 24.11.2024, на которую меня навел Николай, за что ему спасибо отдельное)
Итак, какие различают ли AI-агентов в МАС перечисленные выше свойства?
Нет. Для меня представляется очевидным, что вариант 1 (различные модели) агентов не различает никак. Это два экземпляра кода одного и того же AI-агента.
Нет. Тоже не считаю этот принцип достаточно сильным для разделения агентов. То есть сказать, что например пять инстансов одного того же кода AI-агента с разным уровнем автономности - это МАС, было бы ошибкой, с моей точки зрения.
Нет. Разная детерминированная часть логики AI-агентов - весомо, но если они делают одно и то же, и возможности их одинаковы, какой в этом смысл? Так что тоже недостаточно.
Да. Подбираемся к интересному, а именно - различие возможных действий. Начинается оно с отличий в системном промпте в описании функций. Ну и конечно, в прикладных решаемых задачах. Именно благодаря этому различию МАС может проявить эмерджентность.
Да*. Различные промпты - важно, но ненадежно, так как различие нечеткое, зависящее от вероятностной природы модели-мозга агента. Я бы сказал, что можно собрать несколько AI-агентов с одинаковыми тулами и разными системниками в МАС, если у них выполняется условие - контекст AI-агентов не является общим. Откуда такое условие? Об этом говорит как Yoav в статье, так и недавний блогпост Cognition (разработчик Devin). Но Cognition, в отличие от Yoav'а, не видят в этом проблемы, и считают общий контекст полезным приемом для повышения качества МАС.
Принимая во внимание определение AI-агентов выше, скажем, что МАС - это множество AI-агентов, взаимодействующих друг с другом для решения задачи, выполняющих хотя бы одно из следующих условий:
AI-агенты имеют разные наборы возможных действий
AI-агенты имеют разные собственные задачи в системном промпте и их контекст (история сигналов и действий) не является общим
В этой статье, конечно, не поговорим о типах МАС и их примерах, но об этом как-нибудь в другой раз...
Устройство AI-агентов по протоколу MCP
Об этом протоколе существует немало материалов и статей, так что остановлюсь только на самом главном, добавив немного своих мыслей.
Протокол регламентирует архитектуру AI-агента, задействованную в его взаимодействиях с внешней средой. Конечно, речь идет о действиях агента.
Разработчиками из Anthropic предлагается разделить код AI-агента на три части:
MCP-Хост отвечает за логику обработку входных и выходных сигналов, за обращения к LLM, и возможно за алгоритмы планирования агента. А еще парсер запросов на исполнение действий от LLM реализуется в нем.
MCP-Клиент - универсальный для разных AI-агентов модуль, получающий от Хоста запросы на исполнение действий, преобразующий их MCP-формат, и отправляющий на MCP-Сервер
MCP-Сервер содержит код действий, реализуемых во внешней среде, и выступает в роли приемника стандартных запросов от Клиентов и передаче им результатов выполнения действий.
В стандартной версии есть правило "один Клиент - один Сервер", и у одного Хоста могло быть много Клиентов. Но сейчас существует и многосерверный Клиент, так что такая условность ушла.
Важно понимать, что происходит при запуске нового AI-агента по протоколу MCP. Но прежде, чем говорить о ЖЦ AI-агента, пара слов о реализации MCP.
В микросервисной архитектуре три элемента агента выше (Х, К, С) - отдельные сервера. Но вот транспорт между ними может быть разный. MCP поддерживает два формата - stdio и http, то есть локальный и по сети. В небольших непромышленных масштабах лучше начинать с конструкции Х+К на одном веб-сервере, С на другом.
Жизненный цикл AI-агента в протоколе MCP
Разработчик написал код, и внес в конфиг К перечень доступных ему С.
Запуск К (Х тоже запускается, или может быть уже запущен)
К отправляет на известные ему Сервера дискавери-запрос на предоставление описаний имеющихся у них тулов.
К получает все функции и записывает их в системный промпт агента
При получении входящего сигнала Х передает К информацию о запрашиваемых действий
К связывается с нужным С
С исполняет действие и передает К результат
К передает результат Х, а тот формирует выходной сигнал AI-агента.
Серые зоны MCP
MCP вполне может быть доработан и для обеспечения коммуникации AI-агентов. Для таких целей всего лишь нужен отдельный Сервер, который обладает функциями синхронной p2p, асинхронной p2p, асинхронной широковещательной, и другими передачи сообщений. А прием сообщений был бы реализован как стандартная обработка входных сигналов Хостом AI-агента.
Возможно, я чего-то не знаю, и такое уже в разработке или разработано? Пишите в комменты ссылки, если видели.
Устройство AI-агентов по протоколу A2A
Протокол A2A распространен меньше, чем MCP. Его разработал Google и решает задачу по управлению общением AI-агентов.
AI-агент в рамках этого протокола тоже разделяется два сегмента:
A2A-клиент (К) - код, отправляющий запросы другим агентам в виде объектов под названием Task. Подразумевается, что любое отдельное сообщение от агента к агенту может быть только задачей. Но в рамках задачи, то есть уже начавшегося общения, К может отправлять также и объекты вида Messages для уточнений и передачи промежуточных результатов. И, наконец, результат выполнения задачи К получает в виде объекта Artifact.
A2A-сервер (С) - вторая половина агента, принимающая запросы других агентов и отправляющая ответы. То есть получает Task'и от Клиентов, и в ответ шлет Message или Artifact. Но прежде этого, С хранит так называемую карточку агента (Agent Card), в которой записано название агента, описание, и главное - навыки агента (Skills). И сама карточка, и скиллы - json-объекты. Скиллы перечислены списком, и каждый скилл имеет название, перечисление возможных типов входных данных и возможных типов выходных данных. Важно заметить, что навыки - не равно функции агента. Поэтому у них описания конкретных входных аргументов и выходных значений. Потому что функции - это вотчина MCP.
Серые зоны A2A
Совместимость с MCP
Да, A2A заявлен как совместимый с MCP протокол. Только вот конкретного порядка взаимоувязки набора навыков и набора функций агента разработчики пока не представили. Хотя пишут, что вы можете сделать это самостоятельно в своем гайде по использованию A2A вместе с MCP (https://google-a2a.github.io/A2A/topics/a2a-and-mcp/#example-scenario-the-auto-repair-shop).Дискаверинг
Также вызывают вопрос способ дискаверинга агентов. В спецификации параграф на тему обнаружения карточек агентов (https://google-a2a.github.io/A2A/specification/#52-discovery-mechanisms) довольно немногословен: задавайте нужны url'ы в конфигах изначально, или делайте механизм реестров агентов. Второе вызывает наибольший интерес, особенно то как бы они предложили решить вопрос доверенности реестра, но здесь пока что остается серая зона протокола.Мультиагентные системы
На данный момент все агенты в A2A равноправны, и никакие иерархические организационные элементы в карточках не предусмотрены. Надеюсь, в будущем протокол обзаведется, например, сущностью Multiagent System, у которых будут свои задачи, ролевая модель доступов агентов к общению друг с другом, приоритетность задач, и тому подобное.
Модель угроз МАС с MCP и A2A
Давайте немного поразмышляем, в чем могут состоять вектора атак на мультиагентную систему, реализующую упомянутые протоколы. Как известно, промпт-атаки заключаются в воздействии нарушителя на входной текст для GenAI-модели.
За основу модели на рисунке я взял сберовскую модель в части агентных угроз (Ag01-Ag12). Так что угрозы 1, 2, 5, 6, 9-11 - это про неспецифичные для протоколов истории.
Выделим основные угрозы для MCP и A2A
Угроза 4. Введение промпт-атаки в хранящиеся на MCP-сервере описания инструментов или подмена кода легитимных инструментов.
Описание инструментов MCP-сервера пользователь не видит, следовательно, самостоятельно потенциальную промпт-атаку при компрометации сервера не заметит. Компрометация может быть осуществлена несколькими путями (которые, конечно, сильно зависят от контекста организации). Например, это может быть ошибочно принятый доверенным open-source сервер, который занесли во внутренний контур. Или злоумышленник по сути в рамках тактик Execution, Persistence, или Privelge Escalation может отравить уже проверенный сервер.
В эту угрозу я также заложил и другой способ компрометации MCP-сервера - добавление нелегитимного кода в функцию. И так как GenAI-модель агента код функции не получает, для нее не будет разницы, что на самом деле она запрашивает на исполнение.
Более того, существует практика поставки описаний MCP-описаний тулов в докстринги соответствующих функций для удобства разработки. И это позволяет сделать, можно сказать, докстринг инъекцию, прервав контекст докстринга с помощью тройной кавычки, введя код, и закрыв оставшийся хвост докстринга еще тремя кавычками.Угроза 3. Введение промпт-атаки в хранящиеся на MCP-клиенте описания инструментов.
Такое же воздействие, но уже на MCP-клиент. Ведь MCP не регламентирует частоту синхронизации Клиента и Сервера, значит, Клиент может и прихранить какое-то время описания. Которые также становятся доступными нарушителю для компрометации.Угроза 7. Подмена AI-агента при A2A-дискаверинге.
Данная проблема безопасности возникает из-за нерегламентированности процедуры обнаружения агентов. Например, если в конфиге просто написан какой-то адрес другого агента, то нарушителю ничего не мешает разместить по этому адресу свой mitm-сервер, что при перехвате будет как минимум сниффить трафик агентов, а как максимум - осуществит промпт-атаку на агента.Угроза 5. Распространение промпт-атаки.
Как я уже писал, эта угроза может случиться и в любой другой МАС, не только с нашими протоколами, но в A2A ее некоторым образом усиливает.
Карточка агента, как известно, используются для того, чтобы другие агенты знали, какие задачи может выполнять обладатель карточки. Но вот проблема - создаваемые в A2A задачи не привязываются к скиллам, это не прописано в протоколе. А это значит, что создать задачу с промпт-атакой - совершенно легальное дело. Ведь не надо привязывать ее к какому-либо навыку. По сути еще одна серая зона протокола.Угроза 8. Введение промпт-атаки в A2A-карточку агента.
Чтобы карточка агента работала, она, естественно, попадает во входной текст для GenAI-модели. А значит, может служить точкой внедрения промпт-атаки. Чем конечно, при отсутствии мер защиты и проверки, легко воспользоваться.
Меры защиты AI-агентов на MCP и A2A
Прежде всего, рекомендую на эту тему ознакомиться с недавно вышедшим от Сбера гайдом по агентам, я описывал его недавно тут. В нем есть 12 мер, с которых будет неплохо начать при обеспечении безопасности ваших AI-агентов.
Полный перечень приведен в таблице на изображении. Сосредоточу внимание на трех самых базовых в порядке их практической реализации:
Санитизация текстовых объектов
MCP-сервера, а точнее их функции, и A2A-карточки агентов - потенциальные поверхности атаки. Соответственно, необходимо реализовать проверки на наличие промпт-атак и джейлбрейков в этих объектах. А также - проверять код функций на вредоносность.Контроль целостности, использование подписанных объектов данных
После того, как текстовые объекты были проверены, они должны получить идентификаторы и занесены в реестры с хэш-дайджестом. Таким образом, при передаче и перед использованием текстового объекта, проверка хэша позволит проконтролировать, что промпт-атака не была внедрена на одном из этапов транспортировки текста до GenAI-модели.Реестр агентов, реестр MCP-серверов, связь скиллов и функций
Из предыдущего пункта следует создание реестров доверенных сущностей. Прежде всего, доверенных агентов, чтобы предотвратить mitm-атаки или иные атаки с подменой адреса. Доверенный агент из реестра будет иметь проверенный системный промпт, безопасный код управления входными/выходными сигналами и памятью, и обращаться к доверенным MCP-серверам, а также обладать сертификатом (как в ssl/tls). MCP-сервера также необходимо проверять на подлинность с помощью проверки их сертификатов.
Помимо этого, необходимо ввести связь между реестрами агентов и серверов через навыки и функции агентов. Навык должен быть обеспечен функциями, а сами навыки - предназначены для выполнения тех или иных задач. А функции, в свою очередь, должны затрагивать только те информационные ресурсы, которые ассоциированы с поставленной задачей. Так можно будет предотвратить нецелевое (т.е. вредоносное) использование функций агентами, и в случае инцидента, отследить причинно-следственные связи.
Заключение
Поговорили про базовые определения и понятия, затронули основные угрозы для МАС с использованием протоколов MCP и A2A. Раскрыли некоторые меры безопасности, которые можно предпринять для обеспечения безопасности, если у вас с организации возникает множество различных агентов, и непонятно, какие меры контроля к ним применять.
Подводя итоги, скажем так:
MCP достаточно гибкий протокол, дает широкие возможности по изменению и адаптации под требования безопасности
A2A менее гибкий протокол, есть уязвимости из-за слабой проработки интеграции с MCP, нерегламентированного способа дискаверинга AI-агентов, несвязанности задач и навыков агентов
Протоколы усложняют реализацию некоторых угроз, но открывают новые угрозы
Что осталось за кадром? Во-первых, различия в работе мультиагентных систем при их разном устройстве, иерархии агентов внутри: древовидной иерархии, или при командной структуре, или децентрализованной организации (условно, Round Robin). Во-вторых, примеры атак и конкретные кейсы. Хотя если очень интересно, парочка примеров есть в моей презентации с форума. И в третьих, другие протоколы, на которых могут работать AI-агенты. LAP, ACL, ANP, IEEE P3394, agents.json, и другие.