Aplikacja oparta na modelu językowym może odpowiadać poprawnie podczas zwykłej rozmowy, a mimo to stwarzać poważne zagrożenie bezpieczeństwa. Problem ujawnia się dopiero wtedy, gdy użytkownik wprowadzi złośliwą instrukcję, dokument w bazie wiedzy zawiera ukryty prompt, agent otrzyma zbyt szerokie uprawnienia albo wygenerowana odpowiedź zostanie bezpośrednio przekazana do systemu wykonawczego. Dlatego audyt bezpieczeństwa aplikacji LLM nie powinien ograniczać się do pytania, czy model „daje dobre odpowiedzi”. Trzeba przeanalizować cały łańcuch: interfejs, prompty, dane, model, mechanizmy RAG, narzędzia, API, uprawnienia, logowanie i infrastrukturę.
Praktycznym punktem odniesienia jest OWASP Top 10 for LLM Applications. Lista ta porządkuje najważniejsze klasy ryzyka związane z aplikacjami wykorzystującymi duże modele językowe, ale nie zastępuje pełnego audytu aplikacji, testów infrastruktury ani analizy wymagań prawnych. Poszczególne zagrożenia mogą występować jednocześnie. Prompt injection może prowadzić do wycieku danych, nadmierne uprawnienia agenta mogą zamienić manipulację odpowiedzią w zmianę rekordu w systemie, a zatrute dokumenty w bazie wektorowej mogą wpływać na wiele sesji użytkowników.
Najbezpieczniej prowadzić audyt w określonej kolejności: najpierw ustalić zakres i przepływ danych, następnie przetestować wejście oraz kontekst, później wyjście i integracje, a na końcu sprawdzić odporność operacyjną, monitoring i proces naprawczy. Takie podejście ułatwia rozróżnienie między wadą samego modelu a błędem architektury aplikacji.
Ustal zakres audytu i przygotuj bezpieczne środowisko testowe
Zdefiniuj, co właściwie podlega audytowi
Pierwszym krokiem jest opisanie aplikacji jako całego systemu, a nie tylko okna czatu. Zakres powinien obejmować interfejs użytkownika, backend, model lub modele, prompty systemowe, historię rozmów, pamięć sesji, mechanizm pobierania danych, bazę wiedzy, indeks wektorowy, narzędzia wywoływane przez agenta, zewnętrzne API, kolejki, logowanie i warstwę autoryzacji. Jeśli chatbot może wystawić zgłoszenie, wysłać wiadomość, wyszukać fakturę lub zmienić dane klienta, wszystkie te operacje należą do audytu.
Trzeba też rozdzielić audyt modelu od audytu aplikacji wykorzystującej model. Model może być podatny na próby zmiany instrukcji, ale ryzyko staje się krytyczne dopiero wtedy, gdy aplikacja ufa jego decyzjom, przekazuje mu poufny kontekst lub pozwala mu wykonywać działania. W wielu wdrożeniach największe problemy powstają na styku modelu z bazą danych, systemem uprawnień i narzędziami zewnętrznymi, a nie w samym mechanizmie generowania tekstu.
W dokumentacji audytu trzeba wskazać konkretną wersję OWASP Top 10 for LLM Applications, która służy jako punkt odniesienia. Nazwy, opisy i akcenty mogą zmieniać się między edycjami. Nie należy więc bezrefleksyjnie kopiować listy z nieaktualnego raportu. Dobrą praktyką jest zapisanie daty przyjęcia metodyki, wersji dokumentu oraz ewentualnego mapowania na wewnętrzny katalog kontroli bezpieczeństwa.
Zakres należy odnieść do rzeczywistych scenariuszy biznesowych. Inaczej testuje się publicznego chatbota odpowiadającego na pytania z instrukcji obsługi, inaczej asystenta pracownika mającego dostęp do poczty, a jeszcze inaczej agenta podejmującego działania w systemie finansowym. Dla każdego procesu warto zapisać:
kto może korzystać z funkcji i w jakiej roli;
jakie dane użytkownik może podać;
jakie dane aplikacja pobiera automatycznie;
jakie decyzje podejmuje model;
jakie działania może uruchomić odpowiedź;
co stanie się po błędnej, zmanipulowanej lub niejednoznacznej odpowiedzi.
Zbierz informacje przed rozpoczęciem testów
Audyt bez aktualnej inwentaryzacji łatwo przeoczy komponent, który nie jest widoczny w głównym interfejsie. Lista zasobów powinna obejmować dostawców modeli i ich endpointy, używane wersje modeli, biblioteki, frameworki orkiestrujące, pluginy, agenty, parsery dokumentów, systemy OCR, indeksy wektorowe, repozytoria danych oraz usługi chmurowe. Należy uwzględnić także komponenty pomocnicze, na przykład system kolejkowania, narzędzie do obserwowalności i usługę przechowującą historię konwersacji.
Niezbędna jest mapa przepływu informacji. Powinna pokazywać, co trafia do modelu z wiadomości użytkownika, promptu systemowego, pamięci rozmowy i bazy wiedzy. Trzeba oznaczyć, gdzie powstaje odpowiedź, czy przechodzi przez filtr lub walidator, gdzie jest zapisywana oraz które systemy mogą ją wykonać. W przypadku agenta warto narysować osobne ścieżki dla odczytu danych, zapisu danych i działań nieodwracalnych.
Przykładowo użytkownik wpisuje pytanie w przeglądarce, backend dodaje instrukcję systemową, moduł RAG wyszukuje fragmenty dokumentów, model wybiera narzędzie, a warstwa wykonawcza wywołuje API CRM. Każda granica pomiędzy tymi elementami jest miejscem, które trzeba przetestować. Szczególnie istotne jest ustalenie, czy narzędzie przyjmuje argumenty wygenerowane przez model bez dodatkowej walidacji oraz czy sprawdzenie uprawnień odbywa się przed wywołaniem, a nie dopiero po nim.
Osobno należy spisać role: użytkownik anonimowy, użytkownik zalogowany, administrator, operator procesu, konsultant oraz konto techniczne aplikacji. Uprawnienia konta technicznego nie mogą być traktowane jako uprawnienia każdego użytkownika. Jeżeli backend korzysta z jednego szeroko uprzywilejowanego konta, test powinien sprawdzić, czy model nie może pośrednio wykorzystać pełnego zakresu jego dostępu.
W inwentaryzacji danych trzeba oznaczyć dane osobowe, dane finansowe, informacje objęte tajemnicą przedsiębiorstwa, dane uwierzytelniające, klucze API, treści klientów i dokumenty wewnętrzne. Sam fakt, że informacja została przekazana modelowi, nie oznacza, że może być zwrócona użytkownikowi. Audyt powinien badać zarówno dostęp modelu do danych, jak i możliwość ich późniejszego ujawnienia przez odpowiedź, log, komunikat błędu albo narzędzie obserwacyjności.
Przygotuj zasady bezpiecznych testów
Testy bezpieczeństwa powinny odbywać się na kopii środowiska lub w kontrolowanym trybie. Nie należy używać prawdziwych haseł, aktywnych kluczy, pełnych danych klientów ani produkcyjnych dokumentów tylko dlatego, że ułatwiają test. Jeśli nie da się odtworzyć konkretnego scenariusza bez danych rzeczywistych, trzeba ograniczyć ich zakres, zanonimizować je i uzyskać odpowiednią zgodę.
Środowisko testowe powinno mieć osobne konta, ograniczone klucze API, sztuczne rekordy oraz możliwość szybkiego wyłączenia narzędzi. Dla operacji wysokiego ryzyka przydatny jest tryb symulacji: agent generuje żądanie działania, ale nie wysyła go do systemu docelowego. Dzięki temu można sprawdzić, czy próba prompt injection doprowadziłaby do niebezpiecznej akcji, bez faktycznego usuwania danych lub wysyłania korespondencji.
Przed rozpoczęciem należy określić, czy audyt obejmuje tylko kod aplikacji, czy również dostawcę modelu, biblioteki open source, bazę wiedzy, pipeline ingestowania dokumentów i konfigurację chmury. Audytor nie powinien samodzielnie testować cudzej usługi ani wykonywać obciążających prób bez zgody. Dotyczy to szczególnie testów związanych z masowym generowaniem, skanowaniem endpointów i próbami przekroczenia limitów.
Każdy test powinien zostawiać ślad pozwalający odtworzyć przebieg, ale logowanie nie może samo stać się źródłem wycieku. W logach można rejestrować identyfikator testu, rolę, czas, typ ataku, wersję modelu, wywołane narzędzie, decyzję autoryzacyjną i wynik. Treść promptu lub odpowiedzi należy przechowywać tylko wtedy, gdy jest to potrzebne, a dane poufne powinny być maskowane.
Kryteria zaliczenia pierwszego etapu
Etap przygotowawczy można uznać za zamknięty, gdy istnieje aktualny diagram architektury, lista komponentów, rejestr przepływów danych i katalog ról. Każdy scenariusz testowy powinien mieć przypisane środowisko, konto, zakres dozwolonych działań oraz oczekiwany rezultat. Zespół musi wiedzieć, które testy są bezpieczne do wykonania automatycznie, a które wymagają dodatkowej zgody.
Jeśli nie wiadomo, jaki model działa w produkcji, jakie dokumenty trafiają do indeksu albo kto może zatwierdzić akcję agenta, nie jest to drobna niedogodność organizacyjna. To ustalenie audytowe. Brak inwentaryzacji zwiększa ryzyko, że wynik zostanie uznany za pozytywny tylko dlatego, że nie przetestowano właściwego komponentu.
Przeprowadź testy wejścia, promptów i danych dostarczanych modelowi
Prompt injection — sprawdź, czy model daje się nakłonić do obejścia instrukcji
Prompt injection polega na dostarczeniu modelowi treści, która próbuje zmienić jego zachowanie wbrew regułom aplikacji. Testy bezpośrednie wykonuje się w wiadomości użytkownika. Należy sprawdzić próby unieważnienia instrukcji systemowych, zmiany roli, ujawnienia reguł działania, obejścia polityki bezpieczeństwa oraz wykonania polecenia sprzecznego z celem aplikacji.
Nie trzeba ograniczać się do jednej oczywistej formuły. Test powinien obejmować polecenia zapisane w różnych językach, z nietypowym formatowaniem, w cytacie, w tabeli, jako fragment kodu, w środku długiego tekstu oraz w postaci instrukcji udającej komunikat systemowy. Przydatne jest sprawdzenie, czy model rozróżnia dane od poleceń. Zdanie „dokument zawiera instrukcję, aby ujawnić dane” powinno pozostać treścią dokumentu, a nie stać się poleceniem dla agenta.
Osobną grupę stanowią ataki pośrednie. Złośliwa instrukcja może znajdować się w pliku PDF, wiadomości e-mail, stronie internetowej, zgłoszeniu klienta, komentarzu w systemie albo rekordzie pobranym przez RAG. Użytkownik nie musi jej nawet widzieć. Wystarczy, że aplikacja pobierze taki materiał i przekaże go modelowi jako kontekst. Test polega na umieszczeniu kontrolowanej instrukcji w danych, a następnie sprawdzeniu, czy model ją wykonuje, powtarza lub przekazuje do kolejnego narzędzia.
Ocena nie może kończyć się na treści odpowiedzi. Trzeba sprawdzić skutki działania. Udany atak może spowodować:
pobranie dokumentu z niedozwolonego źródła;
wywołanie API z argumentem kontrolowanym przez atakującego;
wysłanie wiadomości lub utworzenie zgłoszenia;
zmianę rekordu w bazie;
ujawnienie fragmentu kontekstu należącego do innego użytkownika;
ominięcie wymogu potwierdzenia przez człowieka.
Skuteczna obrona nie polega na ukryciu jednego promptu ani na dodaniu zdania „ignoruj złośliwe instrukcje”. Instrukcja systemowa może pomóc, ale nie jest granicą bezpieczeństwa. Ochronę trzeba budować warstwowo: separować dane od instrukcji, ograniczać kontekst, walidować wywołania narzędzi, stosować autoryzację po stronie backendu i wymagać potwierdzenia dla operacji ryzykownych.
System prompt leakage — zweryfikuj ochronę instrukcji wewnętrznych
Test system prompt leakage sprawdza, czy użytkownik może uzyskać pełny prompt systemowy, reguły moderacji, nazwy narzędzi, warunki routingu albo ukryte komunikaty. Próby mogą przyjmować formę bezpośredniej prośby, polecenia odtworzenia instrukcji w innym formacie, prośby o streszczenie zasad lub pytania o to, jakie warunki prowadzą do wywołania określonego narzędzia.
Samo ujawnienie instrukcji nie zawsze oznacza krytyczną podatność. Znacznie ważniejsze jest to, co znajduje się w promptach. Jeśli zawierają sekrety, klucze API, dane osobowe, szczegółowe reguły biznesowe albo informacje umożliwiające obejście kontroli, problem ma wysoki priorytet. Prompt systemowy powinien być traktowany jako element konfiguracji, a nie jako bezpieczny magazyn poufnych danych.
Sprawdź, czy wejście nie prowadzi do ujawnienia danych wrażliwych
Następny test powinien objąć dane, które użytkownik może wprowadzić do aplikacji oraz informacje automatycznie dołączane do zapytania. Celem jest ustalenie, czy system nie przyjmuje bez kontroli haseł, kluczy API, numerów dokumentów, danych medycznych, informacji finansowych albo treści objętych tajemnicą przedsiębiorstwa.
Warto przygotować zestaw kontrolnych wartości oznaczonych jednoznacznymi znacznikami, na przykład TEST-SECRET-001 i TEST-CUSTOMER-002. Następnie trzeba sprawdzić, czy te wartości pojawiają się w:
historii rozmowy i pamięci sesji;
promptach wysyłanych do modelu;
kontekście pobieranym przez RAG;
logach aplikacji i narzędziach obserwowalności;
komunikatach błędów;
odpowiedziach dla innych użytkowników lub w innych sesjach.
Test należy wykonać z użyciem różnych ról. Użytkownik powinien otrzymać tylko te dane, do których ma uprawnienia, nawet jeśli model zna szerszy kontekst albo potrafi odgadnąć nazwę dokumentu. Trzeba sprawdzić również przełączanie użytkownika, ponowne użycie identyfikatora sesji, współdzielenie pamięci oraz wyszukiwanie po dokładnym identyfikatorze rekordu.
Istotny jest scenariusz mieszania danych. Należy utworzyć co najmniej dwa konta testowe i oznaczyć ich dane różnymi znacznikami. Po zakończeniu rozmowy na pierwszym koncie trzeba wykonać pytania na drugim koncie, w tym pytania ogólne, prośby o podsumowanie wcześniejszych rozmów oraz zapytania wykorzystujące podobne słowa kluczowe. Pojawienie się znacznika przypisanego do pierwszego konta oznacza możliwy problem z izolacją sesji, pamięcią lub filtrowaniem wyników.
Zweryfikuj granicę między danymi użytkownika a instrukcją
Nie każda treść wejściowa powinna być interpretowana jako polecenie. W aplikacji analizującej dokumenty, wiadomości lub zgłoszenia tekst pobrany z pliku jest przede wszystkim danymi. Trzeba sprawdzić, czy system zachowuje tę granicę także wtedy, gdy dokument zawiera czasowniki rozkazujące, komunikaty przypominające instrukcje systemowe albo tekst sformatowany jako komunikat dla agenta.
Przygotuj dokumenty testowe zawierające:
zwykły opis procesu z pojedynczą instrukcją osadzoną w akapicie;
tabelę, w której jedna komórka ma formę polecenia;
komentarz autora lub metadane pliku sugerujące zmianę zachowania;
tekst zakodowany w obrazie lub załączniku wymagającym OCR;
duplikat dokumentu z inną wersją osadzonej instrukcji;
treść, która wygląda jak wynik wcześniejszej rozmowy albo wiadomość administratora.
Dla każdego przypadku należy sprawdzić, czy model potrafi wykonać zadanie biznesowe bez podporządkowania się treści dokumentu. Jeżeli aplikacja ma jedynie streszczać pliki, wynik nie powinien zawierać wykonanych poleceń, zmian konfiguracji ani prób pobrania dodatkowych danych. Jeżeli model ma wyodrębniać pola, instrukcja umieszczona w wartości pola nie może zmienić schematu ani zakresu ekstrakcji.
Zbadaj odporność danych RAG na zatrucie i nieprawidłową aktualizację
W systemach korzystających z RAG trzeba przetestować nie tylko samo wyszukiwanie, ale również proces przyjmowania dokumentów do bazy wiedzy. Ryzyko powstaje, gdy użytkownik może dodać materiał, zmienić jego treść, wpłynąć na metadane albo doprowadzić do indeksowania dokumentu bez kontroli właściciela.
W kontrolowanym środowisku należy wprowadzić dokument zawierający:
sprzeczną informację oznaczoną jako najnowsza wersja;
złośliwą instrukcję skierowaną do modelu;
metadane podszywające się pod administratora;
nazwę i identyfikator podobne do zaufanego dokumentu;
treść przeznaczoną dla innego działu lub innej roli;
bardzo długi fragment mający zdominować kontekst wyszukiwania.
Audyt powinien ustalić, kto może publikować, zatwierdzać, usuwać i ponownie indeksować dokumenty. Należy sprawdzić, czy po zmianie uprawnień użytkownik traci dostęp także do wcześniej zindeksowanych treści oraz czy usunięcie pliku powoduje usunięcie jego fragmentów z indeksu, pamięci podręcznej i kopii pomocniczych.
Ważne jest również testowanie metadanych. Filtr typu department=finance nie może być jedyną kontrolą dostępu, jeżeli użytkownik może samodzielnie zmienić metadane dokumentu albo wpłynąć na filtr generowany przez model. Uprawnienia powinny być sprawdzane na podstawie wiarygodnego kontekstu użytkownika i egzekwowane poza modelem.
Sprawdź wyszukiwanie wektorowe i izolację kolekcji
W przypadku indeksów wektorowych należy przygotować rekordy testowe o podobnej treści, lecz przypisane do różnych użytkowników, projektów lub poziomów poufności. Następnie trzeba wykonać zapytania ogólne, zapytania o synonimy oraz pytania celowo omijające dokładne nazwy dokumentów. Celem jest sprawdzenie, czy podobieństwo semantyczne nie powoduje zwrócenia materiału spoza dozwolonego zakresu.
Testy powinny obejmować także:
brak identyfikatora dzierżawcy lub użytkownika w zapytaniu do indeksu;
zmianę filtrów przez parametry wejściowe;
odczyt identyfikatora dokumentu zwróconego przez wyszukiwanie;
dostęp do kolekcji należącej do innego środowiska;
rekordy o podobnych nazwach, lecz odmiennych uprawnieniach;
usunięte i zaktualizowane dokumenty pozostające w indeksie.
Wynik pozytywny nie oznacza wyłącznie, że model nie zacytował obcego dokumentu. Trzeba sprawdzić, czy nie otrzymał go w kontekście, czy identyfikator dokumentu nie został ujawniony, czy metadane nie pojawiły się w logach oraz czy użytkownik nie może wymusić ponownego pobrania treści przez kolejne pytania.
Przetestuj limity wejścia i ryzyko niekontrolowanego zużycia zasobów
Dane wejściowe mogą być wykorzystane do nadmiernego zużycia tokenów, pamięci, czasu obliczeń lub limitów usług zewnętrznych. Test należy wykonać stopniowo, zaczynając od bezpiecznych rozmiarów i używając wyłącznie środowiska testowego. Sprawdź, co dzieje się po przesłaniu bardzo długiej wiadomości, wielu załączników, powtarzalnych fragmentów, dużej liczby rekordów oraz dokumentu wymagającego intensywnego OCR.
Oceń, czy aplikacja ma odrębne limity dla:
długości wiadomości i liczby wiadomości w sesji;
liczby oraz rozmiaru załączników;
liczby wyników wyszukiwania RAG;
rozmiaru kontekstu przekazywanego do modelu;
liczby wywołań modelu przypadających na użytkownika;
czasu wykonywania parsera, OCR i narzędzi pomocniczych;
ponowień po błędzie i równoległych żądań.
Wynik testu powinien wskazywać nie tylko, czy żądanie zostało odrzucone. Należy sprawdzić, czy aplikacja zwraca kontrolowany błąd, nie ujawnia konfiguracji, nie próbuje bez końca ponawiać operacji i nie pozwala jednemu użytkownikowi zająć całej puli zasobów. Limity muszą działać również wtedy, gdy żądanie pochodzi z agenta lub z automatycznego procesu przetwarzania dokumentów.
Lista kontrolna testów wejścia i danych
Czy dane z różnych sesji i kont są wzajemnie odizolowane?
Czy aplikacja odrzuca lub maskuje sekrety przekazywane w wiadomościach i załącznikach?
Czy treść dokumentu jest traktowana jako dane, a nie jako instrukcja uprzywilejowana?
Czy dokumenty wprowadzane do RAG mają właściciela, wersję i kontrolowany proces publikacji?
Czy usunięcie dokumentu usuwa także jego fragmenty z indeksu i pamięci podręcznych?
Czy filtrowanie wektorowe jest powiązane z autoryzacją egzekwowaną poza modelem?
Czy zmiana metadanych nie pozwala uzyskać dostępu do cudzych treści?
Czy załączniki, OCR, parsery i formaty plików mają ograniczenia rozmiaru oraz czasu działania?
Czy limity obejmują także automatyczne ponowienia i działania agenta?
Czy testy sprawdzają ujawnienie danych w odpowiedzi, kontekście, logach i komunikatach błędów?
Najważniejsze ostrzeżenia podczas testów
Nie uznawaj odrzucenia odpowiedzi za pełną ochronę. Poufne dane mogą zostać przekazane do modelu, zapisane w historii albo ujawnione w logach, nawet gdy użytkownik nie zobaczy ich w finalnej odpowiedzi.
Nie ufaj samym metadanym dokumentu. Nazwa działu, etykieta poufności lub identyfikator właściciela powinny pochodzić z kontrolowanego źródła, a nie z treści edytowanej przez użytkownika.
Nie testuj limitów przez niekontrolowane przeciążenie. Wystarczy stopniowe zwiększanie obciążenia, pomiar czasu i obserwacja odrzuconych żądań.
Nie traktuj filtrowania RAG jako autoryzacji. Filtr może ograniczyć wyniki wyszukiwania, ale nie zastępuje kontroli dostępu w backendzie.
Nie pomijaj formatów innych niż tekst. Instrukcje mogą znajdować się w obrazie, arkuszu, komentarzu pliku, nazwie załącznika albo polu metadanych.
Po wykonaniu tej części audytu należy przypisać każdemu ustaleniu konkretny przepływ danych, rolę użytkownika, komponent oraz skutek biznesowy. Za zamknięty można uznać etap testów wejścia wtedy, gdy wiadomo, które treści są przyjmowane, gdzie są zapisywane, jak trafiają do kontekstu modelu, jakie limity je obejmują i czy dane różnych użytkowników pozostają odizolowane.
Najczęściej zadawane pytania (FAQ)
Czym jest audyt bezpieczeństwa aplikacji LLM?
To analiza całego systemu wykorzystującego model językowy: interfejsu, promptów, danych, mechanizmów RAG, narzędzi, API, uprawnień, logowania i infrastruktury.
Czy OWASP Top 10 for LLM Applications zastępuje pełny audyt?
Nie. OWASP Top 10 for LLM Applications porządkuje najważniejsze klasy ryzyka, ale nie zastępuje audytu aplikacji, testów infrastruktury ani analizy wymagań prawnych.
Dlaczego trzeba audytować także narzędzia używane przez agenta?
Agent może wykorzystać narzędzia do odczytu lub zmiany danych. Należy sprawdzić, czy argumenty wygenerowane przez model są walidowane oraz czy autoryzacja odbywa się przed wykonaniem operacji.
Jak przygotować środowisko do testów bezpieczeństwa?
Testy powinny odbywać się w kopii środowiska lub kontrolowanym trybie, z użyciem sztucznych danych, osobnych kont, ograniczonych kluczy API i możliwości szybkiego wyłączenia narzędzi.
Co należy uwzględnić w mapie przepływu danych?
Mapa powinna pokazywać dane pochodzące od użytkownika, prompt systemowy, pamięć rozmowy, bazę wiedzy, odpowiedź modelu, walidatory, logi oraz systemy, które mogą wykonać wygenerowane działanie.
Najważniejsze wnioski
Audyt aplikacji LLM powinien obejmować cały system, a nie tylko jakość odpowiedzi modelu.
OWASP Top 10 for LLM Applications jest punktem odniesienia, ale nie zastępuje pełnego audytu aplikacji i infrastruktury.
Przed testami trzeba przygotować inwentaryzację komponentów, mapę przepływu danych, katalog ról i bezpieczne środowisko.
Szczególnej uwagi wymagają prompt injection, dane pobierane przez RAG, uprawnienia agentów i narzędzia wykonawcze.
Testy powinny być odtwarzalne, kontrolowane i prowadzone tak, aby logowanie nie powodowało dodatkowego wycieku danych.
