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

Niniejszy dokument jest automatycznym tłumaczeniem oryginału w języku angielskim. W przypadku jakichkolwiek rozbieżności między tym tłumaczeniem a oryginalną wersją angielską, wersja angielska jest rozstrzygająca. Przeczytaj oryginał w języku angielskim

Nie pośrodku: dlaczego wyciek w stylu Context AI przeciwko Caiioo nie przyniósłby nic użytecznego

2026-04-22 · Caiioo Team

19 kwietnia 2026 r. firma Vercel ujawniła, że narzędzie AI zewnętrznego dostawcy używane przez jednego pracownika zostało zhakowane, a przejęty token OAuth posłużył do infiltracji wewnętrznych środowisk Vercel. U ograniczonej grupy klientów doszło do ujawnienia niewrażliwych zmiennych środowiskowych. Szyfrowane/wrażliwe zmienne środowiskowe pozostały bezpieczne.

Narzędziem tym było Context AI. Pracownik przyznał mu szeroki dostęp „Zezwalaj na wszystko” do swojego korporacyjnego Google Workspace. To pojedyncze uprawnienie OAuth, przechowywane na serwerach Context AI, stało się punktem nacisku dla wszystkich kolejnych zdarzeń.

Cyberprzestępca na forum BreachForums wystawił na sprzedaż rzekome dane 580 pracowników Vercel za 2 mln USD. Vercel nie potwierdził autentyczności tego ogłoszenia.

Incydent wciąż trwa. Jednak lekcja dotycząca architektury jest już jasna i przydatna dla każdego, kto ocenia przestrzeń roboczą AI.

Przebieg ataku

Model SaaS-AI stawia dostawcę pośrodku każdego uprawnienia OAuth, którego mu udzielasz.

Kiedy instalujesz zewnętrzne narzędzie AI i przechodzisz przez ekran zgody OAuth, token dostępu i token odświeżania wydane przez Google (lub Microsoft, lub dowolnego dostawcę tożsamości) nie zostają na Twoim urządzeniu. Są one przesyłane na serwery dostawcy, ponieważ AI, która ich potrzebuje, działa w chmurze dostawcy. Infrastruktura dostawcy przechowuje stale odświeżany zestaw tokenów dla każdego użytkownika, z uprawnieniami „Zezwalaj na wszystko”, które większość osób akceptuje bez czytania.

Ten scentralizowany magazyn tokenów jest precyzyjnym celem atakujących. Jedno włamanie do dostawcy daje dostęp do Workspace tysięcy klientów. Biuletyn Vercel ostrzega, że skutki mogą dotknąć „setek użytkowników w wielu organizacjach”.

Raporty wskazują, że pierwotny łańcuch zdarzeń zaczął się od pracownika Context AI, którego prywatne urządzenie zostało zainfekowane w lutym 2026 r., rzekomo przez pobrany exploit do gry Roblox zawierający malware Lumma Stealer. Złośliwe oprogramowanie wykradło dane uwierzytelniające Google Workspace i AWS pracownika, co z kolei otworzyło skarbiec tokenów OAuth. Jedno zainfekowane urządzenie prywatne, jeden korporacyjny skarbiec SaaS, setki poszkodowanych Workspace'ów.

Trzy powody architektoniczne, dla których naruszenie bezpieczeństwa w stylu Context AI przeciwko Caiioo nie przyniosłoby nic użytecznego

Caiioo to potężne, stawiające na prywatność środowisko pracy z agentowym orkiestratorem i interfejsem czatu działającym w panelu bocznym. „Privacy-first” opisuje konkretną postawę architektoniczną, a nie hasło marketingowe. W grę wchodzą trzy konkretne właściwości.

1. Tokeny OAuth Twojego Workspace są przechowywane w formie zaszyfrowanej na Twoim urządzeniu, a nie na naszych serwerach

Kiedy łączysz konto Google lub Microsoft w Caiioo, zobaczysz standardowy ekran zgody OAuth Google z zakresami (scopes), których udzielasz. Jak dotąd wygląda to identycznie jak autoryzacja Context AI.

Różnica strukturalna polega na tym, co dzieje się z tokenami wynikającymi z tego procesu zgody. Token dostępu (access token) i token odświeżania (refresh token) wydane przez Google są przechowywane w formie zaszyfrowanej na Twoim urządzeniu — w Keychain na macOS i iOS, w Keystore na Androidzie, w bezpiecznym magazynie przeglądarki w rozszerzeniu. Nie są one przechowywane w centralnej bazie danych Caiioo. Nie posiadamy sejfu na tokeny, który trzymałby je w Twoim imieniu.

Gdy agentowy orkiestrator musi odczytać Twój kalendarz lub przeszukać skrzynkę odbiorczą, wywołanie API trafia z Twojego urządzenia bezpośrednio do Google, z dołączonym tokenem z bezpiecznego magazynu Twojego urządzenia. Nasza infrastruktura nie znajduje się na ścieżce danych dla żadnej zawartości Twojego Workspace.

Możesz to sprawdzić samodzielnie w źródle: src/shared/auth/connections-manager.ts to miejsce, w którym utrwalane są połączenia Google/Microsoft OAuth. Rekordy OAuthConnection, w tym pola accessToken i refreshToken, są zapisywane przez lokalny adapter pamięci masowej — nie są przesyłane do centralnego magazynu tokenów.

2. Szyna komunikatów przekaźnika (relay) jest szyfrowana end-to-end

Kiedy komponenty Caiioo na różnych urządzeniach muszą się koordynować — Twoje rozszerzenie przeglądarki komunikujące się z aplikacją desktopową, Twój telefon łączący się z serwerem domowym, interfejs panelu bocznego wywołujący narzędzie działające natywnie na macOS — robią to za pośrednictwem przekaźnika, który hostujemy pod adresem relay.pebbleflow.ai. Przekaźnik jest punktem spotkań, który pozwala Twoim urządzeniom odnaleźć się nawzajem w różnych sieciach.

Ten przekaźnik jest szyfrowany end-to-end. Urządzenia każdego użytkownika dokonują wymiany kluczy poprzez kopertę przekaźnika i od tego momentu wiadomości między Twoimi urządzeniami są tekstem zaszyfrowanym z perspektywy przekaźnika. Przekaźnik może je trasować, ale nie może ich odczytać.

To nie są tylko aspiracje. Durable Object obsługujący połączenia WebSocket, cloud/relay/src/user-relay.ts, jest udokumentowany jako: "Zarządza połączeniami WebSocket dla pojedynczego użytkownika. Obsługuje wiadomości zaszyfrowane E2E (nieczytelne dla przekaźnika) oraz wymianę kluczy." Ścieżki kodu obsługujące typ wiadomości ENCRYPTED są wyraźnie skomentowane: "Zaszyfrowana wiadomość do konkretnego klienta (nie możemy jej odczytać)." Przekaźnik nie jest architektonicznie zdolny do inspekcji treści wiadomości, które przekazuje.

3. Przekaźnik jest jednodzierżawny (single-tenant) dla każdego użytkownika, z założenia

Przekaźnik Caiioo jest zbudowany na Cloudflare Durable Objects. Każdy użytkownik otrzymuje własną instancję UserRelay — oddzielny, izolowany w czasie wykonywania element obliczeniowy i pamięć masową. Nie ma współdzielonej, wielodzierżawnej bazy danych przechowującej stan sesji na żywo każdego użytkownika, ponieważ w ogóle nie istnieje wielodzierżawna baza danych dla tej roli. Przekaźnik każdego użytkownika jest osobnym obiektem.

Ma to znaczenie, ponieważ eliminuje tryb awarii oparty na wspólnym celu. Nawet jeśli atakujący znalazłby sposób na naruszenie Durable Object jednego użytkownika, nie uzyskałby bocznego dostępu do danych żadnego innego użytkownika — nie ma wspólnego magazynu danych, przez który można by się przemieścić. Każdy użytkownik jest, strukturalnie, swoim własnym dzierżawcą.

Co znajduje się, a czego nie ma w naszej centralnej bazie danych

Prowadzimy centralną bazę danych (Cloudflare D1) dla rzeczy, które muszą być scentralizowane. Uczciwość jest tu kluczowa. Baza danych przechowuje:

  • Tożsamość konta: Twój e-mail, zahaszowane hasło (jeśli używasz logowania e-mail/hasło), ID dostawcy zwrócone przez Google/Apple/Microsoft (jeśli używasz przycisku logowania społecznościowego).
  • Stan rozliczeń: Twój identyfikator klienta Stripe, poziom subskrypcji, klucz licencyjny i status subskrypcji.
  • Klucze API użytkownika dla dostawców wnioskowania AI (konkretnie OpenRouter). Są to poświadczenia dostawcy wnioskowania — odrębne od Twoich tokenów OAuth Workspace. Istnieją one dla przepływu zarządzanych kredytów oraz dla użytkowników, którzy chcą przynieść własny klucz OpenRouter do użytku w funkcjach AI caiioo.
  • Listę aktywacji urządzeń w celu egzekwowania licencji.
  • Logi audytowe, przechowywane zgodnie z wymogami dowodowymi SOC 2.
  • Tabelę routingu dla opcjonalnych przychodzących webhooków (WhatsApp, Telegram itp.) — używaną tylko wtedy, gdy skonfigurowałeś te integracje.

Baza danych nie przechowuje:

  • Twoich tokenów OAuth Workspace (Gmail, Kalendarz, Dysk, Microsoft 365). Znajdują się one wyłącznie na Twoim urządzeniu.
  • Treści Twoich rozmów. Orkiestrator agentowy działa w Twoim panelu bocznym; rozmowy żyją w Twoim lokalnym magazynie.
  • Twoich danych Workspace — e-maili, wydarzeń w kalendarzu, plików na Dysku. Są one odczytywane bezpośrednio z Google/Microsoft na Twoje urządzenie, nigdy nie przechodząc przez naszą infrastrukturę.
  • Treści jakichkolwiek wiadomości przepływających przez przekaźnik WebSocket. Przekaźnik widzi wyłącznie szyfrogram.

Naruszenie naszej centralnej bazy danych ujawniłoby tożsamość konta/rozliczeń, logi audytowe i kolumnę kluczy wnioskowania OpenRouter. Nie przyniosłoby tokenów Workspace, treści rozmów ani danych Workspace, ponieważ ich tam po prostu nie ma.

Szczere zastrzeżenia

To jest inny model zagrożeń, a nie magiczna tarcza. Oto kilka uściśleń, o których wolelibyśmy, abyś dowiedział się od nas, a nie odkrył je później.

Wymiana kodu OAuth na krótko przechodzi przez nasz przekaźnik. Google (oraz Microsoft, GitHub, Slack) wymagają przedstawienia client_secret OAuth na etapie wymiany tokenów, a ten sekret nie może być przesyłany w kodzie klienckim. Dlatego nasz bezstanowy przekaźnik dołącza client_secret i przekazuje Twój kod autoryzacyjny do Google w zamian za właściwe tokeny. Tokeny wracają przez przekaźnik i są natychmiast odsyłane do Twojego urządzenia w celu przechowywania. Nie są one utrwalane w naszej infrastrukturze. Jest to ten sam powód, dla którego każda natywna aplikacja zintegrowana z Google, jakiej kiedykolwiek używałeś, posiada komponent serwerowy — jest to ograniczenie Google, a nie wybór projektowy caiioo.

Niestandardowe punkty końcowe pozwalają całkowicie pominąć naszego klienta OAuth. Caiioo obsługuje konfigurację niestandardowych punktów końcowych OAuth, co oznacza, że użytkownik chcący skonfigurować własnego klienta OAuth w Google Cloud Console (lub odpowiedniku Microsoft Entra) może całkowicie uniknąć zakresów OAuth Caiioo oraz etapu wymiany w naszym przekaźniku. Po skonfigurowaniu, przepływ autoryzacji odbywa się między Twoim urządzeniem a Google, a Caiioo nie uczestniczy w żadnym etapie tej pętli. Nie udostępniamy tego jako ustawienia dla przeciętnego konsumenta, ponieważ większość użytkowników go nie potrzebuje, a domyślna architektura i tak trzyma dane Workspace poza naszymi serwerami. Jednak ta opcja istnieje, a jej implementacja będzie znajoma dla każdego, kto wcześniej konfigurował klienta OAuth w Google Cloud Console.

Kompromitacja urządzenia wciąż ma znaczenie. Jeśli Twój laptop zostanie przejęty, Twoje tokeny również zostaną przejęte. Podejście local-first przenosi powierzchnię ataku ze „skarbca dostawcy” na Twój „punkt końcowy”. Jest to mniejsza i łatwiejsza do obrony powierzchnia, ale nie jest ona zerowa.

Logowanie na poziomie „Sign in with Google” jest oddzielone od dostępu do Workspace. Jeśli logujesz się do samego Caiioo za pomocą Google lub Apple, ten przepływ służy wyłącznie identyfikacji i tworzy połączenie Basic ograniczone do Twojego konta. Nie jest to ta sama ścieżka, co opisany powyżej przepływ dostępu do Workspace, i nie przyznaje AI dostępu do Twojej skrzynki odbiorczej ani kalendarza.

Ataki na łańcuch dostaw samego Caiioo są nadal wyobrażalne. Przejęty kanał aktualizacji mógłby teoretycznie dostarczyć kod, który eksfiltruje tokeny z Twojego urządzenia. Łagodzimy to ryzyko poprzez podpisywanie kodu i notaryzację na każdej platformie, na którą dostarczamy oprogramowanie, ale metody łagodzenia skutków różnią się od modelu skarbca dostawcy — podobnie jak ekonomia atakujących.

Jak zweryfikować to samodzielnie

Szczera odpowiedź brzmi: deklaracji prywatności dostawcy na stronie marketingowej nie da się udowodnić sceptykowi. Oto jak możesz potwierdzić nasze twierdzenia, korzystając z własnych narzędzi.

Uruchom monitor sieci podczas korzystania z caiioo. Little Snitch na macOS, GlassWire na Windows lub Wireshark na dowolnym systemie. Korzystaj z Caiioo normalnie przez godzinę. Ruch, który zobaczysz, oraz znaczenie każdego połączenia:

Miejsce docelowe Kiedy Co to oznacza
oauth2.googleapis.com, gmail.googleapis.com, calendar.googleapis.com, www.googleapis.com Zawsze, gdy agent odczytuje dane Workspace Twoje urządzenie komunikuje się bezpośrednio z Google przy użyciu tokena znajdującego się na urządzeniu. Nie uczestniczymy w tej ścieżce.
login.microsoftonline.com, graph.microsoft.com Jeśli połączyłeś Microsoft 365 Ten sam schemat: Twoje urządzenie łączy się z Microsoft.
api.anthropic.com, openrouter.ai, api.openai.com, generativelanguage.googleapis.com, localhost:11434 (Ollama) Gdy wysyłasz wiadomość na czacie lub uruchamiasz narzędzie korzystające z LLM Twoje urządzenie komunikuje się z wybranym przez Ciebie dostawcą AI. Nie uczestniczymy w tej ścieżce.
relay.pebbleflow.ai (HTTPS) Krótko, podczas wstępnej konfiguracji OAuth Workspace oraz podczas okresowego odświeżania tokena Bezstanowa wymiana kodu OAuth. Tokeny przechodzą przez serwer, ale nie są na nim zapisywane.
relay.pebbleflow.ai (HTTPS) Okresowo Walidacja licencji, pobieranie informacji o nowościach (release-notes) / przewodnika użytkownika, dane model-intelligence, sprawdzanie statusu subskrypcji.
relay.pebbleflow.ai (HTTPS) Gdy ładujesz stronę internetową lub sprawdzasz status połączonego konta Standardowy ruch API.
relay.pebbleflow.ai (WebSocket) W sposób ciągły, jeśli masz zainstalowanych wiele komponentów Caiioo (rozszerzenie + aplikacja desktopowa lub mobile + desktop) Mostek funkcjonalny (capability bridge), który pozwala Twoim urządzeniom komunikować się ze sobą. Szyfrowany end-to-end. Widzimy wyłącznie szyfrogram.
relay.pebbleflow.ai/api/messaging/... Tylko jeśli skonfigurowałeś integracje z komunikatorami (przychodzące wiadomości WhatsApp, Telegram, Slack) Routing Webhook dla wiadomości przychodzących.

Czego nie zobaczysz nigdy:

  • Twoich danych Workspace (e-maili, wydarzeń w kalendarzu, plików Drive) przesyłanych do relay.pebbleflow.ai. Te wywołania trafiają z Twojego urządzenia bezpośrednio do *.googleapis.com.
  • Treści Twoich rozmów przesyłanych do relay.pebbleflow.ai. Orkiestrator działa w Twoim panelu bocznym; historia czatu znajduje się w Twojej lokalnej pamięci masowej.
  • Twoich kluczy API dostawców AI przesyłanych do relay.pebbleflow.ai. Znajdują się one na Twoim urządzeniu. (Wyjątek: jeśli korzystasz z przepływu zarządzanych kredytów, używasz subkonta OpenRouter przydzielonego przez serwer, a wywołanie inferencji nadal odbywa się z Twojego urządzenia).

Jeśli kiedykolwiek zauważysz żądanie z Twojego urządzenia do naszej infrastruktury, które nie pasuje do powyższej tabeli, jest to istotne znalezisko. Poinformuj nas o tym, a my to wyjaśnimy lub naprawimy.

Co zrobić, jeśli jesteś klientem Vercel lub Context AI

Opublikowane wytyczne od Vercel, Context AI i społeczności badaczy bezpieczeństwa sprowadzają się do spójnej listy kontrolnej:

  1. Zmień (rotuj) każdy sekret przechowywany jako niezaszyfrowana zmienna środowiskowa Vercel. Szyfrowane/wrażliwe zmienne rzekomo nie zostały naruszone, ale rotacja jest tania.
  2. Przeprowadź audyt uprawnień OAuth osób trzecich w Google Workspace (i Microsoft 365, jeśli dotyczy). Cofnij dostęp wszystkiemu, czego nie rozpoznajesz, i potraktuj każde narzędzie z uprawnieniami „Zezwalaj na wszystko” jako poświadczenie wymagające wymiany.
  3. Zaostrz przyszłe zgody. Wybieraj narzędzia, które proszą o minimalne uprawnienia (least-privilege), i preferuj przestrzenie robocze, których architektura w ogóle nie wymaga przekazywania długoterminowych tokenów.

Trzeci punkt to zmiana strukturalna, którą ten incydent po cichu rekomenduje.

Wypróbuj Caiioo

Jeśli lekcja z incydentu Vercel/Context AI jest taka, że lokalizacja Twoich tokenów OAuth określa promień rażenia w przypadku włamania do dostawcy, odpowiedzią jest wybór obszaru roboczego, który ich nie przechowuje.

Caiioo to potężny, stawiający na prywatność obszar roboczy z orkiestratorem agentowym i interfejsem czatu działającym w panelu bocznym. Dostępny jako rozszerzenie przeglądarki, natywna aplikacja na macOS, iOS, Android oraz aplikacja desktopowa dla Windows i Linux. Zacznij za darmo.

Źródła: