Токен не умеет публиковать. Но всё ещё умеет навредить
Убрать у AI-агента право выпускать пакет - разумно. Решить, что после этого токен безопасен, уже ошибка.
18 сентября GitHub объявил stage-only токены npm. Автоматизация загружает версию на проверку, а мейнтейнер подтверждает выпуск с 2FA. Прямую публикацию npm с таким токеном отклоняет, даже если для автоматизации включён обход 2FA.
Мне нравится это разделение: агент может подготовить релиз, но не получает последнее слово. Для backend-команды это понятная схема и за пределами npm: собрать NuGet-пакет или контейнер отдельно от разрешения доставить его потребителям. Это архитектурная аналогия, не новая функция NuGet.
Но самая полезная строчка анонса находится ниже: stage-only токен сохраняет другие права записи. В том числе может перемещать dist-tags и помечать версии deprecated.
То есть запретить новую публикацию недостаточно. Если автоматизация передвинет тег latest на другую существующую версию, следующая установка по этому тегу получит уже другой пакет. Нового релиза при этом не было. Lockfile снижает такой риск для зафиксированных зависимостей, но не защищает все способы установки и обновления.
Я бы начинал подключение агента к выпуску с разбора конкретных операций: какие пакеты он видит, что может менять кроме версии и кто подтверждает итоговый артефакт. На проверку нужен сам пакет и его состав, а не только уверенное сообщение агента о зелёных тестах.
Ещё одна оговорка: режим включается добровольно. Старые токены от этого анонса не теряют право прямой публикации. Пока команда не поменяла токен и workflow, её релизный процесс остался прежним.
Для меня здесь практический вывод: права автоматизации стоит проверять по списку разрешённых действий, а не по успокаивающему названию роли. Особенно когда эти права получает агент.
У вас подготовка артефакта и его выпуск уже разделены по правам или всё делает один CI-токен?
