Co znajdziesz w tym artykule?
Wprowadzenie do problemu
Bezpieczeństwo łańcucha dostaw AI obejmuje dziś nie tylko same wagi modeli i kod wykonywalny, ale również pliki pomocnicze odpowiedzialne za przetwarzanie danych wejściowych oraz interpretację wyników. Jednym z kluczowych elementów tej układanki jest tokenizer, czyli mechanizm mapujący tekst na tokeny i identyfikatory oraz wykonujący proces odwrotny podczas dekodowania odpowiedzi modelu.
Najnowsze ustalenia pokazują, że nawet pojedyncza modyfikacja pliku tokenizer.json może wpływać na zachowanie modelu w praktyce operacyjnej. To oznacza, że zaufanie do artefaktów AI nie może ograniczać się wyłącznie do kontroli wag i bibliotek uruchomieniowych.
W skrócie
Atak polega na manipulacji tokenizerem w modelach uruchamianych lokalnie, bez potrzeby modyfikowania samych wag. W rezultacie napastnik może zmienić sposób dekodowania odpowiedzi modelu, przechwytywać argumenty wywołań narzędzi, przekierowywać żądania lub doprowadzić do wycieku danych i poświadczeń.
- modyfikacja dotyczy pliku
tokenizer.json; - model może działać pozornie poprawnie mimo skażenia;
- zagrożenie wpisuje się w obszar AI supply chain;
- najbardziej narażone są środowiska lokalne i własne pipeline’y MLOps.
Kontekst i historia
Ryzyko związane z publicznymi repozytoriami modeli open source od dawna budzi zainteresowanie badaczy i zespołów bezpieczeństwa. W przeszłości wiele analiz koncentrowało się na złośliwym kodzie, backdoorach oraz artefaktach umożliwiających wykonanie nieautoryzowanych działań po stronie użytkownika.
Nowy scenariusz przesuwa uwagę na warstwę tokenizacji, która bywa błędnie traktowana jako niegroźna konfiguracja. To właśnie ta pozorna „pasywność” tokenizera sprawia, że jego manipulacja może pozostać niewidoczna dla tradycyjnych procedur walidacyjnych, mimo realnego wpływu na semantykę działania modelu i wyniki generowane przez system.
Analiza techniczna
Tokenizer pełni funkcję tłumacza między reprezentacją tekstową a numeryczną reprezentacją wejścia i wyjścia modelu. W ekosystemie Hugging Face mapowanie to często zapisane jest w pliku tokenizer.json, który zawiera rozbudowane słowniki tokenów, identyfikatorów i zasad dekodowania.
Kluczowy problem polega na tym, że pojedyncza zmiana w mapowaniu może wpłynąć na końcowy rezultat widoczny dla użytkownika lub aplikacji. Oznacza to, że warstwa inferencji może działać bez zmian, ale wynik dekodowania zostanie zmodyfikowany w sposób zgodny z intencją atakującego.
W scenariuszach agentowych i narzędziowych ryzyko staje się szczególnie poważne. Jeśli model generuje parametry wywołań funkcji, adresy URL, identyfikatory zasobów lub wartości przekazywane do API, spreparowany tokenizer może wpłynąć na sposób prezentacji tych danych i doprowadzić do ich podmiany, ujawnienia lub przekierowania przez infrastrukturę kontrolowaną przez napastnika.
Atak jest trudny do wykrycia, ponieważ zmodyfikowany artefakt może zachować pełną zgodność ze spodziewanym formatem pliku. Standardowe testy funkcjonalne mogą nie wykazać anomalii, jeśli model nadal odpowiada logicznie i nie generuje widocznych błędów. To sprawia, że kompromitacja może utrzymywać się przez dłuższy czas bez wzbudzania podejrzeń.
Problem dotyczy przede wszystkim modeli uruchamianych lokalnie, w tym artefaktów dystrybuowanych w formatach takich jak SafeTensors, ONNX czy GGUF. Warunkiem powodzenia ataku jest dostarczenie zmodyfikowanego pliku tokenizera do środowiska ofiary, co czyni ten wektor szczególnie istotnym w kontekście pobierania modeli z publicznych źródeł i automatycznych procesów wdrożeniowych.
Konsekwencje i ryzyko
Najpoważniejszym skutkiem jest utrata zaufania do integralności modelu i jego odpowiedzi. Jeżeli tokenizer może zostać zmanipulowany bez naruszenia pozornej funkcjonalności systemu, organizacja traci pewność, że zachowanie modelu odpowiada założeniom biznesowym i bezpieczeństwa.
Ryzyko obejmuje kilka krytycznych obszarów:
- eksfiltrację danych przez przekierowanie wywołań lub zmianę parametrów żądań;
- ujawnienie poświadczeń, tokenów dostępu i danych API;
- wdrożenie skażonego modelu do środowiska produkcyjnego bez wykrycia incydentu;
- rozszerzenie kompromitacji na wielu odbiorców w ramach łańcucha dostaw AI.
Z perspektywy przedsiębiorstwa oznacza to konieczność traktowania modeli open source podobnie jak pakietów oprogramowania, obrazów kontenerowych i zewnętrznych zależności. Każdy artefakt dołączony do modelu może stać się nośnikiem manipulacji, nawet jeśli nie jest klasycznym plikiem wykonywalnym.
Rekomendacje
Organizacje wykorzystujące modele open source powinny rozszerzyć polityki bezpieczeństwa o kontrolę integralności wszystkich plików składających się na model. Dotyczy to nie tylko wag, ale również tokenizerów, konfiguracji i pozostałych artefaktów towarzyszących.
- traktować
tokenizer.jsonjako element zaufanej bazy artefaktów; - stosować podpisy cyfrowe i weryfikację sum kontrolnych przed wdrożeniem;
- ograniczać użycie modeli z niezweryfikowanych repozytoriów publicznych;
- wprowadzić formalny proces zatwierdzania modeli przez MLOps i bezpieczeństwo;
- skanować artefakty AI pod kątem anomalii i oznak manipulacji;
- uruchamiać modele w środowiskach izolowanych z ograniczonym ruchem sieciowym;
- monitorować wywołania narzędzi, ruch wychodzący oraz nietypowe zmiany parametrów;
- utrzymywać inwentarz modeli i plików pomocniczych w formie rozszerzonego SBOM lub AI BOM.
Dodatkowo zespoły SOC, DevSecOps i MLOps powinny objąć modele AI standardowymi procedurami wykrywania kompromitacji łańcucha dostaw. Obejmuje to porównywanie zmian między wersjami, analizę pochodzenia artefaktów i testy bezpieczeństwa po każdej aktualizacji.
Podsumowanie
Manipulator tokenizera pokazuje, że bezpieczeństwo AI nie kończy się na ochronie wag modelu czy kontroli promptów. Pozornie drugorzędny plik może wpłynąć na odpowiedzi systemu, parametry wywołań narzędzi oraz poufność danych przetwarzanych przez aplikację.
Dla organizacji to wyraźny sygnał, że pełna ochrona łańcucha dostaw AI wymaga kontroli integralności wszystkich artefaktów. W środowiskach opartych na lokalnie uruchamianych modelach open source takie podejście staje się nie tylko dobrą praktyką, ale operacyjną koniecznością.