Ostatnio mnożą się alerty o podatnościach bezpieczeństwa związanych z pośrednimi atakami typu prompt injection. Główny wniosek brzmi: LLM-y są łatwowierne i nikt nie wie, jak uczynić je całkowicie odpornymi. W związku z tym żaden system AI nie jest bezpieczny.
To oczywiście całkowita prawda i uwaga, jaką przyciągają te ataki, jest jak najbardziej pożądana, ale główne pytanie pozostaje bez odpowiedzi: co z tym właściwie zrobić?
Puryści forsowaliby zakaz wszelkich zewnętrznych danych wejściowych, które mogłyby prowadzić do prompt injection, ale szczerze mówiąc, nie byłbym aż tak pryncypialny. Wiele naprawdę użytecznych aplikacji opiera się na zewnętrznym wejściu, więc obawiam się, że musimy się cofnąć do ostatniej linii obrony: dyscypliny inżynierskiej.
Istnieją różne schematy wykorzystujące sprytną interakcję kilku modeli, żeby zminimalizować ich ekspozycję na ataki (zob. na przykład artykuł o CaMeL). Uważam jednak, że za mało uwagi poświęcamy zwykłej sanityzacji danych wejściowych.
Wiele takich ataków opiera się na tekście ukrytym przed człowiekiem, lecz widocznym dla maszyny. Wykrywanie i usuwanie takiego tekstu jest stosunkowo trywialne (w sensie programistycznym), choć wymaga pracy na poziomie kontenera, a nie samego tekstu. Ta technika (nazywana swoją drogą Content Disarm & Reconstruction) istnieje już od dłuższego czasu. Szczerze mówiąc, dziwi mnie, że nie jest wdrożona wszędzie. Nie powstrzymałaby wszystkich ataków, ale utrudniłaby życie mało wyrafinowanemu napastnikowi.
A tym, którzy upierają się, że 99% w bezpieczeństwie to ocena niedostateczna, chciałbym przypomnieć fundamentalną zasadę bezpieczeństwa: żaden system nie jest w 100% bezpieczny. Rolą bezpieczeństwa jest sprawić, żeby atak kosztował więcej niż potencjalna korzyść z niego płynąca (zob. model Gordona–Loeba).
Z tym paradygmatem w głowie możemy budować niezawodne i bezpieczne systemy AI, nawet z niebezpiecznych pojedynczych komponentów.