Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Incydent powiązany z Vercel z kwietnia 2026 roku pokazuje, że Shadow AI staje się jednym z najważniejszych wyzwań dla bezpieczeństwa przedsiębiorstw. Termin ten odnosi się do nieautoryzowanych, słabo zweryfikowanych lub wdrażanych poza kontrolą działu bezpieczeństwa narzędzi AI, które pracownicy samodzielnie łączą z firmowymi kontami, aplikacjami i danymi.
W praktyce takie rozwiązania tworzą nowy, nieformalny element łańcucha dostaw. Z pozoru niewinna integracja przez przeglądarkę, rozszerzenie lub mechanizm OAuth może otworzyć zewnętrznej usłudze szeroki dostęp do zasobów organizacji, a po kompromitacji dostawcy stać się bezpośrednim kanałem ataku.
W skrócie
W analizowanym przypadku źródłem incydentu nie była luka zero-day ani klasyczna błędna konfiguracja chmury. Kluczowym problemem okazało się zaufanie przyznane zewnętrznemu narzędziu AI, używanemu z wykorzystaniem firmowej tożsamości użytkownika.
Po kompromitacji dostawcy napastnicy przejęli tokeny oraz aktywne sesje, a następnie wykorzystali delegowane uprawnienia OAuth do wejścia do środowiska organizacji. Efektem było rozpoznanie zasobów, dostęp do wybranych zmiennych środowiskowych klientów oraz działania noszące znamiona wymuszenia.
Kontekst / historia
Przypadek ten dobrze wpisuje się w ewolucję od klasycznego Shadow IT do Shadow AI. Wcześniej problem dotyczył głównie niezatwierdzonych aplikacji SaaS i usług chmurowych używanych bez wiedzy zespołów bezpieczeństwa. Dziś podobną rolę odgrywają asystenci AI, narzędzia do generowania kodu, rozszerzenia przeglądarkowe, systemy do podsumowywania spotkań czy automatyzacji pracy z dokumentami.
Różnica polega na skali i charakterze dostępu. Narzędzia AI często wymagają szerokich zgód do poczty, plików, komunikatorów, repozytoriów kodu i API. Jeśli użytkownik zaakceptuje taki zestaw uprawnień, zewnętrzna aplikacja uzyskuje trwały i trudny do zauważenia kanał dostępu do firmowego środowiska.
To sprawia, że zagrożenie nie dotyczy wyłącznie samej aplikacji, ale całej relacji zaufania pomiędzy użytkownikiem, dostawcą usługi a infrastrukturą przedsiębiorstwa. Właśnie ta relacja staje się dziś celem ataków.
Analiza techniczna
Według opisu incydentu łańcuch ataku rozpoczął się po stronie zewnętrznego dostawcy narzędzia AI. Na jednym z endpointów uruchomiono złośliwe skrypty zawierające infostealera, który przechwytywał poświadczenia, cookies przeglądarki oraz zapisane tokeny OAuth. Z perspektywy atakującego są to dane o wyjątkowo wysokiej wartości, ponieważ reprezentują już aktywną, uwierzytelnioną sesję.
W nowoczesnych środowiskach chmurowych token OAuth działa jak poświadczenie okaziciela. Oznacza to, że osoba, która wejdzie w jego posiadanie, może wykonywać operacje API w zakresie przyznanych uprawnień bez konieczności ponownego logowania. W praktyce ogranicza to skuteczność tradycyjnych zabezpieczeń, takich jak MFA, jeżeli sesja została wcześniej poprawnie ustanowiona.
Istotne jest również to, że celem nie była formalnie wdrożona aplikacja korporacyjna, lecz konsumenckie narzędzie AI testowane przez pracownika przy użyciu służbowego konta. W ten sposób powstał niezarządzany most tożsamościowy między środowiskiem firmy a zewnętrzną usługą. Po przejęciu tokena napastnicy mogli działać w granicach uprawnień przypisanych do tożsamości użytkownika.
Dalszy etap obejmował rekonesans i ruch boczny. Jeżeli konto należało do uprzywilejowanego dewelopera, uzyskany dostęp mógł prowadzić do paneli administracyjnych, zasobów powiązanych z SSO oraz systemów chmurowych. Zgodnie z analizą nie potwierdzono kompromitacji głównych repozytoriów kodu, jednak incydent objął wybrane zmienne środowiskowe klientów, które nie były oznaczone jako szczególnie wrażliwe. Dane te posłużyły następnie jako element presji w działaniach wymuszających.
Z perspektywy obrony warto zauważyć, że taki scenariusz łączy kilka klas technik: przejęcie sesji, wykorzystanie zaufanej relacji, użycie prawidłowych kont chmurowych, rozpoznanie infrastruktury oraz eksfiltrację danych połączoną z próbą wywarcia presji na ofierze.
Konsekwencje / ryzyko
Najważniejszy wniosek jest prosty: granica bezpieczeństwa przesuwa się z sieci i endpointów w stronę tożsamości, sesji oraz zgód aplikacyjnych. Organizacja może mieć wdrożone MFA, EDR i segmentację, a mimo to pozostawać podatna na obejście zabezpieczeń, jeśli nie kontroluje, jakie aplikacje otrzymują dostęp do firmowych kont.
Ryzyko operacyjne obejmuje kilka wymiarów:
- niezatwierdzone narzędzia AI mogą uzyskiwać nadmierne zakresy uprawnień,
- kompromitacja zewnętrznego dostawcy automatycznie rozszerza powierzchnię ataku na jego klientów i użytkowników,
- konta deweloperskie oraz administracyjne są szczególnie atrakcyjnym celem ze względu na szeroki dostęp do konfiguracji i danych,
- organizacje często mają ograniczoną widoczność aktywnych aplikacji OAuth, rozszerzeń i narzędzi używanych poza oficjalnym procesem zakupowym.
Dodatkowym problemem jest szybkość adopcji takich usług. Użytkownik może w ciągu kilku minut zainstalować rozszerzenie, zalogować się służbowym kontem i przyznać szerokie zgody aplikacji spoza zatwierdzonego ekosystemu. Jeśli monitoring działa wyłącznie okresowo, zagrożenie może zostać wykryte dopiero po incydencie.
Rekomendacje
Przedsiębiorstwa powinny traktować Shadow AI jako osobną kategorię ryzyka, łączącą bezpieczeństwo tożsamości, ochronę SaaS, kontrolę przeglądarki i zarządzanie dostępem do danych. Podstawą jest pełna inwentaryzacja aplikacji korzystających z OAuth, aktywnych sesji oraz integracji używanych z kontami służbowymi.
W praktyce warto wdrożyć następujące działania:
- ograniczyć możliwość logowania do niezatwierdzonych aplikacji przy użyciu firmowych kont,
- egzekwować polityki zgód OAuth oraz zasadę minimalnych uprawnień,
- monitorować instalacje rozszerzeń przeglądarkowych i użycie narzędzi AI przez pracowników,
- segmentować i ograniczać uprawnienia kont deweloperskich oraz administracyjnych,
- regularnie przeglądać i unieważniać aktywne tokeny, sesje oraz połączone aplikacje,
- klasyfikować i chronić dane konfiguracyjne, w tym zmienne środowiskowe i sekrety,
- włączyć wykrywanie kradzieży cookies, tokenów i sesji do procedur reagowania na incydenty,
- oceniać ryzyko dostawców narzędzi AI, nawet jeśli nie należą do oficjalnie zatwierdzonego stosu technologicznego.
Szczególnie ważne jest przesunięcie kontroli na moment nadawania zgód. Zamiast wykrywać problem po fakcie, organizacja powinna blokować lub warunkować integracje w czasie rzeczywistym. Dotyczy to zarówno dostawcy tożsamości, jak i mechanizmów ochrony przeglądarki, które potrafią wykrywać użycie niezweryfikowanych usług AI z firmową tożsamością.
Podsumowanie
Incydent związany z Vercel pokazuje, że nowoczesne naruszenia łańcucha dostaw coraz częściej nie zaczynają się od exploita, lecz od niekontrolowanej relacji zaufania ustanowionej przez użytkownika. Shadow AI staje się realnym wektorem ataku, ponieważ łączy wygodę pracy, szerokie uprawnienia i niską widoczność po stronie organizacji.
Największym zagrożeniem nie jest samo wykorzystanie sztucznej inteligencji, ale brak nadzoru nad tym, jakie aplikacje uzyskują dostęp do firmowej tożsamości, danych i interfejsów API. Skuteczna obrona wymaga więc kontroli zgód OAuth, nadzoru nad integracjami przeglądarkowymi oraz bieżącego monitorowania nieformalnego ekosystemu narzędzi AI.