Not in the middle: why a Context AI–style breach against Caiioo would yield nothing useful

Це машинний переклад оригінального документа англійською мовою. У разі будь-яких розбіжностей між цим перекладом та оригінальною англійською версією, пріоритет має версія англійською мовою. Читати оригінал англійською мовою

Не посередині: чому злам у стилі Context AI проти Caiioo не дав би нічого корисного

2026-04-22 · Caiioo Team

19 квітня 2026 року Vercel повідомила, що сторонній інструмент ШІ одного співробітника було зламано, а скомпрометований токен OAuth використано для проникнення у внутрішні середовища Vercel. У обмеженої частини клієнтів було розкрито нечутливі змінні середовища. Зашифровані/чутливі змінні середовища не постраждали.

Цим інструментом був Context AI. Співробітник надав йому широкий доступ «Дозволити все» до свого корпоративного Google Workspace. Цей єдиний дозвіл OAuth, що зберігався на серверах Context AI, став важелем для всього, що сталося далі.

Зловмисник на BreachForums окремо виставив на продаж дані, які, за його словами, є записами 580 співробітників Vercel, за 2 мільйони доларів. Vercel не підтвердила цей список.

Інцидент ще не вичерпано. Але архітектурний урок уже зрозумілий, і він корисний для кожного, хто оцінює робочий простір зі ШІ.

Структура атаки

Модель SaaS-AI ставить постачальника посередині кожного дозволу OAuth, який ви йому надаєте.

Коли ви встановлюєте сторонній інструмент продуктивності зі ШІ та проходите через екран згоди OAuth, токен доступу та токен оновлення, видані Google (або Microsoft, або будь-яким постачальником ідентифікації), не залишаються на вашому пристрої. Вони передаються на сервери постачальника, оскільки ШІ, якому вони потрібні, працює в хмарі постачальника. Інфраструктура постачальника зберігає набір токенів, що постійно оновлюються, для кожного зі своїх користувачів, обмежених дозволами «Дозволити все», які більшість користувачів натискають не читаючи.

Саме це централізоване сховище токенів є ціллю зловмисників. Один злам постачальника дає доступ до Workspace тисяч клієнтів. Власне повідомлення Vercel попереджає, що наслідки можуть торкнутися «сотень користувачів у багатьох організаціях».

Звіти відстежують початковий ланцюжок до співробітника Context AI, чий особистий пристрій було зламано в лютому 2026 року, як повідомляється, через завантажений експлойт для гри Roblox, який містив шкідливе ПЗ Lumma Stealer. Це ПЗ викрало облікові дані Google Workspace та AWS співробітника, що, своєю чергою, відкрило сховище токенів OAuth. Один заражений особистий пристрій, одне корпоративне сховище SaaS, сотні постраждалих Workspace далі по ланцюжку.

Три архітектурні причини, чому злам у стилі Context AI проти Caiioo не дасть нічого корисного

Caiioo — це потужний робочий простір, орієнтований на приватність, з агентним оркестратором та інтерфейсом чату, що працює в бічній панелі. «Орієнтованість на приватність» описує конкретну архітектурну позицію, а не маркетингове гасло. Тут діють три конкретні властивості.

1. Ваші OAuth-токени Workspace зберігаються зашифрованими на вашому пристрої, а не на наших серверах

Коли ви підключаєте обліковий запис Google або Microsoft у Caiioo, ви бачите стандартний екран згоди OAuth від Google із переліком дозволів (scopes), які ви надаєте. Поки що це виглядає ідентично до авторизації Context AI.

Структурна різниця полягає в тому, що відбувається з токенами, отриманими в результаті цього процесу згоди. Токен доступу (access token) та токен оновлення (refresh token), видані Google, зберігаються зашифрованими на вашому пристрої — у Keychain на macOS та iOS, у Keystore на Android, у захищеному сховищі браузера в розширенні. Вони не зберігаються в центральній базі даних Caiioo. У нас немає сховища токенів, яке б утримувало їх від вашого імені.

Коли агентному оркестратору потрібно прочитати ваш календар або виконати пошук у поштовій скриньці, API-виклик іде з вашого пристрою безпосередньо до Google із доданим токеном із захищеного сховища вашого пристрою. Наша інфраструктура не перебуває на шляху передачі даних для будь-якого вашого контенту Workspace.

Ви можете перевірити це самостійно у вихідному коді: src/shared/auth/connections-manager.ts — це місце, де зберігаються з’єднання Google/Microsoft OAuth. Записи OAuthConnection, включаючи поля accessToken та refreshToken, записуються через адаптер локального сховища — вони не передаються до центрального сховища токенів.

2. Шина повідомлень реле (relay) зашифрована наскрізно (end-to-end)

Коли компоненти Caiioo на різних пристроях потребують координації — ваше розширення браузера спілкується з вашим десктопним додатком, ваш телефон спілкується з вашим домашнім сервером, інтерфейс бічної панелі викликає інструмент, що працює нативно на macOS — вони роблять це через реле, яке ми хостимо за адресою relay.pebbleflow.ai. Реле — це точка зустрічі, яка дозволяє вашим пристроям знаходити один одного в різних мережах.

Це реле зашифроване наскрізно. Пристрої кожного користувача виконують обмін ключами через оболонку реле, і відтоді повідомлення між вашими пристроями є шифротекстом з точки зору реле. Реле може маршрутизувати їх, але не може прочитати.

Це не просто плани. Durable Object, який обробляє WebSocket-з’єднання, cloud/relay/src/user-relay.ts, задокументований як: "Керує WebSocket-з’єднаннями для одного користувача. Обробляє E2E зашифровані повідомлення (непрозорі для реле) та обмін ключами." Шляхи коду, які обробляють тип повідомлення ENCRYPTED, мають явні коментарі: "Зашифроване повідомлення для конкретного клієнта (ми не можемо його прочитати)." Реле архітектурно не здатне перевіряти вміст повідомлень, які воно пересилає.

3. Реле є одноорендним (single-tenant) для кожного користувача за своєю конструкцією

Реле Caiioo побудоване на Cloudflare Durable Objects. Кожен користувач отримує власний екземпляр UserRelay — окрему, ізольовану в середовищі виконання одиницю обчислень та зберігання. Не існує спільної багатоорендної бази даних, що містить стан активних сесій усіх користувачів, тому що для цієї ролі взагалі немає багатоорендної бази даних. Реле кожного користувача — це окремий об’єкт.

Це важливо, оскільки це усуває режим відмови «єдина спільна ціль». Навіть якби зловмисник знайшов спосіб зламати Durable Object одного користувача, він не отримав би побічного доступу до даних будь-якого іншого користувача — немає спільного сховища, через яке можна було б переміститися. Кожен користувач структурно є власним орендарем.

Що є і чого немає в нашій центральній базі даних

Ми використовуємо центральну базу даних (Cloudflare D1) для речей, які мають бути централізованими. Чесність тут важлива. База даних зберігає:

  • Ідентифікація облікового запису: ваша електронна пошта, ваш хешований пароль, якщо ви використовуєте вхід за паролем, ідентифікатор постачальника, повернутий Google/Apple/Microsoft, якщо ви використовуєте кнопки входу через соцмережі.
  • Статус оплати: ваш Stripe customer ID, рівень підписки, ліцензійний ключ та статус підписки.
  • Ключі API для кожного користувача для постачальників ШІ-висновків (зокрема OpenRouter). Це облікові дані постачальника висновків — вони відрізняються від ваших токенів OAuth для Workspace. Вони існують для потоку керованих кредитів та для користувачів, які хочуть принести власний ключ OpenRouter для використання у функціях ШІ caiioo.
  • Список активації пристроїв для контролю ліцензій.
  • Журнали аудиту, що зберігаються для вимог SOC 2.
  • Таблиця маршрутизації для добровільних вхідних вебхуків (WhatsApp, Telegram тощо) — використовується лише якщо ви налаштували ці інтеграції месенджерів.

База даних не зберігає:

  • Ваші токени OAuth для Workspace (Gmail, Календар, Диск, Microsoft 365). Вони знаходяться лише на вашому пристрої.
  • Вміст ваших розмов. Агентний оркестратор працює у вашій бічній панелі; розмови живуть у вашому локальному сховищі.
  • Ваші дані Workspace — електронні листи, події календаря, файли на Диску. Вони зчитуються безпосередньо з Google/Microsoft на ваш пристрій, ніколи не проходячи через нашу інфраструктуру.
  • Вміст будь-якого повідомлення, що проходить через реле WebSocket. Реле бачить лише зашифрований текст.

Злам нашої центральної бази даних розкрив би ідентифікаційні дані облікового запису/оплати, журнали аудиту та колонку ключів OpenRouter. Це не дало б токенів Workspace, вмісту розмов або даних Workspace, оскільки їх там просто немає.

Чесні застереження

Це інша модель загроз, а не магічний щит. Ось кілька нюансів, про які ми хочемо повідомити вам самі, щоб ви не виявили їх пізніше.

Обмін кодом OAuth на короткий час проходить через наш ретранслятор (relay). Google (а також Microsoft, GitHub, Slack) вимагають надання client_secret на етапі обміну токенів, а цей секрет не може бути вшитий у клієнтський код. Тому наш ретранслятор без збереження стану (stateless relay) додає client_secret і пересилає ваш код авторизації до Google в обмін на справжні токени. Токени повертаються через ретранслятор і негайно передаються на ваш пристрій для зберігання. Вони не зберігаються в нашій інфраструктурі. З цієї ж причини кожен нативний додаток з інтеграцією Google, яким ви коли-небудь користувалися, має певний серверний компонент — це обмеження Google, а не вибір дизайну caiioo.

Користувацькі кінцеві точки (custom endpoints) дозволяють повністю обійти наш клієнт OAuth. Caiioo підтримує налаштування власних кінцевих точок OAuth. Це означає, що користувач, готовий створити власний клієнт OAuth у Google Cloud Console (або еквіваленті Microsoft Entra), може взагалі уникнути використання OAuth-дозволів Caiioo та етапу обміну через наш ретранслятор. Після налаштування потік авторизації відбувається між вашим пристроєм і Google, а Caiioo взагалі не бере участі в цьому процесі. Ми не виносимо це як налаштування для звичайних користувачів, оскільки більшості це не потрібно, а стандартна архітектура вже тримає ваші дані Workspace подалі від наших серверів. Але така можливість існує, і процес налаштування буде знайомий кожному, хто раніше створював клієнт OAuth у Google Cloud Console.

Компрометація пристрою все ще має значення. Якщо ваш ноутбук зламано, ваші токени також зламано. Підхід Local-first переносить поверхню атаки зі «сховища розробника» на «вашу кінцеву точку». Це менша поверхня, яку легше захистити, але вона не є нульовою.

Вхід через «Sign in with Google» відокремлений від доступу до Workspace. Якщо ви входите в саму систему Caiioo за допомогою Google або Apple, цей потік призначений лише для ідентифікації та створює базове з'єднання, обмежене вашим обліковим записом. Це не той самий шлях, що й описаний вище потік доступу до Workspace, і він не надає AI доступу до вашої поштової скриньки чи календаря.

Атаки на ланцюжок поставок (supply-chain attacks) самого Caiioo все ще можливі. Скомпрометований канал оновлення теоретично міг би доставити код, який викрадає токени з вашого пристрою. Ми мінімізуємо цей ризик за допомогою підпису коду та нотаріального завірення на кожній платформі, де ми представлені, але цей метод захисту відрізняється від моделі «сховища розробника» — як і економічна вигода для зловмисників.

Як перевірити це самостійно

Чесна відповідь полягає в тому, що заяви постачальника про конфіденційність на маркетинговій сторінці неможливо довести скептику. Тому ось як підтвердити наші заяви за допомогою ваших власних інструментів.

Запустіть мережевий монітор під час використання caiioo. Little Snitch на macOS, GlassWire на Windows або Wireshark на будь-якій системі. Користуйтеся Caiioo у звичайному режимі протягом години. Трафік, який ви побачите, та значення кожного з’єднання:

Призначення Коли Що це означає
oauth2.googleapis.com, gmail.googleapis.com, calendar.googleapis.com, www.googleapis.com Щоразу, коли агент зчитує ваші дані Workspace Ваш пристрій спілкується безпосередньо з Google за допомогою вашого токена на пристрої. Ми не беремо участі в цьому процесі.
login.microsoftonline.com, graph.microsoft.com Якщо ви підключили Microsoft 365 Аналогічна схема: ваш пристрій взаємодіє з Microsoft.
api.anthropic.com, openrouter.ai, api.openai.com, generativelanguage.googleapis.com, localhost:11434 (Ollama) Коли ви надсилаєте повідомлення в чат або запускаєте інструмент, що використовує LLM Ваш пристрій спілкується з тим AI-провайдером, якого ви налаштували. Ми не беремо участі в цьому процесі.
relay.pebbleflow.ai (HTTPS) Короткочасно, під час початкового налаштування Workspace OAuth та під час періодичного оновлення токенів Stateless-обмін кодами OAuth. Токени проходять транзитом і не зберігаються на стороні сервера.
relay.pebbleflow.ai (HTTPS) Періодично Перевірка ліцензії, отримання приміток до випуску / посібника користувача, дані інтелектуальних моделей, перевірка статусу підписки.
relay.pebbleflow.ai (HTTPS) Коли ви завантажуєте вебсайт або переглядаєте статус підключеного облікового запису Стандартний API-трафік.
relay.pebbleflow.ai (WebSocket) Постійно, якщо у вас встановлено кілька компонентів Caiioo (розширення + десктопний додаток або мобільний + десктопний) Міст можливостей, який дозволяє вашим пристроям спілкуватися один з одним. Наскрізне шифрування. Ми бачимо лише шифротекст.
relay.pebbleflow.ai/api/messaging/... Тільки якщо ви налаштували інтеграції з месенджерами (вхідні WhatsApp, Telegram, Slack) Маршрутизація Webhook для вхідних повідомлень.

Що ви не побачите ніколи:

  • Ваші дані Workspace (електронні листи, події календаря, файли Drive), що передаються на relay.pebbleflow.ai. Ці запити йдуть з вашого пристрою безпосередньо на *.googleapis.com.
  • Вміст ваших розмов, що передається на relay.pebbleflow.ai. Оркестратор працює у вашій бічній панелі; історія чату зберігається у вашому локальному сховищі.
  • API-ключі ваших AI-провайдерів, що передаються на relay.pebbleflow.ai. Вони зберігаються на вашому пристрої. (Виняток: якщо ви використовуєте потік керованих кредитів, ви використовуєте субаккаунт OpenRouter, виділений сервером, але виклик інференсу все одно здійснюється з вашого пристрою.)

Якщо ви коли-небудь побачите запит з вашого пристрою до нашої інфраструктури, який не відповідає наведеній вище таблиці, це буде знахідкою. Повідомте нам, і ми пояснимо це або виправимо.

Що робити, якщо ви є клієнтом Vercel або Context AI

Опубліковані рекомендації від Vercel, Context AI та спільноти дослідників безпеки зводяться до послідовного контрольного списку:

  1. Змініть кожен секрет, збережений як незашифрована змінна середовища Vercel. Повідомлялося, що зашифровані/чутливі змінні не постраждали, але ротація коштує недорого.
  2. Проведіть аудит сторонніх дозволів OAuth вашої команди в Google Workspace (і Microsoft 365, якщо актуально). Відкличте все, чого не впізнаєте, і ставтеся до будь-якого інструменту, якому ви надали широкі права «Дозволити все», як до облікових даних, які потрібно замінити.
  3. Посильте майбутні згоди. Надавайте перевагу інструментам, які запитують мінімально необхідні права, і робочим просторам, архітектура яких взагалі не вимагає передачі довгострокових токенів.

Третій пункт — це структурний крок, який цей інцидент наполегливо рекомендує зробити.

Спробуйте Caiioo

Якщо урок інциденту з Vercel/Context AI полягає в тому, що розташування ваших токенів OAuth визначає радіус ураження при зламі постачальника, то відповідь — обрати робочий простір, який їх не зберігає.

Caiioo — це потужний, орієнтований на конфіденційність робочий простір з агентним оркестратором та інтерфейсом чату, який працює в бічній панелі. Доступно як розширення для браузера, нативний додаток для macOS, нативний додаток для iOS, нативний додаток для Android та десктопний додаток для Windows і Linux. Почніть безкоштовно.

Джерела: