Napisz do nas

Kod z AI ma luki. Bezpieczeństwo aplikacji z agentem

AI i Automatyzacje • Łukasz Ślusarski Łukasz Ślusarski • • 16 min czytania
Kod z AI ma luki. Bezpieczeństwo aplikacji z agentem

Kod pisany przez agenta AI wymaga osobnej kontroli bezpieczeństwa, bo modele same jej nie gwarantują. W październiku 2026 Veracode znalazł lukę w 38% testów kodu z 18 modeli. Trzeba pilnować czterech miejsc: sekretów w repozytorium, zależności, dostępu do danych i tego, co agent czyta z repozytorium.

Łukasz Ślusarski, important.is. Stan na 11 listopada 2026. Opracowane na podstawie raportów Veracode (2025 i 2026), GitGuardian (marzec 2026), Wiz (listopad 2025) oraz dokumentacji GitHub, OWASP, Supabase i Claude Code.

Ten tekst jest dla osób, które budują aplikacje z agentami AI, trzymają kod na GitHubie i chcą go potem utrzymywać. Agent pisze szybko, a bezpieczeństwo wychodzi dopiero wtedy, gdy ktoś o nie zapyta. Poniżej zebrałem liczby z raportów pierwotnych, dwie głośne luki we frameworkach i krótką listę rzeczy do włączenia jeszcze dziś. U nas obrazy kontenerów w serwerze komunikatorów są przypięte po sumie sha256 i mają wyłączone uprawnienia (cap_drop: ALL), a opis naszego błędu z portalu klienta jest w sekcji pod koniec tekstu.

Testy, przegląd diffu i CI opisałem osobno w artykule Testy, review i CI dla kodu z AI. Tutaj zajmuję się tym, co może wyciec, wejść do projektu z zewnątrz albo zostać źle zabezpieczone w bazie.

W skrócie: co pilnować w aplikacji pisanej z AI

RyzykoCo pokazują dane pierwotneCo zrobić najpierw
Luki w wygenerowanym kodzieVeracode, 29.10.2026: 38% testów z luką (18 modeli)Przegląd diffu i skaner w CI
Sekrety w repozytoriumGitGuardian, 17.03.2026: 3,2% commitów z Claude Code z wyciekiem, przy 1,5% średniejPush protection, secret scanning, rotacja klucza
Zależności i wymyślone pakietyBadanie USENIX 2025: od 5,2% do 21,7% pakietów nie istniałoSprawdzić pakiet przed instalacją, plik lock, Dependabot
Dostęp do danych w bazieCVE-2025-48757 (Lovable, brak właściwych polityk RLS)RLS na każdej tabeli, klucz tajny tylko na serwerze
Luki we frameworkachCVE-2025-29927 (CVSS 9,1) i CVE-2025-55182 (CVSS 10,0)Aktualizacja po ogłoszeniu CVE, autoryzacja także przy danych
Polecenia ukryte w repozytoriumOWASP LLM01:2025, pośredni prompt injectionUprawnienia z pytaniem o zgodę, obcy kod w izolacji
Pogadajmy

Zrobić to razem?

Wdrażam takie rzeczy w firmach na co dzień. Umów 30 minut, pogadamy konkretnie o Twoim przypadku. Bez prezentacji sprzedażowej.

Umów bezpłatną rozmowę →
Łukasz Ślusarski
Łukasz ŚlusarskiTwórca important.is

Czy kod z AI jest bezpieczny?

Nie z automatu. Veracode od lipca 2025 co jakiś czas sprawdza, jak modele radzą sobie z bezpiecznym kodem. W pierwszym raporcie z 30 lipca 2025 (80 zadań, ponad 100 modeli) kod z luką pojawił się w 45% przypadków. Komunikat z 28 lipca 2026 podał średnią 56% zdanych testów, praktycznie bez zmian rok do roku, a modele zdawały testy składni prawie w 100%. Komunikat z 29 października 2026 pokazał 62% zdanych testów, czyli 38% z luką. To próba 18 modeli i czterech kategorii podatności, więc nie jest to wprost porównanie z 2025 rokiem. Różnice między językami są duże: w tej ostatniej edycji Python zdał 64% testów, C# 60%, JavaScript 57%, a Java tylko 31% (te wyniki językowe nie składają się na średnią 62%, więc źródło jest tu niespójne i traktuj je orientacyjnie). Wniosek jest prosty: poprawnie działający kod z AI nie musi być bezpieczny. Raporty nie porównują go jednak z kodem pisanym ręcznie, więc nie wiemy, o ile jest gorszy albo lepszy.

Poniższy wykres zestawia dane z trzech komunikatów Veracode. Lewa strona pokazuje wyniki według języka, prawa odsetek testów z lukami w kolejnych edycjach.

Wykres Veracode: odsetek testów zdanych według języka w październiku 2026 (Python 64%, C# 60%, JavaScript 57%, Java 31%) i odsetek testów z lukami w 2025 i 2026 (45%, 44%, 38%)

Drugie badanie to BaxBench (arXiv, 17 lutego 2025, wersja z 30 maja 2025). Autorzy dali modelom 392 zadania na backend. Najlepszy model osiągnął 62% poprawności kodu, a na około połowie poprawnych programów każdego modelu udało się wykonać exploit. Uwaga: 62% w BaxBench to poprawność działania najlepszego modelu (o1), a nie odsetek luk, a exploity sprawdzano tylko na programach, które działały.

Jak sekrety trafiają do repozytorium i co z tym zrobić?

Agent kopiuje do kodu to, co widzi, a widzi też pliki z kluczami. GitGuardian w raporcie z 17 marca 2026 policzył 28,65 mln nowych sekretów zapisanych w kodzie w publicznych commitach na GitHubie w 2025 roku, o 34% więcej niż rok wcześniej. Commity wspierane przez Claude Code miały 3,2% wycieków sekretów, przy 1,5% średniej dla wszystkich publicznych commitów. GitGuardian zastrzega, że tego nie należy czytać jako zwykłej wady narzędzia, bo o tym, co trafi do repozytorium, decyduje człowiek. W plikach konfiguracyjnych MCP na publicznym GitHubie znaleziono 24 008 unikalnych sekretów, w tym 2 117 ważnych. Wiz w raporcie z 10 listopada 2025 przejrzał firmy z listy Forbes AI 50 i u 65% znalazł zweryfikowane wycieki, między innymi klucz ElevenLabs w jawnym pliku mcp.json. Próbą było 50 firm z listy Forbes AI 50, a autorzy zgłosili ten wyciek i został szybko naprawiony.

GitHub ma na to trzy mechanizmy. Secret scanning działa w repozytoriach publicznych automatycznie i za darmo, a w prywatnych repozytoriach organizacji wymaga GitHub Secret Protection. Push protection blokuje push z sekretem, zanim trafi do repozytorium. W repozytoriach publicznych ochrona użytkownika jest domyślnie włączona i działa za darmo. W repozytoriach prywatnych push protection na poziomie repozytorium jest domyślnie wyłączona i wymaga GitHub Secret Protection. Blokadę można obejść, podając powód, a GitHub zapisuje to w logu; organizacja może też włączyć delegowane zatwierdzanie obejść (delegated bypass), wtedy decyduje wskazana grupa osób.

Gdy klucz już wyciekł, zasada jest jedna: unieważnij go od razu. Dokumentacja GitHub mówi, że usuwanie sekretu z historii gita jest opcjonalne i często zbędne po unieważnieniu. GitGuardian dodaje powód pośpiechu: w styczniu 2026 ponad 64% sekretów uznanych za ważne w 2022 roku nadal działało. Moja rekomendacja: agentowi dawaj klucze testowe o wąskich uprawnieniach, a prawdziwe trzymaj w zmiennych środowiskowych hostingu albo w menedżerze haseł, nigdy w pliku, który agent może zacommitować.

Wolisz to zlecić? 30 minut, bez zobowiązań. Sprawdzimy czy to ma sens.
Zarezerwuj termin →

Czym jest halucynowany pakiet i jak pilnować zależności?

Halucynowany pakiet to nazwa biblioteki, którą model wymyślił, bo brzmi wiarygodnie. Badanie „We Have a Package for You!” (arXiv, pierwsza wersja z 12 czerwca 2024, trzecia z 2 marca 2025, USENIX Security 2025) sprawdziło 576 000 próbek kodu w dwóch językach. Średnio co najmniej 5,2% pakietów z modeli komercyjnych i 21,7% z modeli otwartych nie istniało, w sumie 205 474 unikalne wymyślone nazwy. Autorzy nazywają zjawisko trwałym i systemowym. Skutek łatwo sobie wyobrazić: jeśli ktoś zarejestruje taką nazwę w rejestrze pakietów i wrzuci tam złośliwy kod, instalacja z polecenia agenta ściągnie go do Twojego projektu. OWASP ma w Top 10:2025 osobną pozycję na ten temat, A03: Software Supply Chain Failures. Badanie pochodzi z lat 2024 i 2025, a nowszych danych o tej skali nie znalazłem, więc traktuj te odsetki jako rząd wielkości, nie aktualny wynik.

Dependabot pomaga, ale w ograniczonym zakresie. Alerty powstają z recenzowanych wpisów w GitHub Advisory Database, więc dotyczą znanych podatności w pakietach, które masz w projekcie. Nowo zarejestrowany, złośliwy pakiet z wymyślonej nazwy takiego wpisu nie ma. Dependabot security updates otwierają pull requesty z poprawką do najniższej wersji, która łata lukę, a version updates utrzymują zależności na bieżąco także bez podatności.

Moja praktyka dla projektów z agentem jest prosta, to opinia, nie wynik badania. Zanim zaakceptujesz nowy pakiet w diffie, otwórz jego stronę w rejestrze i sprawdź wiek, liczbę pobrań i repozytorium. Trzymaj w gicie plik lock, żeby wersje były przypięte. Zmiany w manifeście zależności traktuj w review jak kod, bo to one wpuszczają cudzy kod do projektu.

Czy samo RLS wystarczy do ochrony danych?

Nie. RLS, czyli Row Level Security, to reguły w Postgresie, które decydują, które wiersze tabeli widzi i zmienia dany użytkownik. W Supabase to podstawowa ochrona danych, bo przeglądarka rozmawia z bazą przez API. Dokumentacja Supabase mówi wprost: włącz RLS na każdej tabeli w udostępnionym schemacie, bo tabela bez RLS jest czytelna i zapisywalna dla każdej roli z uprawnieniem do niej. Po włączeniu RLS dane nie są dostępne przez klucz publiczny, dopóki nie dodasz polityk. Klucz tajny omija RLS, więc dokumentacja każe używać go tylko do zadań administracyjnych i nigdy w przeglądarce. W bazie NVD jest wpis CVE-2025-48757 z 30 maja 2025: niewystarczająca polityka RLS w platformie Lovable (według stanu na 15 kwietnia 2025) pozwalała nieuwierzytelnionym osobom czytać i zapisywać dowolne tabele w wygenerowanych stronach. Dostawca ten wpis kwestionuje, wskazując, że za ochronę danych aplikacji odpowiada jej klient.

Samo „włączone RLS” nie jest dowodem ochrony. Polityka, która przepuszcza każdy wiersz, formalnie istnieje, ale niczego nie chroni, a taką łatwo wygenerować, gdy agent chce, żeby zapytanie zadziałało. Dlatego politykę przetestuj na dwóch kontach: użytkownik A nie powinien zobaczyć ani zmienić danych użytkownika B. Kontrola dostępu to zresztą pierwsza pozycja listy OWASP Top 10:2025 (A01: Broken Access Control). Wybór bazy i Supabase omawiam osobno w artykule Backend i baza z AI.

Czy luka we frameworku to problem kodu z AI?

Nie każda luka w aplikacji pochodzi od AI, ale agent nie zauważy jej za Ciebie. CVE-2025-29927 (CVSS 9,1, opublikowana 21 marca 2025) pozwalała obejść sprawdzanie uprawnień w middleware Next.js przez nagłówek x-middleware-subrequest. Według postmortem Vercela dotyczyła aplikacji hostowanych samodzielnie, uruchamianych przez next start i output: 'standalone', a Vercel, Netlify i Cloudflare Workers jej nie dotyczyły. CVE-2025-55182 (CVSS 10,0, 3 grudnia 2025) to zdalne wykonanie kodu bez uwierzytelnienia w React Server Components. Zespół Reacta pisze, że aplikacja może być podatna, nawet jeśli nie ma własnych endpointów Server Function, o ile obsługuje React Server Components, a wśród dotkniętych frameworków wymienia między innymi Next.js. Obie luki naprawiono w nowych wersjach (przy React: 19.0.1, 19.1.2 i 19.2.1, a błąd to według GitHub Advisory deserializacja niezaufanych danych, CWE-502), więc o tym, czy aplikacja jest narażona, decydują wersje pakietów w pliku lock (przy CVE-2025-55182 chodzi o pakiety react-server-dom-* i o wersję Next.js, której łatane numery podaje advisory), a nie to, kto pisał kod.

Oba przypadki mają wpisy w GitHub Advisory Database, z którego korzysta Dependabot, więc włączone alerty pokazałyby je w repozytorium. Z pierwszej luki wyciągam wniosek, który jest moją opinią: nie opieraj autoryzacji wyłącznie na middleware, tylko sprawdzaj uprawnienia także tam, gdzie aplikacja czyta dane. Z drugiej: po ogłoszeniu krytycznego CVE dla frameworka aktualizuj tego samego dnia i zajrzyj do komunikatu autorów, bo lista wersji potrafi się zmieniać. Zależność od hostingu opisuję w artykule Gdzie hostować aplikację z AI.

Czym jest prompt injection w repozytorium i jak się przed nim bronić?

Prompt injection to ukryte polecenie w treści, którą agent czyta, a które zmienia jego zachowanie. OWASP w LLM01:2025 odróżnia wstrzyknięcie bezpośrednie, gdy robi to sam użytkownik, od pośredniego, gdy model przyjmuje dane z zewnętrznych źródeł, takich jak strony i pliki. Repozytorium to właśnie zbiór plików: README, komentarze, pliki konfiguracyjne i zależności. Agent, który je czyta i potrafi uruchamiać polecenia, może dostać instrukcję od autora cudzego kodu. Moim zdaniem o skutkach decydują więc uprawnienia, które agent dostał, a nie to, czy model rozpozna podstęp. Dokumentacja Claude Code zaleca przeglądanie poleceń przed zatwierdzeniem, niewrzucanie nieufnej treści prosto do agenta i uruchamianie skryptów w maszynach wirtualnych, a przy pierwszym uruchomieniu w nieznanym folderze pokazuje okno zaufania. Zastrzega też, że żaden system nie jest odporny na wszystkie ataki. Serwery z pliku .mcp.json mają w Claude Code osobne okno zatwierdzenia. Wśród obron OWASP wymienia między innymi minimalne uprawnienia i zatwierdzanie przez człowieka akcji wysokiego ryzyka.

W praktyce oznacza to kilka nawyków. Obcego repozytorium nie otwieraj agentem ze zgodami na wszystko; najpierw przeczytaj je sam albo uruchom w izolowanym środowisku. Dokumentacja Claude Code wyjaśnia, że samo przejrzenie pliku .mcp.json nie pokazuje wszystkich serwerów, które sesja może załadować. Anthropic nie audytuje bezpieczeństwa serwerów MCP, więc używaj własnych albo od zaufanych dostawców. Pliki z instrukcjami dla agenta to też tekst, który agent wykonuje, dlatego zmiany w nich idą do review jak kod. Jak je pisać, opisuję w artykule AGENTS.md i CLAUDE.md.

Jak ułożyć obronę, żeby jedna luka nie wystarczyła?

Ułóż pięć warstw, z których każda łapie to, co przepuściła poprzednia. Pierwsza to sam agent: uprawnienia z pytaniem o zgodę, izolacja poleceń i zaufanie tylko do własnych repozytoriów. Druga to commit i push: push protection i secret scanning, a klucze poza repozytorium. Trzecia to zależności: plik lock, sprawdzenie nowych pakietów i Dependabot. Czwarta to przegląd diffu i CI, czyli to, co opisuję w artykule o testach i review. Piąta to produkcja i dane: RLS, klucz tajny wyłącznie na serwerze, aktualizacje po ogłoszeniu CVE i rotacja kluczy. Dlatego checklista poniżej układa je w jedną kolejność. Dokumentacja GitHub opisuje dwie pierwsze warstwy jako osobne funkcje, a OWASP Top 10:2025 wymienia kontrolę dostępu, błędy w łańcuchu dostaw i niewłaściwą konfigurację w pierwszej trójce. Żadna warstwa nie jest szczelna sama: push protection da się obejść z podaniem powodu, a Dependabot zna tylko znane podatności.

Schemat poniżej pokazuje kolejność warstw od agenta do produkcji.

Schemat pięciu warstw obrony kodu pisanego przez agenta AI: agent, commit i push, zależności, review i CI, produkcja i dane

Jeśli masz na to jeden dzień, zrób to w tej kolejności:

  1. Włącz secret scanning i push protection w ustawieniach repozytorium albo organizacji.
  2. Włącz Dependabot alerts oraz security updates.
  3. Sprawdź każdą tabelę w udostępnionym schemacie: czy ma RLS i czy polityki działają na dwóch kontach.
  4. Wyjmij prawdziwe klucze z repozytorium i z zasięgu agenta, a te, które już tam były, unieważnij.
  5. Zaktualizuj framework do wersji po ostatnich krytycznych CVE.

Ta sama lista w formie checklisty do wydruku lub przypięcia przy monitorze:

Checklista bezpieczeństwa aplikacji pisanej z AI: sekrety, zależności, dane, agent i aktualizacje, dziesięć punktów do odhaczenia

Czego to nie rozwiąże

Ten zestaw nie zastępuje przeglądu kodu przez człowieka. Secret scanning szuka znanych wzorców kluczy, więc nietypowy token może go ominąć. Dependabot nie wykryje błędu w logice Twojej aplikacji ani wymyślonego pakietu. RLS nie sprawdzi, czy reguły biznesowe są dobre. Dane, na których opieram artykuł, też mają granice: Veracode testował same modele, bez agentów i środowisk produkcyjnych, w czterech kategoriach podatności (CWE-89, CWE-327, CWE-80 i CWE-117) i bez poleceń dotyczących bezpieczeństwa. GitGuardian liczy publiczne commity, a Wiz objął 50 firm, więc nie mówią nic o kodzie prywatnym. Veracode, GitGuardian i Wiz sprzedają narzędzia bezpieczeństwa, co nie podważa ich liczb, ale każda z tych firm ma interes w tym, by problem wyglądał na duży. Wiz podaje 65% firm z wyciekiem, lecz to próba 50 spółek z jednej listy. Nie znalazłem w tych raportach porównania z kodem pisanym ręcznie na tych samych zadaniach, więc nie twierdzę, że AI jest bezpieczniejsze albo groźniejsze od człowieka.

Jaki błąd bezpieczeństwa popełniliśmy w portalu klienta?

Do klienta wylicz tylko potrzebne pola, zamiast przekazywać cały obiekt z zewnętrznego API. Rozwinięcie całego obiektu jest najkrótsze, więc łatwo je napisać, i dlatego warto je wyłapywać w review.

Obronę układamy warstwowo. Sesje w portalu przechowujemy jako skrót SHA-256, a w zasadach testów mamy zapis, że każda rzecz, która może wpuścić klienta do cudzych danych, ma mieć test. W naszym serwerze komunikatorów (Matrix) obrazy kontenerów są przypięte po sumie sha256, mają cap_drop: ALL i no-new-privileges, Synapse i mostki działają dodatkowo z read_only i jako zwykły użytkownik, a procedura aktualizacji każe odczekać od jednego do dwóch tygodni od wydania i zweryfikować podpis Synapse narzędziem cosign.

Najczęstsze pytania

Czy wystarczy poprosić agenta o bezpieczny kod?

Nie mam danych, które by to rozstrzygały. Veracode w komunikacie z lipca 2026 podaje, że testował w standardowych warunkach, bez poleceń dotyczących bezpieczeństwa. Moim zdaniem prośba nie zaszkodzi, ale nie zastępuje skanera ani przeglądu.

Czy usunięcie wyciekłego klucza z repozytorium wystarczy?

Nie. Dokumentacja GitHub każe unieważnić lub zmienić sekret natychmiast po alercie. Czyszczenie historii gita jest opcjonalne i często zbędne po unieważnieniu klucza. Dopóki klucz działa, każdy, kto go skopiował, może go użyć.

Czy GitHub skanuje moje repozytorium za darmo?

W repozytoriach publicznych secret scanning działa automatycznie i za darmo. W prywatnych repozytoriach organizacji wymaga GitHub Secret Protection w planie Team lub Enterprise Cloud. Dla prywatnych repozytoriów zwykłego konta dokumentacja nie wymienia takiej opcji, poza Enterprise Cloud z Enterprise Managed Users.

Czy Dependabot wykryje halucynowany pakiet?

Nie ma na to podstaw w dokumentacji. Alerty powstają z recenzowanych wpisów w GitHub Advisory Database, a świeżo zarejestrowany złośliwy pakiet z wymyślonej nazwy takiego wpisu zwykle nie ma. Pakiet sprawdź ręcznie przed zaakceptowaniem zmiany.

Czy hosting na Vercelu chroni przed takimi lukami?

Tylko w jednym opisanym przypadku. Według postmortem Vercela CVE-2025-29927 nie dotyczyła aplikacji na Vercelu, Netlify i Cloudflare Workers, a dotyczyła hostowanych samodzielnie. Przy CVE-2025-55182 decydują wersje pakietów react-server-dom-* i Next.js, nie miejsce hostingu.

Czy te dane dotyczą TypeScriptu?

Veracode testował Python, C#, JavaScript i Javę. Osobnych wyników dla TypeScriptu nie znalazłem. Najbliższy jest JavaScript z 57% zdanych testów w październiku 2026.

Czy włączone RLS oznacza, że baza jest bezpieczna?

Nie. Włączone RLS bez polityk blokuje dostęp przez klucz publiczny, ale źle napisana polityka może wpuścić wszystkich. Sprawdź ją na dwóch kontach i trzymaj klucz tajny wyłącznie po stronie serwera.

Źródła

Czytaj również

Stan na 11 listopada 2026. Liczby Veracode, GitGuardian i Wiz pochodzą z komunikatów i blogów firm sprzedających narzędzia bezpieczeństwa, a nie z recenzowanych badań, poza dwiema pracami z arXiv; dokumentacja GitHub i Supabase zmienia się, więc przed wdrożeniem sprawdź aktualne ustawienia.

raz na jakiś czas

Zostań w pętli

Nowe artykuły, narzędzia i case study prosto na maila. Bez spamu, bez sprzedaży.

To pole jest używane do walidacji i powinno pozostać niezmienione.
Zgodawymagane

Czytaj również