Практические атаки на ИИ-агентов в организации

Разбираем первые инциденты, в которых злоумышленники атакуют ИИ-агентов, применяемых в компании.

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

Особенно привлекательны для атакующего ИИ-агенты, пишущие код, а также инструменты командной строки: Claude Code CLI, Gemini CLI, Codex CLI, Amazon Q CLI и их аналоги. Они умеют читать и изменять файлы, запускать команды оболочки, устанавливать пакеты и обращаться к внешним сервисам. Разработчики часто разрешают им действовать автоматически, чтобы не подтверждать каждую операцию вручную. Для атакующего такой агент становится «мультитулом», который уже имеет нужные привилегии, доступ к важным данным и одобрение от ИБ. Впрочем, атаке могут подвергаться и другие ИИ-агенты, например ассистенты финансового документооборота.

Чем опасны доверенные агенты

ИИ-агент отличается от другого ПО широкими правами доступа, разнообразием способов, которыми можно попросить его о нужных действиях, а также трудностями с детектированием аномального поведения агента. Установленные в организации средства защиты (EPP, EDR, XDR, SIEM) ищут вредоносные файлы, известные команды и подозрительные последовательности действий. Даже если конкретный зловред ранее не встречался, его может выдать поведение: массовый поиск документов, запуск PowerShell, обращение к хранилищам учетных данных или передача информации на внешний сервер со стороны неизвестного ПО вызовут шквал предупреждений в SOC.

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

Если такую ИИ-систему пытается проэксплуатировать злоумышленник, он будет передавать свое задание агенту на естественном языке. Просьбу найти пароли, API-ключи и криптовалютные кошельки можно сформулировать тысячами способов, на разных языках и с помощью иносказаний. А спрятать команду можно в любом потоке данных, который читает агент, включая текстовые поля документов, имена файлов и даже журналы сообщений об ошибках, как в одном из примеров ниже.

Возможность интеграции агентов с дополнительным ПО делает потенциальные атаки еще разнообразнее. Агентов подключают к электронной почте, мессенджерам, системам управления задачами, базам знаний и MCP-серверам. В результате вредоносная инструкция может поступить из любого источника, данные которого агент обрабатывает автоматически.

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

Атака на Nx: кодинг-агент ищет пароли

Наиболее известный и массовый пример — компрометация npm-пакетов Nx в августе 2025 года, получившая название s1ngularity. Злоумышленники воспользовались уязвимым процессом GitHub Actions, похитили токен для публикации пакетов и выпустили троянизированные версии нескольких пакетов @nx, которые воровали у разработчиков секреты.

Вредоносный постинсталляционный сценарий (postinstall script) проверял, установлены ли на компьютере очередной жертвы Claude Code, Gemini CLI или Amazon Q CLI. Обнаруженному агенту передавалась инструкция найти криптовалютные кошельки, файлы .env, API-ключи и другие ценные данные. Агенты запускались с флагами автоматического подтверждения операций: --dangerously-skip-permissions, --yolo, --trust-all-tools.

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

Вместо разработки собственного сложного инструмента для поиска атакующие использовали легитимного агента жертвы. Он уже умел ориентироваться в файловой системе, понимать назначение файлов и выбирать потенциально ценные данные. Правда, анализ атак экспертами обнажил и недостатки подхода: иногда ИИ отказывался выполнить неэтичную задачу. Также авторы атаки были вынуждены адаптировать код зловреда, чтобы он дожидался ИИ-агента, который может решать такую задачу довольно долго и выводить много промежуточных данных в ответ.

Связь через… журналы ошибок

Исследование AgentJacking не является вредоносной атакой, но по сути отличается от нее только тем, что ее авторы не собирались красть секреты. Разработав технику атаки, исследователи не постеснялись проверить ее глобально — и получили ответные обращения от ИИ-агентов из более чем сотни реальных компаний, включая очень крупные.

Атака использовала популярный сервис телеметрии Sentry. Веб-сайты и мобильные приложения автоматически отправляют туда сведения об ошибках, чтобы разработчики получали эти сведения без активного участия пользователей. Такие сообщения принимаются без аутентификации: ошибка может возникнуть у анонимного посетителя, о котором сайт или приложение ничего не знают.

Исследователи создали в Sentry собственный MCP-сервер, через который ИИ-агенты могут автоматически анализировать отчеты. Далее они отправляли ложное сообщение об ошибке с блоком, оформленным так же, как данные MCP-сервера Sentry. Внутри находилась косвенная промпт-инъекция — инструкция провести «дополнительную диагностику» с помощью команды такого вида: npx @controlled-validation-package --diagnose.

Если обработка ошибок была поручена агенту, он мог принять инструкцию за легитимную и выполнить команду, которая приводит к автоматической инсталляции стороннего пакета. В эксперименте этот пакет только обращался к контрольному серверу исследователей, не отправляя туда никаких важных данных. Настоящий вредоносный пакет мог бы похищать учетные данные, изменять код или закрепляться в системе. Найти жертву для такой атаки тоже несложно. Использование компанией Sentry легко обнаружить при анализе кода веб-сайтов или просмотре строк в коде мобильного приложения.

Примечательно, что, по словам авторов исследования, в Sentry признали проблему, но не приняли масштабных мер, а только заблокировали конкретный вариант вредоносного запроса, направляемого через MCP. Из скриншота в исследовании видно, что кто-то из сотрудников Sentry назвал защиту от атаки «технически невозможной» (technically not defensible).

Кража финансовых данных через MCP

Злоупотребление беспечными MCP-серверами, как в случае с Sentry, является только одним из способов атаки на этот протокол, который уже называют «USB для ИИ-агентов». Стандарт MCP появился всего год назад, был внедрен поспешно и изначально не был снабжен средствами безопасности. Поэтому атаки на него будут множиться, о чем недавно предупредили в Microsoft.

Угроза может таиться даже в самом описании MCP-инструмента, которым агент еще не воспользовался. Агент читает описание, чтобы решить, когда вызывать инструмент и какие данные ему передавать. Если поставщик MCP-сервера незаметно добавит туда инструкцию собрать дополнительные сведения, агент может выполнить ее как часть нормального рабочего процесса.

Microsoft описывает пример с финансовым агентом, который проверяет реквизиты поставщиков через внешний MCP-сервис. После изменения описания инструмента агент начинает прикладывать к ответу сведения о неоплаченных счетах. Пользователь видит обычный ответ, а конфиденциальные финансовые данные уходят владельцу сервера. Каждая отдельная операция выглядит разрешенной: агент действует с правами сотрудника, обращается к одобренному сервису и использует штатный интерфейс. Но утечка данных все равно происходит.

Из расплывчатой формулировки Microsoft до конца не ясно, является ли этот пример гипотетическим, или пост появился по мотивам расследования конкретной атаки. Но авторство Microsoft Incident Response намекает на последнее.

Промпт-инъекции уже стали массовыми

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

В Google при анализе данных Common Crawl также зафиксировали рост подобных материалов: с ноября 2025 по февраль 2026 года доля вредоносных инъекций увеличилась на 32%.

При этом подтвержденных случаев успешного взлома с помощью таких техник пока мало. Наличие инъекции на странице не доказывает, что агент выполнил команду. Но злоумышленники явно начали готовить веб-контент к эпохе, когда его будут читать не только (и не столько) люди.

Как защищаться от атак через агентов

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

Необходимо:

• вести реестр агентов, MCP-серверов и доступных им инструментов. Ограничивать при помощи (allowlist) инструменты агента и пакеты для установки списком доверенных и одобренных в службе ИБ компонентов. В список должны входить конкретные версии пакетов;
• контролировать изменения версий MCP-инструментов и других зависимостей, проводить с обновлениями повторный анализ перед тем, как включать их в реестр одобренных;
• использовать принцип наименьших привилегий и выдавать агентам только те права, которые нужны им в рамках конкретной задачи на время выполнения этой задачи;
• требовать подтверждения человеком установки пакетов, запуска сценариев, отправки файлов и других рискованных действий (human-in-the loop);
• запускать агентов в изолированных средах с ограниченным доступом к компьютеру разработчика;
• блокировать опасные режимы автоматического подтверждения;
• ограничивать исходящие соединения и разрешать передачу данных только одобренным сервисам;
• хранить секреты в централизованных защищенных хранилищах, использовать короткоживущие токены и регулярно их ротировать;
• передавать в SIEM и XDR журналы промптов, вызовов инструментов, команд оболочки и сетевых обращений агента. Чтобы эти инструменты были эффективны, им необходим подробный контекст работы агента и специальные наборы правил, адаптированные к «агентским» конвейерам обработки данных.