Wprowadzenie do problemu / definicja
Rosnąca popularność agentów AI wspierających tworzenie systemu zmienia sposób pracy zespołów developerskich, ale jednocześnie ujawnia nową klasę ryzyka operacyjnego. Narzędzia tego typu potrafią gwałtownie generować działający kod, jednak tempo wytwarzania nie oznacza automatycznie zgodności z dobrymi praktykami secure by design. Coraz więcej obserwacji wskazuje, iż agenci kodujący często odtwarzają dobrze znane, klasyczne błędy bezpieczeństwa, szczególnie w obszarach uwierzytelniania, autoryzacji i logiki biznesowej.
W skrócie
Badanie przeprowadzone na trzech agentach AI wykazało wysoki odsetek podatności w kodzie generowanym podczas normalnego procesu wytwarzania aplikacji. W ramach 38 skanów obejmujących 30 pull requestów wykryto 143 problemy bezpieczeństwa, a 26 z 30 PR-ów zawierało co najmniej jedną lukę.
Najczęściej powtarzały się błędy kontroli dostępu, nieprawidłowe wdrożenia OAuth, brak ochrony WebSocketów, słabe zarządzanie sekretami JWT oraz brak skutecznego rate limitingu. Wniosek jest jednoznaczny: kod wygenerowany przez AI wymaga pełnoprawnej weryfikacji bezpieczeństwa, tak samo jak kod pisany manualnie.
Kontekst / historia
Badanie objęło trzy popularne klasy agentów AI wykorzystywanych do programowania: rozwiązania od Anthropic, OpenAI oraz Google. Każdy z nich otrzymał zadanie stworzenia od podstaw dwóch realistycznych aplikacji, bez sztucznie uproszczonych scenariuszy testowych i bez dodatkowych wskazówek bezpieczeństwa w promptach.
Pierwsza aplikacja była webową platformą do zarządzania informacjami o alergiach dzieci i kontaktach rodzinnych. Druga stanowiła przeglądarkową grę wyścigową z backendowym API, rankingiem wyników oraz funkcjami multiplayer. Taki dobór przypadków użycia odzwierciedlał typowe środowiska produkcyjne, w których pojawiają się zarówno mechanizmy kont użytkowników, jak i złożona logika aplikacyjna.
Proces tworzenia przebiegał iteracyjnie, z wykorzystaniem pull requestów, które były skanowane na bieżąco. Dodatkowo wykonywano skan bazowy przed rozpoczęciem developmentu oraz końcowy przegląd całego kodu po scaleniu wszystkich zmian. Dzięki temu możliwe było prześledzenie nie tylko końcowego stanu aplikacji, ale również momentu, w którym podatności były wprowadzane i utrwalane.
Analiza techniczna
Najbardziej powtarzalną klasą problemów okazało się broken access control. W praktyce oznaczało to obecność endpointów umożliwiających wykonywanie wrażliwych lub destrukcyjnych operacji bez odpowiedniego uwierzytelnienia albo autoryzacji. Tego rodzaju błędy należą do najgroźniejszych, ponieważ umożliwiają bezpośrednie nadużycia funkcji aplikacji przez nieuprawnionych użytkowników.
Drugim silnym wzorcem były błędy logiki biznesowej. W aplikacji growej agenci akceptowali od klienta takie dane jak wynik, saldo czy stan odblokowanych elementów bez wystarczającej walidacji po stronie serwera. To klasyczny przykład nadmiernego zaufania do danych wejściowych z frontendu, który prowadzi do manipulacji stanem gry, oszustw oraz eskalacji uprawnień w modelu biznesowym aplikacji.
W obszarze OAuth odnotowano powtarzalne braki związane z parametrem state oraz z niebezpiecznym łączeniem kont. Takie problemy mogą skutkować atakami typu CSRF w procesie logowania federacyjnego lub przejęciem powiązań między tożsamościami użytkownika. Istotne jest to, iż błędy nie wynikały z pojedynczej implementacji, ale pojawiały się w pracach wszystkich badanych agentów.
Kolejny problem dotyczył WebSocketów. Agenci poprawnie implementowali middleware uwierzytelniające dla REST API, ale nie podłączali analogicznej ochrony do procesu upgrade połączenia WebSocket. W efekcie część komunikacji czasu rzeczywistego pozostawała poza egzekwowaniem polityki dostępu. To szczególnie niebezpieczne w aplikacjach multiplayer, czatach, panelach operacyjnych i systemach telemetrycznych.
Badanie wykazało także systematyczne problemy z rate limitingiem. Middleware ograniczające liczbę żądań bywało obecne w kodzie, ale nie było faktycznie aktywowane w aplikacji. Taki błąd jest podstępny, ponieważ przy pobieżnym przeglądzie kodu można odnieść wrażenie, iż zabezpieczenie istnieje, mimo iż nie działa w ścieżce wykonywania programu.
W wielu przypadkach wykryto również słabe zarządzanie sekretami JWT, w tym twardo zakodowane wartości zapasowe. jeżeli napastnik jest w stanie przewidzieć lub poznać taki sekret, może generować poprawne tokeny i obchodzić mechanizmy uwierzytelniania. W praktyce jest to błąd krytyczny, ponieważ podważa zaufanie do całego modelu sesji.
Szczególnie istotny jest wniosek dotyczący narzędzi detekcji. Znaczna część błędów miała charakter kontekstowy i logiczny, a nie składniowy. Oznacza to, iż klasyczne mechanizmy SAST oparte głównie na sygnaturach, regexach i znanych antywzorcach mogą nie wykrywać najważniejszych podatności generowanych przez agentów AI.
Konsekwencje / ryzyko
Z perspektywy bezpieczeństwa organizacji najważniejsze ryzyko polega na fałszywym poczuciu pewności. Kod wygenerowany przez AI często działa funkcjonalnie, przechodzi podstawowe testy i bywa akceptowany szybciej z uwagi na wysokie tempo dostarczania zmian. To jednak nie oznacza, iż spełnia wymagania bezpieczeństwa produkcyjnego.
W praktyce opisane podatności mogą prowadzić do nieautoryzowanego dostępu do danych, przejęcia kont, obchodzenia mechanizmów MFA, manipulacji stanem aplikacji, nadużyć API, ataków brute force oraz eskalacji wpływu pojedynczego błędu na cały system. Szczególnie niebezpieczne są luki obecne od wczesnych pull requestów, które następnie pozostają nierozwiązane do końca projektu.
Dla zespołów DevSecOps oznacza to także wzrost presji na proces przeglądu zmian. jeżeli agent AI generuje większą liczbę commitów i PR-ów, organizacja może szybciej akumulować dług bezpieczeństwa niż w klasycznym cyklu developmentu. Im większa automatyzacja kodowania, tym większa musi być automatyzacja i dojrzałość kontroli bezpieczeństwa.
Rekomendacje
Organizacje korzystające z agentów AI do programowania powinny traktować każdy wygenerowany fragment kodu jako nieufny do momentu przejścia pełnej walidacji bezpieczeństwa. Skanowanie wyłącznie końcowego buildu jest niewystarczające; analiza powinna obejmować każdy pull request, aby wychwytywać ryzyko na etapie wprowadzania zmian.
Konieczne jest również włączenie wymagań bezpieczeństwa już do etapu planowania funkcji. o ile agent otrzymuje jedynie specyfikację biznesową, najczęściej zoptymalizuje rozwiązanie pod kątem działania, a nie ochrony. Dlatego prompt engineering i wymagania produktowe powinny zawierać jawne oczekiwania dotyczące autoryzacji, walidacji serwerowej, obsługi sesji, ochrony przed nadużyciami oraz bezpiecznego zarządzania sekretami.
- obowiązkowe przeglądy PR-ów z perspektywy bezpieczeństwa,
- analizę kontekstową kodu uwzględniającą przepływ danych i granice zaufania,
- testy kontroli dostępu dla wszystkich endpointu i kanału komunikacji, w tym WebSocket,
- walidację po stronie serwera dla wszystkich decyzji biznesowych,
- centralne zarządzanie sekretami bez fallbacków w kodzie,
- obowiązkowy rate limiting i ochronę przed brute force dla interfejsów logowania oraz API,
- testy regresji bezpieczeństwa dla OAuth, JWT, sesji i mechanizmów odświeżania tokenów.
Dobrym podejściem jest również stworzenie listy kontrolnej najczęściej powtarzających się błędów agentów AI. Powinny się na niej znaleźć: nieautoryzowane endpointy, brak state w OAuth, brak egzekwowania autoryzacji dla WebSocketów, zaufanie do danych klienta, niewłączony rate limiting, nieodwoływalne refresh tokeny oraz słabe sekrety JWT.
Podsumowanie
Agenci AI do programowania przyspieszają development, ale nie eliminują podstawowych problemów bezpieczeństwa aplikacji. Wręcz przeciwnie, obserwacje pokazują, iż potrafią systematycznie odtwarzać znane od lat wzorce podatności, szczególnie tam, gdzie wymagane jest rozumienie kontekstu biznesowego i granic zaufania.
Dla organizacji oznacza to konieczność dostosowania procesów AppSec i DevSecOps do realiów kodu generowanego maszynowo. Skuteczność agentów AI należy oceniać nie tylko przez pryzmat szybkości dostarczania funkcji, ale również przez poziom ryzyka, jaki wnoszą do pipeline’u wytwarzania oprogramowania.
Źródła
- Help Net Security – AI coding agents keep repeating decade-old security mistakes – https://www.helpnetsecurity.com/2026/03/13/claude-code-openai-codex-google-gemini-ai-coding-agent-security/
