Подробный разбор · Около 5 мин чтения
Vercel планирует заменить постоянные ключи агентов ограниченными удостоверениями
Инструменты OIDC, обмен токенами во время работы и будущие правила Marketplace требуют корректных политик доверия и прав пользователя.
- Опубликовано здесь
- Дата источника
- Источник проверен
В технической статье от 22 октября 2026 года CTO Vercel Malte Ubl описал переход от многократно используемых секретов к короткоживущим удостоверениям сервисов. Речь о получении доступа ИИ-агентами, его проверке провайдерами и стимулах менять интеграции.
Слушать новости
Прослушайте эту статью или включите новости подряд.
Подготовка чтения…
Голос устройства
Речь обрабатывает браузер или устройство. AISubHub не отправляет текст в аудио-API. Доступные голоса и работа при заблокированном экране зависят от устройства.
При продолжении короткая фраза может повториться.
Кратко
- Vercel сообщает о поддержке безопасной аутентификации у 8,4% из более чем 1000 опрошенных SaaS-провайдеров; это не оценка безопасности всей отрасли.
- Компания планирует предупреждения в Marketplace к 30 ноября 2026 года и удаление провайдеров, не выполняющих заявленные требования, к январю 2027 года. Это пока не результат исполнения.
1. Короткий срок ограничивает конкретный риск
Агент, вызывающий несколько сервисов, может получить ключи с правами шире текущей задачи. Украденная копия способна работать и после завершения разговора. Ubl называет репозитории, чаты, скомпрометированные зависимости и инъекции инструкций возможными путями утечки. Шифрование хранимых секретов не мешает вредоносному коду читать учетные данные, доступные работающему приложению. Важны и объем полномочий, и срок их действия.
Более 1000 провайдеров и 8,4% — данные собственного опроса Vercel. Статья недостаточно раскрывает выборку и классификацию, чтобы считать их репрезентативной оценкой отрасли. Это заявленная поддержка методов, а не вероятность взлома или качество реальных развертываний. Рассказ Vercel о тысячах инженерных часов на профилактическую ротацию ключей также не равен измеренной экономии каждого клиента.
2. Удостоверение должно соответствовать границе доверия
В OpenID Connect, или OIDC, доверенный эмитент подписывает временный токен, идентифицирующий приложение. Принимающий сервис проверяет его, затем определяет допустимые операции. Правила проекта и окружения ограничивают принимаемое развертывание, а audience указывает предназначенный сервис-получатель. Одна действительная подпись не доказывает, что этот API должен принять токен или разрешить конкретное действие.
Утекший временный токен остается пригодным в пределах своих прав до истечения срока. Короткий срок ограничивает использование копии, но не предотвращает утечку или получение замен скомпрометированной нагрузкой. По словам Vercel, федерация общедоступна с 2024 года и позволяет менять удостоверение развертывания на временные данные AWS, Google Cloud и Azure. Blob, AI Gateway и Sandbox здесь — существующие примеры, а не сервисы, впервые запущенные вместе со статьей.
3. Connect и OIDC UI решают задачи разных сторон
Vercel Connect использует удостоверение развертывания для получения токена провайдера во время работы. В примере Linear указаны пользователь и область чтения. Нужны настроенный и связанный с проектом коннектор, подключенный аккаунт пользователя и поддерживаемые провайдером области доступа. Вызов функции не открывает произвольные аккаунты, не отменяет подключение пользователя и не унифицирует права всех провайдеров.
OIDC UI предназначен поставщикам API: реестр shadcn/ui предоставляет формы политики доверия и серверный код проверки. В показанном конструкторе разделены эмитент, команда, проект, окружение и audience. Это может сократить повторную разработку. Наш анализ: инструмент не выбирает правильную границу доверия. Чрезмерно широкий прием проектов или неправильный audience остается ошибкой политики, даже если форма и проверяющий код успешно сгенерированы.
4. Ускорение не устраняет сетевой обмен
Статья различает чтение уже доступного токена и его обмен. Vercel Functions получает удостоверяющий токен платформы в заголовке запроса; SDK читает его без нового получения. Платформа повторно использует еще действующие токены; Connect кэширует токены провайдера внутри процесса и обновляет ближе к истечению. Но пользовательский audience и обмен у провайдера по-прежнему требуют сетевых вызовов. Нулевая дополнительная задержка для любой аутентификации не обещается.
Пример Cosmos DB показывает этапы: Azure должен доверять проекту Vercel и стандартному audience; ClientAssertionCredential предъявляет токен Vercel для обмена на токен доступа Azure; CosmosClient использует результат. Помимо первого успешного обращения нужно учитывать обновление и доступность провайдера. Независимого теста задержек или гарантии, что кэш исключит сбои аутентификации, статья не содержит.
5. Сроки Marketplace — запланированный коммерческий стимул
Ubl выделяет три препятствия: сложность настройки, задержку на пути запроса и слабые стимулы провайдеров. Третье Vercel адресует через Marketplace. К 30 ноября 2026 года компания планирует помечать “Not secure” страницы провайдеров, не поддерживающих OIDC-аутентификацию из Vercel и продолжающих использовать долговечные секреты. Провайдеров без безопасной аутентификации обещают удалить к январю 2027 года.
Это объявленные будущие требования собственной экосистемы, а не уже завершенное применение или универсальный правовой стандарт. Точный январский день и время в статье отсутствуют. Vercel говорит о той же планке для своего API и нативных интеграций; автоматическая настройка при подключении сервисов остается работой в процессе. Следует проверять фактическую поддержку интеграции, а не предполагать, что любое подключение Marketplace уже настроило федерацию.
6. Миграция должна проверять разрешения, а не только выдачу
Представим учебный пример агента, читающего лишь задачи одного пользователя в Linear. Мы предлагаем составить перечень постоянных ключей и сопоставить каждому сервису развертывание, пользователя и необходимые права. После настройки доверия и подключения аккаунта проверьте успешное разрешенное чтение и отказ для другого проекта, окружения, audience или запрещенной операции. Это предлагаемая методика, не испытание AISubHub и не дополнительное обещание Vercel.
До удаления старого ключа проверьте истечение, обновление, кэш и ошибки обмена, предусмотрев явный план восстановления. Успешное получение токена может скрывать чрезмерные права или ненадежное обновление. Полезный сдвиг — ограниченные возобновляемые полномочия с наблюдаемыми границами. Он не избавляет агента от учетных данных, не решает инъекции инструкций и не гарантирует принятия протокола всеми последующими провайдерами.
Почему это важно
Наш анализ: удостоверение развертывания может уменьшить распространение постоянных ключей, но получатель должен поддерживать и ограничивать такую идентичность. Стимулы Marketplace могут расширить поддержку; настройка и авторизация пользователя остаются необходимыми.
Ограничения и доступность
Анализ официальной статьи и иллюстрации настройки, без независимого аудита безопасности или теста производительности. Методика опроса раскрыта неполно, будущие сроки не означают завершенное исполнение. Аккаунты, интеграции и производственные настройки не изменялись.
Источники и подтверждения
Дата источника: · Источник проверен:
Материалы подготовлены с помощью ИИ и сверены с указанными первоисточниками. Заявления поставщиков атрибутированы; публикация не означает рекомендацию.