--- title: "OWASP w AI SDLC: bezpieczeństwo od zadania do wdrożenia" url: "https://majchrzycki.com/blog/owasp-bezpieczenstwo-w-ai-sdlc" description: "OWASP udostępnia otwarte projekty i praktyki bezpieczeństwa. Jak włączyć je w AI SDLC tworzenia systemów AI oraz kodowania z agentami." --- # OWASP w AI SDLC: bezpieczeństwo od zadania do wdrożenia 11 lipca 2026·2 min czytania·Krzysztof Majchrzycki Temat: [AI SDLC](https://majchrzycki.com/blog/filar/ai-sdlc) **OWASP (Open Worldwide Application Security Project) to społeczność tworząca otwarte materiały i narzędzia bezpieczeństwa aplikacji.** [Strona OWASP](https://owasp.org/) gromadzi projekty dotyczące klasycznych aplikacji, API, chmury i systemów generatywnej AI. W AI SDLC OWASP jest przydatny jako język rozmowy o ryzyku i źródło scenariuszy testowych, nie jako certyfikat, który sam zapewnia bezpieczeństwo. ## Dwa nurty AI SDLC, dwa zestawy pytań Gdy **budujemy system AI**, sprawdzamy dane wejściowe, retrieval, model, narzędzia, uprawnienia, logowanie i wynik. Prompt injection może wejść przez dokument pobrany z bazy, a nadmierna autonomia może zmienić rekord, choć użytkownik prosił tylko o analizę. Tu przydaje się [aktualna lista OWASP dla aplikacji LLM](https://majchrzycki.com/blog/owasp-llm-top-10-2026-lista-ryzyk) oraz osobne materiały OWASP dla agentów. Test bezpieczeństwa powinien obejmować granicę między tekstem nieufnym a poleceniem wykonywanym przez system. Gdy **tworzymy oprogramowanie z pomocą agenta kodującego**, ryzyka są inne: agent może wprowadzić podatność, pobrać złośliwą zależność, ujawnić sekret lub ominąć kontrolę zmiany. Review człowieka, testy automatyczne, skan zależności i minimalne uprawnienia narzędzi pozostają konieczne. [OWASP ZAP](https://majchrzycki.com/blog/owasp-zap-testy-api-agentow-ai) pomaga testować aplikacje webowe i API, ale nie oceni sam semantyki odpowiedzi LLM ani tego, czy agent miał prawo wykonać daną akcję. ## Praktyczny cykl kontroli Na etapie wymagania zapisz zasoby i działania, których agent nie może dotknąć. W projekcie architektury wyznacz granice zaufania: kto dostarcza dokument, kto wybiera narzędzie, kto zatwierdza zapis. W implementacji testuj autoryzację po stronie serwera, nie tylko w instrukcji modelu. W odbiorze dodaj scenariusze prompt injection, wycieku danych, błędnego źródła i niepoprawnego wykonania akcji. Po uruchomieniu monitoruj naruszenia polityk i ślad decyzji. Alternatywą nie jest „brak OWASP”, lecz inne uzupełniające ramy: NIST AI RMF, MITRE ATLAS i normy organizacyjne. OWASP jest szczególnie użyteczny dla zespołu wytwarzającego aplikację, bo jego listy ryzyk można przełożyć na backlog, testy i kryteria odbioru. Dobrą pierwszą pracą jest warsztat nad jednym agentem: spisać jego narzędzia, dane i możliwe skutki, po czym zbudować mały zestaw powtarzalnych testów przed każdą zmianą. ## Przykład kryterium odbioru zamiast hasła „bezpieczne AI” Załóżmy, że agent odczytuje zgłoszenia i przygotowuje odpowiedź do klienta. Wymaganie brzmi: „pracownik widzi tylko swoje zgłoszenia, a agent może przygotować wersję roboczą, ale nie wysłać jej bez zatwierdzenia”. Z tego wynikają testy: konto innego działu nie pobiera zgłoszenia; dokument w zgłoszeniu nie zmienia instrukcji systemowej; próba wysyłki przed zgodą jest odrzucana po stronie API; log pokazuje treść zatwierdzoną przez człowieka i rzeczywistego adresata. Każdy test ma obserwowalny wynik, więc może wejść do pipeline wdrożeniowego. Rozdziel też **test modelu** od **testu systemu**. Model może poprawnie odmówić w rozmowie, podczas gdy źle skonfigurowane narzędzie pozwala wywołać akcję. Albo przeciwnie: model może sformułować niebezpieczną propozycję, lecz serwer ją zablokuje. Oba zdarzenia należy zarejestrować i ocenić. Raport „model nie popełnił błędu w dziesięciu promptach” nie dowodzi, że cały system jest odporny. W pracy z agentami kodującymi dodaj regułę przeglądu zależności i sekretów. Pull request przygotowany przez agenta przechodzi te same testy co zmiana człowieka, a właściciel usługi odpowiada za decyzję o połączeniu. Testy bezpieczeństwa powinny obejmować także pliki wejściowe agenta: README, dokumentację i wyniki narzędzi, które mogą zawierać instrukcje podszywające się pod użytkownika. Właśnie tam często przebiega granica między pomocną automatyzacją a wykonaniem obcej woli. - Agenci AI - AI SDLC ## Przełóż temat na projekt w Twojej firmie Zobacz zakres współpracy: od rozpoznania procesu i danych po projekt rozwiązania AI. [Zobacz współpracę](https://majchrzycki.com/wspolpraca) ## Czytaj dalej - [OWASP ZAP w AI SDLC: testy API agentów i aplikacji](https://majchrzycki.com/blog/owasp-zap-testy-api-agentow-ai) - [OWASP LLM Top 10 2026: dziesięć ryzyk aplikacji z AI](https://majchrzycki.com/blog/owasp-llm-top-10-2026-lista-ryzyk) - [Prompt flow: testowanie przepływu aplikacji AI](https://majchrzycki.com/blog/co-to-jest-microsoft-prompt-flow) - [LangSmith: jak oceniać i śledzić aplikacje AI](https://majchrzycki.com/blog/langsmith-ai-application-lifecycle-management-alm)