Расследование в сфере безопасности связало Claude, OpenAI Codex и агенты для программирования Hermes от Nous Research с установкой незарегистрированных программных пакетов внутри корпоративных сред. Активность была обнаружена, когда исследователи тестировали файлы документации, которые направляли агентов к пакетам и доменам, не принадлежащим на тот момент какой-либо организации.

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

Что обнаружили исследователи

По данным Ars Technica AI, скрытый стартап по безопасности в Израиле просканировал 6 214 активных доменов, связанных с оборонными подрядчиками, компаниями Fortune 500 и крупными технологическими фирмами. Команда выявила 8 265 файлов, использующих emerging-конвенции llms.txt и llms-full.txt, которые сайты применяют для предоставления машиночитаемых описаний и навигации для ИИ-систем.

Среди этих файлов 120, размещённых на отдельных сайтах, ссылались на одно или несколько незарегистрированных имён пакетов или никем не занятых доменов. В сумме исследователи насчитали 227 команд на установку пакетов или доступ к доменам, которые на момент сканирования не принадлежали никому. Многие ссылки относились к распространённым экосистемам пакетов, включая PyPI и npm.

Чтобы проверить риск, исследователи зарегистрировали несколько заброшенных имён и разместили пакеты, предназначенные для связи с их сервером при запуске. Полученный beacon идентифицировал родительские процессы, связанные с Claude, Codex и Hermes. Исследователи также получили callbacks от нескольких десятков организаций, включая некоторые компании Fortune 500 и стартапы, после обработки тестовых пакетов.

Расследование не показало, что эти компании были заражены вредоносным ПО. Оно показало, что их среды выполняли proof-of-concept код или иным образом достигали инфраструктуры исследователей. Anthropic, OpenAI и Nous Research не ответили на запросы о комментарии к моменту публикации, согласно Ars Technica AI.

Проблема документации становится риском выполнения

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

Один документированный паттерн использовал инструкции pip install или npm install для несуществующих пакетов. Другой ссылался на несуществующий домен тестового фреймворка. Следовательно, проблема безопасности не ограничивается злонамеренным сайтом или намеренно отравленным prompt. Автор документации мог много лет назад ошибочно указать, устаревшую или галлюцинированную зависимость, оставив ссылку доступной для захвата кем-то другим.

Исследователи также описали случай, связанный с сайтом Clerk. Файл llms.txt содержал команду npx, связанную с именем пакета, которое позднее было занято и использовалось для распространения активного вредоносного ПО. Поскольку npx может загрузить и выполнить бинарный файл пакета без добавления его в манифест зависимостей проекта, эта команда создавала особенно прямой путь к выполнению.

Позднее Clerk исправила проблему в документации. Компания заявила, что пользователи, которые уже установили связанный пакет, @clerk/eslint-plugin, при описанных обстоятельствах не были подвержены воздействию вредоносного пакета. Остаётся неясным, привела ли путаница вокруг Clerk к реальным заражениям.

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

Расследование подчёркивает разрыв между моментом, когда принимается небезопасное решение, и моментом, когда корпоративные инструменты безопасности обычно ищут злоупотребления. Кодирующий агент, запускающий pip или npm в отношении известного пакета-репозитория, может выглядеть как обычная деятельность разработчика. Инструменты обнаружения и реагирования на конечных точках могут видеть одобренного ИИ-помощника, запускающего привычный менеджер пакетов через разрешённое сетевое соединение.

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

Это связано с prompt injection, но в одном важном смысле шире. Prompt injection обычно подразумевает намеренно внедрённые инструкции, призванные манипулировать моделью. В сценарии, описанном исследователями, исходная инструкция может быть подлинной и безвредной. Опасность возникает позже, когда заброшенный пакет или домен становится доступным атакующему.

Что это означает для создателей ИИ и корпоративных команд

Для разработчиков AI-агентов выводы усиливают аргумент в пользу того, чтобы относиться к полученной документации как к недоверенному вводу, а не как к продолжению команды пользователя. Агентам, которые могут выполнять shell-команды, следует отделять чтение инструкций от разрешения на выполнение, требовать подтверждения для новых зависимостей и проверять право собственности и происхождение пакетов перед установкой. Песочницы и ограниченный сетевой доступ могут снизить последствия, когда эти проверки не срабатывают.

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

Команды безопасности должны проводить аудит файлов llms.txt и llms-full.txt в своих доменах, но риск не ограничивается этими форматами. Агенты также используют README-файлы, руководства вендоров по SDK, issue-треды, примеры и документацию третьих сторон. Организациям понадобятся проверки зависимостей и контроль происхождения на всём пути извлечения, включая доверенных партнёров и проекты сообщества.

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

На что смотреть дальше

Первым сигналом будет то, раскроют ли Anthropic, OpenAI или Nous Research изменения в том, как их агенты обрабатывают команды установки, незарегистрированные пакеты и полученные инструкции. Исследователям безопасности и корпоративным пользователям также следует следить за контролями реестров пакетов, которые помечают повторное использование заброшенных имён, а также за платформами агентов, добавляющими проверки происхождения до выполнения.

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

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

Мнение Creati.ai

Этот инцидент — предупреждение об авторитете, а не только о точности модели. AI-агент может технически корректно обратиться к реестру пакетов и всё же действовать по небезопасной инструкции. Такое различие легко упустить, когда команда исходила с официального домена вендора.

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