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