Kali Linux w AI OS: narzędzie audytu, nie serwer modeli

Kali Linux ma miejsce obok suwerennego AI OS jako środowisko testów bezpieczeństwa, nie jako domyślny host modeli i danych. To ważne rozróżnienie: system z dużym zestawem narzędzi audytowych nie staje się przez to bezpieczniejszą bazą produkcyjną. Twórcy Kali sami odradzają używanie go jako ogólnego desktopu czy systemu do zwykłego programowania.

Czym jest Kali?

Kali to dystrybucja oparta na Debianie, przygotowana do testów penetracyjnych, informatyki śledczej, badań bezpieczeństwa i analizy podatności. Oficjalne FAQ wymienia środowiska fizyczne, wirtualne, kontenery i instalacje izolowane. Projekt celowo zmienia część ustawień względem uniwersalnego Linuksa, np. ogranicza usługi sieciowe uruchamiane domyślnie. Dlatego nie należy przenosić recept z Kali bezpośrednio na host produkcyjny.

Do czego przydaje się w systemach AI?

Własny system agentowy ma powierzchnię ataku: API modeli, bazę wektorową, integracje MCP, sekrety narzędzi i uprawnienia do wykonywania akcji. Z Kali można prowadzić autoryzowany audyt ekspozycji sieciowej i konfiguracji tych składników. Sam Kali nie testuje poprawności odpowiedzi LLM, odporności na prompt injection ani jakości decyzji agenta; do tego potrzebne są osobne scenariusze i ewaluacje. Granice uprawnień agenta opisuje też filar bezpieczeństwa AI.

W praktyce przygotuj odizolowaną kopię środowiska, pisemny zakres testu, konta o ograniczonych rolach i dziennik działań. Dla agenta testowego zdefiniuj limit narzędzi i zakaz modyfikacji danych produkcyjnych. Wynik audytu powinien mieć reprodukcję, wpływ na proces i test poprawki, a nie tylko listę skanerów.

Czy Kali wzmacnia suwerenność?

Kod i obrazy można pobrać i utrzymywać lokalnie, więc Kali nie wymaga zewnętrznej usługi do samego uruchomienia. Suwerenność audytu oznacza jednak także kontrolę nad danymi z testów, kluczami i raportami. Kopia bazy klientów na laptopie audytora może naruszyć ten cel, nawet jeśli laptop pracuje pod Linuksem. Używaj danych syntetycznych i lokalnych repozytoriów narzędzi, jeżeli środowisko jest odłączone od sieci.

Alternatywy i AI SDLC

Na produkcyjny serwer AI wybierz Debiana, Ubuntu, Rocky lub system wspierany przez dostawcę sprzętu. Do oceny kodu i kontenerów Kali może uzupełnić skanery SAST, testy zależności oraz kontrole konfiguracji uruchamiane w CI. Agent kodujący może przygotować test regresyjny dla znalezionej podatności, ale nie powinien sam uznać swojej poprawki za bezpieczną. Punkt odbioru w AI SDLC to powtórzony test przez niezależną osobę lub proces.

Przykładowy zakres audytu agenta

Załóżmy, że agent obsługi klienta może odczytać zamówienie i wywołać operację zwrotu. Zacznij od mapy kont i endpointów, nie od uruchomienia skanera. Sprawdź, czy token agenta pozwala odczytać tylko dane właściwego klienta, czy logi zapisują sekrety i czy żądanie zmiany stanu przechodzi przez autoryzację serwera. Testuj odmowę dostępu, wygasły token, nadmierną liczbę żądań i próbę wywołania narzędzia z niewłaściwym identyfikatorem zamówienia.

Kali może pomóc badać techniczną ekspozycję tych API. Oddzielny zestaw testów powinien wykazać, czy treść dokumentu lub wiadomości może skłonić model do użycia narzędzia poza intencją użytkownika. To test granicy zaufania modelu, nie klasyczny skan portów. Obie grupy wyników połącz z logiem decyzji agenta, aby można było odtworzyć incydent bez ujawniania danych klienta.

Bezpieczna procedura wykonania

Zatwierdź środowisko i okno testowe, przygotuj kopię danych syntetycznych, ustaw limit żądań, a potem zbieraj wyłącznie dowody potrzebne do odtworzenia błędu. Po teście usuń nadane konta i sekrety. W raporcie rozdziel: podatność hosta, błąd autoryzacji API, podatność integracji agenta oraz słabą odpowiedź modelu. Inaczej właściciel systemu nie wie, kto ma naprawić problem. Kali jest wtedy narzędziem kontrolnego sprawdzenia AI OS, a nie elementem jego ścieżki produkcyjnej.

Powtórz audyt po istotnej zmianie narzędzi agenta, sieci lub sposobu przechowywania sekretów. Nowa wersja modelu może zmienić jego zachowanie, lecz nie powinna poszerzać technicznych uprawnień. Raport powinien więc porównywać zarówno zachowanie aplikacji, jak i granice wymuszane przez API. Tylko druga warstwa chroni organizację wtedy, gdy model zinterpretuje złośliwą instrukcję jako polecenie działania.