13 июля 2025 года в публичный репозиторий AWS попал вредоносный код для Amazon Q Developer, а уже через четыре дня он доехал до релиза VS Code-расширения с почти миллионной установочной базой. История, о которой сообщает The New Stack, хорошо показывает, почему безопасность AI-агентов для разработчиков уже не факультативная тема, а новый обязательный слой DevSecOps.
Речь идет о Q Developer, бесплатном расширении Amazon для IDE, которое умеет читать проект, предлагать изменения и запускать команды от имени разработчика. Это уже не классический автокомплит, который тихо подсказывает строку кода, а полноценный агент с доступом к репозиторию, локальным файлам и, в некоторых сценариях, к облачным инструментам. Именно поэтому инцидент оказался неприятным не только для AWS, но и для всей индустрии: ошибка в пайплайне сборки тут превращается не просто в supply chain-историю, а в попытку подсунуть «полезному» агенту инструкцию на уничтожение среды.
По данным пересказа статьи и подтвержденным материалам AWS, пользователь GitHub с ником lkmanka58 отправил pull request в репозиторий aws-toolkit-vscode 13 июля 2025 года. Через четыре дня код попал в релиз Amazon Q Developer for VS Code версии 1.84.0. Внутри был промпт, который фактически задавал агенту цель «очистить систему до почти заводского состояния» и удалить локальные файлы, а также облачные ресурсы через AWS CLI. Если перевести это с языка AI-продуктов на язык эксплуатации, то разработчику едва не доставили через официальный канал не троян, а очень исполнительного цифрового стажера с доступом к кнопке Delete Everything.
Ключевая деталь здесь даже не в формулировке вредоносного промпта, а в том, как он вообще оказался в поставке. В бюллетене AWS от 23 июля 2025 года компания признала, что в конфигурации CodeBuild использовался GitHub-токен с избыточными правами. Именно этот токен позволил злоумышленнику внести вредоносный код в open-source-репозиторий так, что он автоматически попал в выпуск расширения. Позже AWS выпустила версию 1.85.0, удалила 1.84.0 из каналов распространения и присвоила инциденту идентификатор CVE-2025-8217. Отдельная ирония в том, что реального ущерба, по данным AWS, не случилось из-за синтаксической ошибки: вредоносный код был распространен, но не исполнился.
Утешение, мягко говоря, так себе. Если защита держится на том, что атакующий где-то промахнулся скобкой, это не защита, а удачное стечение обстоятельств. Для русскоязычных команд это важный сигнал: безопасность AI-агентов нельзя сводить к разговору о «галлюцинациях модели» или лицензировании кода. Главная проблема в другом: агенту дают полномочия действовать в доверенной среде, а значит, любая инъекция в контекст, цепочку поставки или набор разрешенных команд становится уже не багом интерфейса, а потенциальной операционной аварией.
Контекст у этой истории тоже показательный. Весной 2025 года AWS активно развивала агентный режим Q Developer: сначала в CLI, затем в IDE. Компания прямо продвигала сценарии, в которых агент читает и пишет файлы, генерирует диффы, выполняет shell-команды и помогает с задачами за пределами обычного кодогенератора. На бумаге это выглядит как естественная эволюция AI-инструментов для разработки. На практике же каждая такая «удобная» возможность расширяет поверхность атаки. Если раньше компрометация расширения могла привести к подмене подсказок или краже телеметрии, то теперь на кону уже локальная файловая система, секреты, CI-артефакты и облачная инфраструктура.
Ситуацию делает еще интереснее другой эпизод вокруг Amazon Q. Исследователь Иоганн Рехбергер летом 2025 года отдельно показал, что агент можно подтолкнуть к выполнению неожиданных bash-команд через prompt injection, в том числе используя особенности команды find. По его данным, проблема была быстро закрыта в той же ветке обновлений, но сама связка симптомов выглядит слишком знакомо: агент умеет много, проверок на пути мало, а граница между «безопасной автоматизацией» и «удаленным исполнением команд» местами держится на эвристиках. И это уже не проблема одного вендора. С теми же рисками сейчас живут все, кто встраивает AI-агента в редактор, терминал, CI или DevOps-контур.
Для бизнеса вывод тоже достаточно приземленный. Если в компании уже используют AI-агентов для разработки, проверять нужно не только модель и вендора, но и весь контур доверия вокруг них: кто подписывает релизы, какие токены лежат в build-пайплайнах, какие команды агент может запускать без подтверждения, как ограничен его доступ к AWS CLI, Kubernetes, Git и секретам. Иначе получится странная картина: команда неделями спорит о политике доступа к production, а потом сама ставит в IDE помощника, который по замыслу должен «сам разобраться» и у которого слишком длинные руки.
Главный вопрос после этой истории звучит неприятно, но честно: готовы ли разработческие инструменты к роли автономных исполнителей, или рынок слишком быстро перескочил от автодополнения к агентам с полномочиями? Пока ответ выглядит так: модели стали заметно полезнее, а инженерная дисциплина вокруг них еще не успела догнать собственный маркетинг. Подробности исходного кейса можно посмотреть в материале .