Риски AI-интеграций: чему учит инцидент Vercel и Context.ai

По состоянию на 21 апреля 2026 года риски AI-интеграций уже нельзя сводить к вопросу качества ответов модели. Если сторонний ИИ-инструмент получает OAuth-доступ к Google Workspace, почте, документам, репозиториям или платформам разработки, он становится частью цепочки доверия компании.

Свежий кейс Vercel показывает это без теории. В отдельном материале мы уже разобрали сам инцидент Vercel и Context.ai. Здесь фокус другой: что должны проверить CTO, администраторы Workspace и команды разработки, чтобы новый AI SaaS не стал тихим входом во внутренний контур.

Кейс Vercel: где сломалась цепочка доверия

В официальном бюллетене Vercel пишет, что инцидент начался с компрометации Context.ai, стороннего ИИ-инструмента, которым пользовался сотрудник компании. По версии Vercel, атакующий использовал этот доступ, чтобы захватить Google Workspace-аккаунт сотрудника, попасть в некоторые окружения Vercel и получить доступ к environment variables, которые не были помечены как sensitive.

Масштаб важно не раздувать. Vercel говорит об ограниченной группе клиентов, чьи не-sensitive переменные окружения могли быть скомпрометированы, и о продолжающемся расследовании. Компания отдельно пишет, что сервисы остаются работоспособными, sensitive environment variables хранятся так, что их нельзя прочитать, а доказательств доступа к таким значениям на момент бюллетеня нет. Также Vercel сообщила, что вместе с GitHub, Microsoft, npm и Socket подтвердила отсутствие компрометации npm-пакетов Vercel.

Для команд разработки главный урок не в названии конкретного сервиса. Слабым местом стала связка: внешний AI SaaS, OAuth-приложение, рабочий аккаунт, внутренние окружения и секреты. Такая связка есть почти в каждой компании, которая подключает ассистентов к почте, календарю, тикетам, логам или коду.

Почему OAuth делает AI-инструмент рискованнее обычного сервиса

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

Документация Google Workspace прямо описывает, что администратор может управлять доступом сторонних и внутренних приложений через OAuth 2.0 scopes. В Admin Console видны configured apps и accessed apps, можно смотреть имя приложения, тип, ID, статус проверки, уровень доступа, число пользователей и запрошенные сервисы вроде Gmail, Calendar или Drive. При этом сведения об accessed apps могут появляться с задержкой 24-48 часов после авторизации.

Исследовательская работа OAuthHub формулирует более общую проблему: многие OAuth-провайдеры дают ограниченный набор довольно грубых прав, поэтому сторонние приложения часто получают больше данных, чем им нужно. Для AI SaaS это особенно чувствительно. Ассистенту легко объяснить, зачем ему доступ к письмам, документам и календарю, но потом эти разрешения становятся постоянной поверхностью атаки.

Что проверить перед подключением AI SaaS

Новый ИИ-сервис в корпоративном контуре стоит проверять как поставщика с доступом к данным, а не как удобную кнопку в браузере. Минимальная предварительная проверка должна отвечать на несколько практических вопросов.

• Кто владелец интеграции внутри компании и кто имеет право её выключить.
• Какой OAuth client ID у приложения и какие scopes оно запрашивает.
• Какие классы данных видит инструмент: почта, файлы, календарь, репозитории, логи, production-панели.
• Сколько пользователей подключили приложение и нужны ли эти права всем или только одной роли.
• Как быстро можно отозвать токены, заблокировать приложение и проверить журналы после инцидента.
• Есть ли у поставщика понятные условия по хранению данных, обучению моделей и доступу сотрудников к пользовательскому контенту.

Для Google Workspace есть отдельный слой контроля: OAuth Token Audit Activity Events. Их можно получать через Reports API с applicationName=token. В событиях есть authorize, activity, request, revoke, а среди параметров указаны app_name, client_id и scope. Это даёт администраторам не только список приложений, но и историю того, кто и когда выдал доступ.

Как настроить least privilege для AI-интеграций

Least privilege для AI SaaS начинается с запрета на автоматическое доверие. В Google Workspace администратор может управлять доступом в разделе Security, Access and data control, API controls. Для приложений доступны статусы Trusted, Limited и Blocked. Trusted даёт доступ ко всем Workspace services, включая restricted services; Limited ограничивает приложение unrestricted services; Blocked запрещает доступ к Google services.

Google также позволяет ограничивать доступ к конкретным сервисам и high-risk scopes. В документации отдельно перечислены чувствительные Gmail и Drive scopes, включая полный доступ к Gmail, чтение Gmail, отправку писем, полный доступ к Drive и чтение Drive. Практическое правило простое: если AI-инструменту нужен только календарь для планирования встреч, он не должен получать Drive, Gmail и Admin SDK на всякий случай.

С 2024 года Google Workspace даёт более гранулярное управление сторонними приложениями по отдельным API scopes. Администраторы могут ограничить доступ приложения конкретными OAuth scopes, чтобы оно не получило новые права без согласия администратора, даже если попросит их позже. Для AI-инструментов это должно стать стандартной настройкой, а не ручным исключением после инцидента.

Секреты и переменные окружения: отдельная зона риска

Vercel в рекомендациях после инцидента просит пересмотреть и ротировать environment variables, которые не были помечены как sensitive. Компания прямо пишет: если в таких переменных были API keys, tokens, database credentials или signing keys, их нужно считать потенциально раскрытыми и менять в приоритетном порядке. Удаление проекта или аккаунта само по себе не убирает риск, потому что уже скомпрометированные секреты могут продолжать открывать доступ к production-системам.

Это касается не только Vercel. Любая платформа, где AI-инструмент может видеть логи, переменные, деплои, CI/CD-настройки или экспортированные конфиги, должна попадать в карту секретов. Если ассистент помогает разбирать падения production, ему не нужен доступ к значениям токенов. Если он пишет отчёт по инциденту, ему часто достаточно редактированного лога без ключей, cookie и персональных данных.

Какой регламент нужен команде

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

• Разделите инструменты по уровню доступа: публичные данные, внутренняя документация, рабочая почта, репозитории, production-системы.
• Для каждого уровня задайте владельца, срок действия разрешений и обязательный пересмотр доступа.
• Запретите личные AI SaaS для рабочих данных, если они обходят корпоративные журналы и политику хранения.
• Добавьте OAuth client ID, scopes, владельца и дату ревью в реестр SaaS-интеграций.
• Проводите квартальный аудит accessed apps и отдельно проверяйте новые приложения с Gmail, Drive, Calendar, Admin SDK и GitHub-доступом.
• Заранее опишите сценарий аварийного отключения: кто блокирует приложение, кто отзывает токены, кто ротирует секреты, кто пишет пользователям.

Похожая логика нужна и в dev-контуре. В материале про то, как ИИ-агенты атакуют разработчиков через тестовые задания, мы разбирали другой вход: чужой репозиторий, IDE и автозапуск задач. А в заметке про GitHub Copilot и проверку opt-out речь шла о данных, которые уходят в AI-инструмент во время работы. Во всех трёх случаях проблема одна: удобный ассистент пересекает границу доверия быстрее, чем компания успевает описать правила.

Главный вывод

Риски AI-интеграций не означают, что каждый сторонний ассистент опасен. Они означают, что AI SaaS с OAuth-доступом должен проходить тот же контроль, что CI/CD-инструмент, менеджер секретов или сервис мониторинга. У него есть владелец, разрешения, журналы, срок жизни токенов и процедура отключения.

Кейс Vercel и Context.ai полезен именно как ранний сигнал. Команды привыкли проверять пакеты, контейнеры, GitHub Actions и npm-зависимости. Теперь в ту же карту риска нужно добавить AI-инструменты, которые читают корпоративные данные и действуют от имени сотрудников. Самая практичная мера на сегодня: выгрузить список OAuth-приложений, найти AI SaaS с широкими scopes, ограничить доступ до нужного минимума и заранее подготовить сценарий отзыва прав.

Источники и проверка фактов

• Vercel: April 2026 security incident, проверено 21 апреля 2026 года.
• Vercel Docs: Sensitive environment variables, проверено 21 апреля 2026 года.
• Google Workspace: OAuth Token Audit Activity Events, проверено 21 апреля 2026 года.
• Google Workspace Admin Help: Control which third-party and internal apps access Google Workspace data, проверено 21 апреля 2026 года.
• Google Workspace Updates: configure third-party apps by selected API scopes, проверено 21 апреля 2026 года.
• OAuthHub: Mitigating OAuth Data Overaccess through a Local Data Hub, проверено 21 апреля 2026 года.