Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Shadow AI przestaje oznaczać wyłącznie nieautoryzowane korzystanie z chatbotów i narzędzi generatywnych przez pracowników. Coraz częściej chodzi o samodzielne tworzenie aplikacji biznesowych z użyciem platform low-code oraz środowisk AI-assisted development, a następnie ich publikowanie bez udziału działów IT i bezpieczeństwa. W efekcie ryzyko przenosi się z poziomu pojedynczego zapytania do modelu na poziom gotowego produktu, który może mieć dostęp do danych firmowych, operacyjnych i osobowych.
To istotna zmiana z perspektywy cyberbezpieczeństwa, ponieważ nowe aplikacje mogą być podłączane do systemów produkcyjnych, korzystać z interfejsów API i działać pod publicznymi adresami URL. Jeśli powstają poza standardowym nadzorem, organizacja często dowiaduje się o ich istnieniu dopiero wtedy, gdy dojdzie do ekspozycji danych lub błędnej konfiguracji.
W skrócie
Opisane badanie wskazuje, że w ekosystemie narzędzi do szybkiego tworzenia aplikacji z użyciem AI zidentyfikowano ponad 380 tys. publicznie dostępnych zasobów webowych. Około 5 tys. z nich miało wyglądać na powiązane z organizacjami, a ponad 2 tys. mogło zawierać wrażliwe dane albo zapewniać zbyt szeroki dostęp, w tym administracyjny, bez odpowiednich mechanizmów ochronnych.
- problem dotyczy wielu branż i regionów,
- ryzyko wynika nie tylko z AI, ale także z błędnej publikacji aplikacji,
- klasyczne narzędzia bezpieczeństwa nie zawsze widzą pełny łańcuch tworzenia i wdrożenia,
- największym zagrożeniem są publiczna ekspozycja, nadmierne uprawnienia i brak audytu.
Kontekst / historia
Przez lata firmy walczyły przede wszystkim ze zjawiskiem Shadow IT, czyli używaniem niezatwierdzonych usług, kont i aplikacji poza centralnym nadzorem. Choć taki model był problematyczny, zwykle pozostawiał przynajmniej część punktów kontrolnych, takich jak logi dostawcy, integracja z systemem tożsamości czy formalne relacje z usługodawcą.
Nowa fala narzędzi AI istotnie obniżyła jednak próg wejścia w budowę oprogramowania. Dziś pracownik biznesowy może samodzielnie przygotować dashboard, formularz obiegowy, panel raportowy lub prostą aplikację integrującą dane z CRM, ERP albo systemów BI. Tego typu rozwiązania powstają szybciej, niż organizacja jest w stanie je zinwentaryzować, sklasyfikować i objąć politykami bezpieczeństwa.
To właśnie odróżnia współczesne Shadow AI od wcześniejszego modelu Shadow IT. Nie chodzi już tylko o korzystanie z obcej usługi, ale o tworzenie własnych aplikacji, które operują na rzeczywistych danych przedsiębiorstwa i mogą zostać wystawione do internetu z nieprawidłową konfiguracją.
Analiza techniczna
Kluczowy problem techniczny nie wynika wyłącznie z użycia AI, lecz z faktu, że niemal cały proces powstawania aplikacji może odbywać się w ramach jednej sesji przeglądarkowej. Użytkownik tworzy aplikację, autoryzuje dostęp do systemów przez OAuth lub API, importuje dane, definiuje logikę działania i publikuje gotowy projekt pod publicznym adresem.
Z punktu widzenia obrony oznacza to istotne luki w widoczności. EDR zazwyczaj obserwuje sam proces przeglądarki, ale nie rozumie kontekstu budowania aplikacji. DLP może wykrywać klasyczne kopiowanie danych do narzędzi AI, jednak nie zawsze zobaczy legalnie wyglądające transfery cloud-to-cloud przez API. CASB potrafi identyfikować znane usługi SaaS, lecz ma ograniczoną skuteczność wobec ogromnej liczby niestandardowych aplikacji tworzonych wewnątrz jednej platformy. Z kolei firewall, SSE czy SASE widzą ruch do domeny platformy, ale nie muszą rozpoznać, że konkretna sesja zakończyła się publikacją aplikacji z dostępem do wrażliwych danych.
Dodatkowym problemem są urządzenia niezarządzane, takie jak prywatne laptopy, sprzęt kontraktorów czy odseparowane instancje przeglądarek. W takim modelu organizacja może nie posiadać telemetrii potrzebnej do wykrycia ryzykownej aktywności. To sprawia, że zagrożenie rodzi się nie w tradycyjnym cyklu wytwarzania oprogramowania, ale w warstwie sesji, integracji i publikacji.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją jest nieautoryzowane ujawnienie danych. Publicznie dostępna aplikacja może eksponować informacje o klientach, dane finansowe, dokumenty operacyjne, informacje pracownicze lub treści handlowe. W wielu przypadkach do naruszenia nie jest potrzebny zaawansowany atak, ponieważ sama błędna konfiguracja otwiera drogę do dostępu.
Drugim ryzykiem jest nadmierny poziom uprawnień. Aplikacje tworzone ad hoc często korzystają z szerokich tokenów OAuth, kluczy API lub połączeń do systemów produkcyjnych bez odpowiedniej segmentacji. Może to umożliwić odczyt, eksport, a czasem także modyfikację danych poza oficjalnymi procesami biznesowymi.
Istotny jest również brak odpowiedzialności i ścieżki audytowej. Takie aplikacje zwykle nie przechodzą secure SDLC, code review, testów bezpieczeństwa ani formalnego procesu zatwierdzenia. W konsekwencji rośnie ryzyko trwałych błędów konfiguracyjnych, niejawnych zależności oraz długotrwałych ekspozycji, które pozostają niezauważone.
Nie można też pominąć ryzyka regulacyjnego. Jeżeli przez tego typu aplikacje przepływają dane osobowe lub informacje objęte wymogami sektorowymi, organizacja może narazić się na naruszenia zgodności, obowiązki notyfikacyjne i szkody reputacyjne.
Rekomendacje
Pierwszym krokiem powinna być szybka inwentaryzacja. Firmy powinny przyjąć, że aplikacje tworzone z użyciem AI już funkcjonują w ich środowisku i wymagają identyfikacji. W praktyce oznacza to połączenie działań organizacyjnych i technicznych, obejmujących zarówno komunikację z pracownikami, jak i analizę połączeń do platform budowy aplikacji.
- zidentyfikować używane platformy AI-assisted development i low-code,
- ustalić, które aplikacje są publicznie dostępne,
- sprawdzić źródła danych, sposób uwierzytelnienia i poziom uprawnień,
- ocenić wykorzystanie tokenów OAuth, sekretów i kluczy API,
- wdrożyć zasadę najmniejszych uprawnień oraz wymuszone uwierzytelnienie,
- regularnie przeglądać internetową ekspozycję zasobów.
Kolejnym elementem powinno być ustanowienie kontrolowanej ścieżki korzystania z takich narzędzi. Zamiast całkowitego zakazu lepiej wyznaczyć zatwierdzone platformy, dopuszczalne klasy danych, wymagania w zakresie MFA, obowiązkowego logowania zdarzeń oraz okresowych przeglądów uprawnień.
Organizacje powinny też zwiększać obserwowalność warstwy sesyjnej i integracyjnej. Szczególnie ważne jest monitorowanie autoryzacji OAuth, tworzenia nowych aplikacji, publikowania publicznych endpointów oraz przepływów danych do usług zewnętrznych. W połączeniu z dobrymi praktykami OWASP i podejściem opartym na NIST CSF 2.0 może to znacząco ograniczyć skalę ryzyka.
Podsumowanie
Rosnąca popularność platform AI do szybkiego budowania aplikacji tworzy nową kategorię zagrożeń na styku Shadow AI, Shadow IT i błędnej konfiguracji usług webowych. Skala publicznie dostępnych aplikacji pokazuje, że tradycyjne stosy bezpieczeństwa nie zawsze obejmują cały proces tworzenia, integracji i publikacji takich rozwiązań.
Dla zespołów bezpieczeństwa najważniejsza zmiana polega na przesunięciu uwagi z samego korzystania z AI na pełny cykl życia aplikacji budowanych przez biznes. To właśnie tam powstają dziś największe luki: w uprawnieniach, ekspozycji, kontroli dostępu i widoczności operacyjnej.
Źródła
- What 2,000 Exposed Vibe-Coded Apps Reveal About the Limits of Most Security Stacks — https://thehackernews.com/2026/05/what-2000-exposed-vibe-coded-apps.html
- The Shadow Builders — https://redaccess.io/shadow-builders/
- OWASP API Security Top 10 — https://owasp.org/API-Security/
- OWASP Top 10 — https://owasp.org/www-project-top-ten/
- NIST Cybersecurity Framework 2.0 — https://www.nist.gov/cyberframework