Vercel Agent получает доступ к продакшену через план с scope-ами и одним апрувом

Vercel опубликовала разбор того, как её Vercel Agent получает доступ к боевым системам. Исходная проблема знакома любому, кто пробовал отдавать агентам продакшен: запрос «почини деплой» заранее не говорит, какие действия потребуются и какие права понадобятся. Широкий доступ означает, что ошибка зазаденет посторонние ресурсы. Подтверждение каждого шага превращает ревью в автоматическое нажатие «Одобрить». Vercel выбрала третий путь: агент сначала расследует, затем предлагает план, и апрув плана выдаёт ровно те дополнительные права, которые нужны для его выполнения.

План как единица разрешения

На примере сломанного деплоя схема выглядит так. Агент смотрит последние деплои и билд-логи, сравнивает упавший деплой с последним рабочим. Для этого хватает read-only доступа, и расследование идёт автоматически. Если из него вырастает предложение сделать редеплой, агент формирует план и запрашивает scope read-write:deployment. Пользователь видит и действие, и нужный для него доступ в одном решении.

В плане связаны четыре слоя: намерение (чего хочет пользователь), работа (задачи агента), доступ (scope-ы этих задач) и принуждение (токены и проверки на стороне API). Каждый сохранённый план хранит задачи, прогресс и запрошенные scope-ы, которые суммируются по всем шагам. Короткую справочную проверку агент может выполнить вообще без плана. Для долгих расследований создаётся read-only план, чтобы пользователь мог следить за ходом работы.

Базовый уровень сейчас включает все зарегистрированные scope-ы с префиксом read:. Подтверждение нужно, если план выходит за этот уровень или содержит поддерживаемые внешние действия, например открытие pull request в GitHub. Vercel прямо оговаривает: чтение тоже может раскрыть чувствительные данные, так что автоматическое одобрение не равно безвредности.

Токены, которые модель не может обойти

Vercel Agent работает как Vercel App, которое пользователь авторизует в рамках команды. Эта авторизация ограничена правами самого пользователя, поэтому апрув плана не даст агенту то, чего нет у человека. OAuth-сервис обменивает авторизацию на короткоживущие токены с конкретными scope-ами, а API проверяют токен при каждом запросе.

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

Какой credential используется, зависит от работы:

• расследование: базовый токен с read-only scope-ами;
• одобренные изменения в Vercel: базовые scope-ы плюс утверждённые дополнительные;
• внешние действия: credentials и права конкретного провайдера.

Один план может включать и изменения в Vercel, и pull request. Пользователь проверяет всё сразу, но провайдеры используют раздельные права. Доступ GitHub привязан к владельцу и репозиторию: апрув для acme/storefront не распространяется на acme/payments, там нужен отдельный.

Единый реестр scope-ов и возобновление работы

Сначала у Vercel Agent был собственный список разрешений, и он расходился с OAuth-сервисом, выдающим токены. Теперь при старте сессии агент загружает определения из общего реестра scope-ов в in-memory каталог. Каталог используется для валидации плана (неизвестные и некорректные имена отклоняются до показа пользователю), для решения о необходимости апрува и для подготовки токена. Если задача по правилам файрвола запросит устаревший scope, система отклонит план и вернёт список допустимых, чтобы агент исправился, а не получил более широкий доступ по умолчанию. Каталог кешируется, поэтому проверки отражают его состояние до очередного обновления.

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

Что оставили открытым

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

Что взять в свои агентные системы

Для команд, которые строят агентов для инфраструктуры, схема даёт несколько ориентиров. Разделяйте расследование и изменение. Показывайте человеку действие простым языком рядом со scope-ами. Берите определения прав из того же источника, что и выдача токенов. Проверяйте активность плана перед каждым использованием credential, а не только при выдаче. И не рассчитывайте, что инструкции модели ограничат её сами: ограничения должны жить в API.