Как доверенный инструмент мониторинга ошибок стал шлюзом для захвата ИИ-агентов

Я помню первую неделю, когда я интегрировал ИИ-ассистента для написания кода в свою локальную среду разработки. Это казалось мощным ускорителем моего рабочего процесса. Я мог попросить его провести рефакторинг запутанной функции или объяснить загадочную трассировку стека из моих логов. Прирост производительности был мгновенным. Я ни разу не остановился, чтобы поставить под сомнение модель доверия к данным, которые потреблял агент. Как и многие специалисты по безопасности, я предполагал, что агент работает в «песочнице», уважающей границы моей машины. Открытие «агентджекинга» (Agentjacking) компанией Tenet Security доказывает, что это предположение является опасным упущением в современной программной инженерии.

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

Архитектурный изъян, стоящий за агентджекингом

В центре этой уязвимости лежит фундаментальный парадокс в дизайне ИИ-агентов. Эти агенты созданы быть полезными, проактивными и способными предпринимать действия на основе технического контекста. Когда вы просите ИИ исправить баг, он часто ищет источники данных, которые дают подсказки о том, что пошло не так. Sentry — один из таких источников. Он собирает отчеты об ошибках из приложений и представляет их разработчикам для анализа. Чтобы упростить этот процесс, многие ИИ-агенты используют Model Context Protocol для запроса Sentry и получения последних событий ошибок.

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

Когда ИИ-агент запрашивает Sentry через протокол, он получает вредоносный отчет об ошибке злоумышленника наряду с легитимными. Агент интерпретирует инструкции внутри этого поддельного отчета как диагностические шаги или руководство по решению. Затем он выполняет эти инструкции с полными привилегиями разработчика. Это нарушение триады CIA, в частности, влияющее на целостность системы и конфиденциальность данных разработчика.

Отслеживание пути от публичного DSN до выполнения кода

Чтобы понять цепочку атаки, мы должны посмотреть, как данные перемещаются из публичного интернета в частный терминал разработчика. Процесс начинается с того, что злоумышленник находит DSN Sentry цели. Это несложная задача. Многие организации непреднамеренно раскрывают эти ключи в своих рабочих JavaScript-бандлах или публичных репозиториях. Как только у злоумышленника появляется DSN, он использует стандартный POST-запрос для отправки специально подготовленного события ошибки на эндпоинт приема Sentry.

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

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

Почему традиционные меры безопасности бессильны против этого метода

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

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

Реакция индустрии и реальность неустранимых уязвимостей

Когда Tenet Security сообщила об этих выводах Sentry, ответ был показательным. Sentry признала проблему, но заявила, что технически она не поддается защите. Это обычная ситуация в мире проектирования API и публичных точек приема данных. Если сервис предназначен для приема данных от любого клиента, он не может легко отличить реальный сбой от вредоносной инъекции без нарушения своей основной функции. Хотя Sentry внедрила глобальный фильтр контента для блокировки определенных строк полезной нагрузки, это реактивная мера. Злоумышленники, скорее всего, смогут найти новые способы форматирования Markdown для обхода таких фильтров.

Исследователи протестировали эту атаку на более чем 100 организациях и достигли 85% успеха. Они обнаружили как минимум 2388 организаций с открытыми и уязвимыми для инъекций DSN. Это говорит о том, что уязвимость распространена по всей отрасли. Она не ограничивается одним инструментом или конкретной моделью ИИ. Это системная проблема того, как мы строим автономных агентов, взаимодействующих с внешними источниками данных. Мы, по сути, выдаем этим агентам VIP-пропуск в наши самые чувствительные системы без вышибалы у двери для проверки документов.

Снижение рисков интеграции ИИ-агентов

В качестве контрмеры организации должны пересмотреть то, как они позволяют ИИ-агентам взаимодействовать со сторонними сервисами. Если оставить в стороне исправления, наиболее эффективной защитой является переход к модели нулевого доверия (Zero Trust) для контекста ИИ. Тот факт, что данные поступают из официального API, не означает, что эти данные безопасны для исполнения.

Разработчикам следует с опаской относиться к любому ИИ-агенту, который запрашивает разрешение на выполнение произвольного кода без ручного контроля. Если вы используете такие инструменты, как Claude Code или Cursor, вы должны сохранять высокий уровень здоровой паранойи. Проверяйте команды, которые предлагает агент, прежде чем нажимать клавишу ввода. Если агент предлагает решение ошибки Sentry, которое включает запуск скрипта оболочки, который вы не писали, остановитесь и сначала проверьте ошибку в панели управления Sentry.

Для организаций приоритетом является аудит публичного кода на предмет открытых DSN. Хотя DSN Sentry предназначены только для записи, они явно представляют критический риск, когда в дело вступают ИИ-агенты. Отношение к этим ключам с тем же уровнем осторожности, что и к приватному ключу API, является необходимым шагом. Следовательно, группы безопасности должны обновить свои модели угроз, включив ИИ-агентов в качестве потенциального вектора выполнения внешних данных.

Основные выводы для безопасного внедрения ИИ

Чтобы защитить свою среду разработки от агентджекинга и подобных атак типа инъекции, рассмотрите следующие шаги:

1. Проведите аудит всех публичных репозиториев и фронтенд-развертываний на наличие открытых DSN Sentry и смените все ключи, найденные в открытом виде.
2. Настройте ИИ-агентов для написания кода так, чтобы они требовали явного ручного подтверждения для каждой команды оболочки или изменения файловой системы.
3. Отключите автоматический сбор данных Sentry или другого внешнего контекста в инструментах ИИ, если вы не занимаетесь активной отладкой известной проблемы.
4. Обучайте разработчиков рискам промпт-инъекций и инъекций данных через доверенные сторонние интеграции.
5. Внедрите детализированные разрешения для ИИ-агентов, чтобы гарантировать, что они не смогут получить доступ к конфиденциальным файлам, таким как .env или .git/config, без конкретной причины.

Мы находимся в периоде быстрого внедрения ИИ, когда скорость разработки часто опережает развитие систем безопасности. Агентджекинг — это напоминание о том, что каждая новая интеграция создает новый путь для злоумышленника. Агенты, которым мы доверяем облегчение нашей жизни, защищены ровно настолько, насколько защищены данные, которыми мы их кормим.

Источники: Tenet Security Research Blog, Sentry Official Documentation, Model Context Protocol Specification, NIST AI Risk Management Framework.

Отказ от ответственности: Данная статья носит исключительно информационный и образовательный характер и не заменяет профессиональный аудит кибербезопасности или услуги по реагированию на инциденты.