ИИ-агент ставит пакет без проверки: как закрыть уязвимость до запуска

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

Само указание «работай безопасно» этого не гарантирует. Агенту нужна одноразовая изолированная среда без производственных секретов, запрет автоматического выполнения команд и отдельный инструмент, который получает метаданные о пакете, не устанавливая его.

Как текст превращается в исполняемый код

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

Исследование атак через инструкции настройки охватило двенадцать сценариев пяти классов. Авторы установили, что результат зависит от сочетания модели и агентской оболочки: очевидные опечатки агенты замечали увереннее, тогда как перенаправление в недоверенный реестр пропускали почти повсеместно; детерминированная проверка имени, источника и версии до выполнения кода закрывала большую часть выявленного разрыва.

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

Сначала ограничьте последствия ошибки

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

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

Изоляция не делает вредоносный пакет безопасным. Она уменьшает область поражения, если проверка не распознала новый способ подмены.

Поставьте единый шлюз перед установкой

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

1. Разберите команду без выполнения. Выделите имя пакета, версию, параметры реестра, прямые URL, Git-репозитории, локальные архивы и файлы зависимостей. Составная команда не должна скрывать установку после другого действия.
2. Сверьте имя. Сопоставьте его с задачей, манифестом проекта и внутренним списком разрешённых зависимостей. Похожее написание, переставленные символы, необычный разделитель или ранее не использовавшийся пакет требуют ручного решения.
3. Получите метаданные отдельно. Инструмент только для чтения должен проверить существование пакета в ожидаемом реестре, его сопровождающих, историю выпусков и связанный репозиторий. Сам факт регистрации имени не доказывает безопасность.
4. Зафиксируйте источник. Разрешайте точный адрес официального или корпоративного реестра. Дополнительный индекс, прямую ссылку, Git-источник или локальный файл блокируйте до явного одобрения.
5. Зафиксируйте версию и целостность. Для новой зависимости не принимайте плавающую метку без проверки. Сверьте точную версию с базой уязвимостей и сохраните поддерживаемую экосистемой контрольную сумму или файл фиксации версий.
6. Покажите полный вердикт. Человек должен увидеть имя, версию, источник, причину блокировки и точную команду. Агент не может одобрить исключение, которое запросил сам.

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

Не запускайте сценарии во время проверки

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

Документация npm install описывает параметры ignore-scripts, allowScripts и strict-allow-scripts: первый отключает сценарии, а два других позволяют задать и строго применять политику разрешений. Эти настройки уменьшают риск выполнения кода при установке, но не заменяют проверку имени, источника и версии.

Если зависимость действительно требует установочного сценария, изучите его содержимое и вызываемые программы. Разрешение ограничьте конкретным пакетом в зафиксированной версии, а не всем деревом зависимостей.

Разделите патч и внешние действия

Агент может подготовить патч, но не должен сам принимать его и менять внешнюю систему. Перед подтверждением просмотрите изменения в манифестах, файлах фиксации версий, настройках реестра, сценариях package.json, pyproject.toml, Makefile, Dockerfile, конфигурации непрерывной интеграции и файлах правил агента.

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

Рабочая последовательность такова: агент предлагает зависимость и патч; шлюз извлекает имя, версию и источник; служебный процесс получает только метаданные; человек изучает вердикт; пакет устанавливается без сценариев в одноразовой среде; тесты разрешаются отдельно. Любое несовпадение останавливает процесс до нового независимого решения.

Контрольный список владельца репозитория

• Автоматическое принятие команд отключено, все установки проходят через единый шлюз.
• Среда одноразовая и не содержит постоянных секретов или доступа к производству.
• Имя новой зависимости сверяется с задачей, разрешённым списком и выбранным реестром.
• Источник задан точным адресом; его смена и прямые ссылки блокируются.
• Версия зафиксирована, проверена по уведомлениям об уязвимостях и защищена доступным механизмом целостности.
• Установочные сценарии отключены по умолчанию; исключение ограничено конкретной зависимостью.
• Человек просматривает изменения в манифестах, файлах фиксации, сборочных настройках и правилах агента.
• Сеть, публикация, развёртывание и производственные операции подтверждаются независимо.
• Журнал сохраняет исходную инструкцию, предложенную команду, вердикт шлюза и выполненное действие.

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

Читайте также:

• Семья — только первый агент социализации: кто ещё задаёт правила поведения
• Займ до зарплаты всё ещё может удвоить долг: как закрыть кассовый разрыв
• Уязвимость ИИ-агента не помещается в CVE: исследователи предлагают APV