Истории ужасов об агентах кодирования: Проблема секретности на 29 миллионов

Это Часть 4 нашей серии «Хроники ужасов агентов ИИ-кодирования», посвященная реальным инцидентам безопасности с участием агентов ИИ-кодирования и тому, как Docker Sandboxes защищает учетные данные от доступа агента на уровне выполнения.

В Части 1 мы рассмотрели шесть категорий сбоев в работе агентов ИИ-кодирования и причины их повторяемости. Агент запускается от вашего имени, с вашими разрешениями файловой системы и вашими учетными данными, и ничто не стоит между решением модели и выполнением командной оболочки. В Части 2 подробно рассматривался инцидент с rm -rf ~/. В Части 3 та же проблема была перенесена в продакшн-облачную среду. Эта проблема удерживает учетные данные в фокусе, но меняет вопросы местами: вместо того чтобы спрашивать, что агент делает с имеющимися у него секретами, мы спрашиваем, что происходит с самими секретами.

Сегодняшняя история ужасов: Агент, который прочитал чужие ключи

26 августа 2025 года вредоносные версии пакета сборки Nx были опубликованы на npm. Nx набирает около четырех миллионов скачиваний в неделю, а скомпрометированные релизы содержали post-install хук, указывающий на файл с именем telemetry.js:

Post-install хук срабатывает в момент завершения установки, поэтому полезная нагрузка выполнялась на каждой машине, которая скачала пакет, без открытия файла или просмотра diff. Бегуны CI пострадали точно так же, как и любой пользователь, чье расширение Nx Console проверяло наличие обновления версии в течение этого периода. Пакеты попали на npm напрямую, без подтверждения происхождения. Кампания получила название s1ngularity от публичных репозиториев, которые она создала для хранения украденного.

Затем telemetry.js сделал то, что делают похитители учетных данных: выполнил сканирование на наличие .env-файлов, закрытых ключей SSH, конфигурации облака, токенов npm и GitHub, а также хранилищ ключей кошельков. Эта часть является рутинной. Что сделало s1ngularity достойным упоминания, так это следующий шаг: вместо того чтобы поставлять собственный сканер, скрипт проверил систему на наличие уже установленного агента ИИ-кодирования и перепоручил эту работу ему.

В этом выпуске вы узнаете:

• Как зараженный пакет npm превратил установленные ИИ CLI в сканеры учетных данных
• Почему --dangerously-skip-permissions и их эквиваленты составляют суть всей атаки
• Почему код с поддержкой ИИ утекает секреты примерно в два раза чаще базового уровня
• Как Docker Sandboxes полностью изолирует учетные данные от агента

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

Проблема

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

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

• --dangerously-skip-permissions в Claude Code
• --yolo в Gemini CLI
• --trust-all-tools в Amazon Q

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

Скрипт проверяет, какие из трех двоичных файлов присутствуют, запускает тот, который находит, и перехватывает вывод. PROMPT — это то место, где находится инструкция, и она читается как обычная работа. Она говорит агенту искать из домашнего каталога на глубину до восьми уровней, сопоставлять имена файлов со списком, который включает .env, id_rsa, keystore и несколько форматов кошельков, и записывать каждый абсолютный путь, который он найдет, в /tmp/inventory.txt. Он также говорит агенту не использовать sudo, что является способом злоумышленника избежать запроса пароля, который выдал бы всю схему.

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

Масштаб проблемы

Нашли примерно 28,65 миллиона новых захардкоженных секретов, отправленных на публичный GitHub в 2025 году, что на 34% больше по сравнению с прошлым годом. Скрытая в этой общей сумме цифра имеет для нас значение: тот же отчет оценивает скорость утечки секретов в коде с поддержкой ИИ примерно в два раза выше базового уровня по всему GitHub. Код, написанный с помощью агента, теряет учетные данные примерно в два раза быстрее, чем код, написанный без него.

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

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

Технический разбор: Как установка npm превращается в утечку учетных данных

Подпись: Диаграмма, показывающая, как post-install скрипт заимствует уже авторизованный ИИ CLI для чтения учетных данных, оставленных разработчиком в зоне досягаемости.

Вот как разворачивается инцидент, шаг за шагом.

1. Установка

Разработчик или сборщик CI извлекает зараженную версию Nx, обычно в качестве транзитивной зависимости несколькими уровнями ниже. Ничто в команде не выглядит необычным, а показанный ранее post-install хук делает все остальное. Полезная нагрузка проверяет платформу перед всем остальным и завершает работу на Windows, поэтому под угрозой оказались машины под управлением macOS и Linux.

2. Инвентаризация

Скрипт обходит обычные места хранения учетных данных, которые на обычной рабочей станции являются именно тем местом, где живут рабочие учетные данные.

3. Заимствованный агент

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

Это читается как задача, которую вполне мог бы поставить разработчик, в чем и заключается суть. Указание не использовать sudo выдает осторожность атакующего, так как запрос пароля мог бы кого-то насторожить. Агент работает от имени разработчика, с правами доступа к файловой системе разработчика, поэтому он может читать все то же, что и разработчик.

4. Эксфильтрация

Собранные пути и содержимое файлов кодируются в base64 и отправляются в публичный репозиторий, созданный в собственной учетной записи жертвы на GitHub. Данные уходят через аутентифицированный сеанс GitHub, который уже был открыт на машине.

5. Каскадный эффект

Побережная нагрузка также перехватила токены GitHub. Используя их, злоумышленники сделали приватные репозитории жертв публичными, что вдобавок к уже украденным секретам раскрыло любые секреты, которые хранились в этих репозиториях.

Последствия

Всего за одну автоматическую установку разработчик:

• Раскрыл любые учетные данные, находившиеся в файлах .env, ~/.ssh и конфигурациях облаков
• Передал аутентифицированный токен GitHub, который является ключом ко второй волне атаки
• Опубликовал результаты в публичном репозитории под собственной учетной записью
• Перевел приватные репозитории в статус публичных, обнажив секреты, которых вообще никогда не было на его машине
• Получил необходимость ротации учетных данных для каждого сервиса, с которым они соприкасались

GitGuardian насчитал 2349 уникальных украденных секретов в 1079 скомпрометированных репозиториях, причем более 1100 из них все еще оставались действительными на момент анализа. Таков результат единственной автоматической установки на машине, где агент и учетные данные делят общую файловую систему.

Как песочницы Docker защищают секреты

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

Docker Sandboxes запускает агентов кодирования на базе ИИ в изолированных микровиртуальных машинах (microVM), каждая из которых имеет собственное ядро, файловую систему и сеть с политикой «запрещено по умолчанию», поэтому скомпрометированная зависимость, загруженная агентом, не может получить доступ к хосту, его учетным данным или другим рабочим нагрузкам. В выпусках 1 и 2 рассматривались команды, а в выпуске 3 — сама микровиртуальная машина. Что касается проблемы с секретами, здесь работают два свойства этой архитектуры.

Доступ к файловой системе в рамках рабочей области: внутри песочницы файловая система, которую агент может читать, ограничена исключительно рабочим пространством проекта и ничем больше. Согласно документации Docker Sandboxes, пользовательская конфигурация за пределами рабочей области, включая любые данные в домашнем каталоге, в виртуальной машине отсутствует. При воспроизведении этой архитектуры шаг разведки s1ngularity не дает никаких результатов. Скомпрометированная зависимость все еще может вызывать CLI и запрашивать список секретов, но искомые файлы отсутствуют в файловой системе, видимой агенту.

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

Вам не нужно принимать это на веру. Запустите временную песочницу и прочитайте переменную изнутри:

Вот сокращенный результат:

Внутри контейнера переменная представляет собой управляемую прокси-заглушку, а сохраненные учетные данные GitHub отображаются как удерживаемые, но не внедряемые. Именно этот вопрос задавал промпт s1ngularity каждой машине, до которой дотягивался. Внутри песочницы ответом служит подменный маркер. Учетные данные также можно не хранить в хранилище секретов хоста. Их извлечение из хранилища (vault) при запуске с использованием интеграции с 1Password, описанной в руководстве по рабочим процессам Docker Sandboxes, означает, что значение запрашивается при старте песочницы и никогда не записывается на диск ни с одной из сторон границы. Об этом я подробно написал the full setup, including the failure modes worth knowing about, в отдельной статье.

Как это выглядит на практике

Вот тот же рабочий процесс, настроенный так, чтобы учетные данные оставались на хосте.

Агент ведет себя одинаково в обоих случаях. Разница заключается лишь в том, к чему он может получить доступ.

Рекомендации по защите секретов от доступа агента

• Не передавайте агенту файлы с вашими учетными данными. Храните секреты на хосте и внедряйте их на сетевой границе. Секрет, который агент никогда не видит, невозможно закоммитить, записать в лог или вывесть из него обманным путем.
• Предоставляйте агенту рабочую область, а не всю машину целиком. Шаг разведки s1ngularity сработал только потому, что агент имел доступ ко всему. Лишите его этого доступа — и проводить инвентаризацию станет нечего.
• Относитесь к установленному ИИ-интерфейсу командной строки как к привилегированной автоматизации. Аутентифицированный агент на вашем диске — это постоянно действующий инструмент, и любой установленный вами пакет может им воспользоваться.
• Никогда не передавайте флаг обхода разрешений на хосте. Если вы хотите, чтобы агент работал без подтверждения каждого шага, запускайте его внутри песочницы. Именно граница безопасности делает пропуск подтверждений безопасным.
• Читайте журнал политик. Журнал sbx policy log фиксирует каждое соединение, разрешенное или заблокированное прокси — то есть именно то, что необходимо изучить после установки новой зависимости.

Действуйте

• Установите Docker Sandboxes. Посетите документацию Docker Sandboxes, чтобы установить sbx и запустить своего первого агента с просмотром файловой системы исключительно в рамках рабочей области.
• Перенесите свои ключи на прокси-инъекцию. Выполнение команды sbx secret set с последующим sbx run — это самый быстрый способ увидеть изменения на практике. Агент проходит аутентификацию в обычном режиме, а исходный ключ никогда не попадает внутрь контейнера.
• Ознакомьтесь с моделью безопасности. Документация по безопасности Docker Sandboxes подробно описывает обработку учетных данных, уровни изоляции и сетевые политики.

Заключение

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

Далее в нашей серии: в выпуске 5 рассматривается промпт-инъекция через документы и веб-контент, читаемые агентом, когда инструкции, перенаправляющие агента, поступают внутри тех данных, с которыми его попросили работать.

Узнайте больше

• Безопасный запуск агентов с Docker Sandboxes: посетите документацию Docker Sandboxes для начала работы.
• Изучите каталог Docker MCP: откройте для себя MCP-серверы, которые подключают ваших агентов к внешним сервисам через ориентированную на безопасность архитектуру Docker.
• Загрузите Docker Desktop: самый быстрый путь к контролируемой среде ИИ-агентов, включающий Docker Sandboxes, MCP Gateway и Model Runner в рамках одной установки.
• Прочитайте серию материалов «Истории ужасов MCP»: начните с выпуска 1, чтобы понять риски безопасности на уровне протоколов, которые дополняют рассмотренные здесь риски на уровне агентов.