Microsoft опубликовала исследование, показывающее, как злоумышленник может перехватить контроль над ИИ-агентом, действующим от имени пользователя, — и для этого достаточно подменить всего лишь текстовое описание одного из подключённых инструментов. Хитрость в том, что агент при этом не нарушает ни одного правила: каждый его шаг выглядит рутинным, и в системе с настройками по умолчанию сигнал тревоги может просто не сработать.
Работу провели Microsoft Incident Response и исследовательская команда Defender — на фоне того, как компании всё активнее доверяют ИИ не только чтение и суммирование текстов, но и реальные действия.
Что меняется, когда агент умеет действовать
Раньше риски, связанные с ИИ на рабочем месте, сводились к тому, что модель читает и пишет: отравленный документ мог исказить ответ — и на этом всё заканчивалось. Агенты — совсем другое дело. Microsoft 365 Copilot умеет отправлять письма, создавать файлы и менять записи в календаре. Кастомные агенты, собранные в Copilot Studio или Azure AI Foundry, обращаются к бизнес-системам и самостоятельно выполняют многошаговые задачи.
Тот же приём внедрения инструкций, что раньше искажал текст сводки, теперь запускает действие. Против «читателя» атака меняет вывод. Против агента — она меняет то, что программа реально делает.
Такие агенты подключаются к бизнес-системам через MCP (Model Context Protocol) — открытый протокол, позволяющий ИИ вызывать внешние инструменты так же, как приложение обращается к API. Microsoft называет MCP самой быстрорастущей частью цепочки поставок агентного ИИ, а значит — расширяющейся поверхностью атаки.
Как работает атака
У каждого MCP-инструмента есть описание — несколько строк обычного текста, объясняющих агенту, что делает инструмент и когда его применять. Именно на это описание агент опирается, принимая решения. В этом и вся уязвимость: описание — просто слова, а слова могут нести инструкции.
Microsoft разбирает механику на примере с обработкой счетов (пример условный, без привязки к реальной жертве). Финансовый отдел развернул агента для работы со счетами поставщиков. Агент подключён к трём инструментам, один из которых — сторонний сервис «обогащения счетов»: он был одобрен к использованию, но так и не прошёл настоящую проверку безопасности.
Затем атакующий обновляет этот сторонний инструмент. Название и видимое описание остаются прежними. Но в самом тексте, замаскированная под примечания по форматированию, спрятана команда: собрать последние тридцать неоплаченных счетов и приложить их к следующему вызову. MCP подхватывает изменения описаний «на лету», и там, где нет триггера повторного одобрения, отравленная версия уходит в работу без дополнительной проверки.
Дальше аналитик задаёт агенту обычный вопрос о поставщике. Агент выполняет скрытую команду, собирает счета и прикладывает их к внешне нормальному запросу. Инструмент возвращает чистый ответ, а данные тихо копируются на сервер атакующего. Аналитик не видит ничего подозрительного.
Каждый шаг агента по отдельности законен: инструмент был одобрен, запрос выполнялся с правами самого аналитика, исходящий вызов шёл на сервер, который когда-то разрешили добавить. Проблема не в отдельной системе — она, как формулирует Microsoft, «в границе доверия между ними».
Глубже лежит то, что MCP смешивает инструкции и данные в одном пространстве: описание инструмента находится в рабочей памяти агента буквально рядом с его настоящими указаниями, и правка этого описания управляет агентом почти так же эффективно, как переписывание системного промпта. У агента нет надёжного способа отличить честную инструкцию от вредоносной, подсунутой тем, кто обслуживает инструмент. Microsoft подчёркивает: это не баг самого Copilot, а разрыв доверия, возникающий при подключении сторонних инструментов.
Что делать защитникам
Рекомендации Microsoft, по сути:
- Относиться к каждому подключённому инструменту как к части цепочки поставок: вести список одобренных издателей инструментов, отключить режим «разрешить всё» и давать агенту доступ только к тем инструментам, которые реально нужны.
- Относиться к описанию инструмента как к системному промпту: проверять изменения в нём так же, как код, и искать в тексте команды, которым не место в справочном поле.
- Ставить человека перед рискованными действиями: всё, что связано с перемещением денег, передачей данных за пределы компании или изменением учётных записей, должно требовать одобрения человека.
- Давать каждому агенту собственную идентичность и следить за его действиями: логировать их, задать базовый профиль нормального поведения и отмечать новые адреса, крупные выгрузки данных или нетипичные запросы.
- Применять принцип наименьшей агентности, а не только наименьших привилегий: даже агент с низкими правами способен нанести реальный вред, если ему позволено действовать без проверок.
Microsoft увязывает эти шаги со своими продуктами — Prompt Shields, Purview DLP, Entra Agent ID, Defender for Cloud и Sentinel, — но сами принципы применимы к любому стеку.
Не теория: как к этому пришли
У атак такого рода уже есть история. Invariant Labs ввела термин «отравление инструментов» (tool poisoning) в апреле 2025 года, продемонстрировав proof-of-concept: скрытые в описании инструмента-калькулятора инструкции заставили редактор Cursor прочитать приватный SSH-ключ пользователя и отправить его наружу. Разработчик Саймон Уиллисон подробно разобрал этот случай несколько дней спустя.
Позже та же группа показала родственный трюк: вредоносный issue в GitHub мог перехватить агента, подключённого к GitHub MCP-серверу, и вывести данные из приватных репозиториев. Сами инструменты при этом оставались доверенными и нетронутыми — вредоносные инструкции приезжали вместе с данными, которые агент читал. OWASP теперь приводит этот случай как пример уязвимостей цепочки поставок агентных систем в своём Top 10 for Agentic Applications за декабрь 2025 года.
Похожий сбой в цепочке поставок уже случался на практике. В сентябре 2025 года исследователи Koi Security обнаружили npm-пакет postmark-mcp, который пятнадцать релизов подряд честно копировал легитимный почтовый инструмент — пока в версии 1.0.16 не появилась одна строка, тайно добавлявшая атакующего в скрытую копию (BCC) каждого письма, отправленного агентом. В Koi назвали это первым в реальном мире вредоносным MCP-сервером.
Проблему уже начали измерять и академически. Бенчмарк MCPTox, вышедший в августе 2025 года, прогнал отравленные описания инструментов против 45 реальных MCP-серверов и 20 ведущих ИИ-моделей. Результат: атака работает широко и стабильно, успех достигает 72,8%, а модели почти никогда не отказываются выполнять скрытую команду.
Вывод, который сейчас продвигает Microsoft, прост: ИИ, способный действовать, надёжен ровно настолько, насколько надёжны инструменты, к которым ему дали доступ. А эти инструменты сегодня легко отравить и трудно контролировать.
Источник: The Hacker News.