"A może dodamy drugi model AI, który będzie sprawdzał czy pierwszy nie został oszukany?"
Brzmi logicznie. Próbowaliśmy. Nie działa.
Ten wpis wyjaśnia, dlaczego intuicyjne rozwiązanie "AI sprawdzi AI" zawodzi – i co robić zamiast tego.
- Skąd bierze się ta intuicja
- Dlaczego to nie działa
- Dlaczego 95% skuteczności to porażka
- Co działa zamiast tego
- Praktyczne wnioski
Skąd bierze się ta intuicja
Kiedy słyszysz o prompt injection – że atakujący może umieścić w treści instrukcje, które model AI wykona – naturalną reakcją jest:
"Dobra, to dodajmy drugi model, który będzie sprawdzał odpowiedzi pierwszego. Albo który będzie filtrował wejście."
To brzmi jak rozsądna architektura. Mamy strażnika, który pilnuje głównego agenta. Dwóch jest lepszych niż jeden, prawda?
Problem jest fundamentalny: drugi model AI ma te same podatności co pierwszy.
Dlaczego to nie działa
Simon Willison, jeden z najbardziej wpływowych głosów w dziedzinie bezpieczeństwa AI, ujął to zwięźle:
"Nie możesz rozwiązać problemów bezpieczeństwa AI przy pomocy więcej AI. Te same podatności, które pozwalają na prompt injection, dotyczą również każdego modelu, którego użyjesz do wykrywania tych ataków."
Pomyśl o tym tak:
| Scenariusz | Co się dzieje |
| Filtr AI na wejściu | Atakujący tworzy prompt, który omija filtr I atakuje główny model |
| Walidator AI na wyjściu | Jeśli atak się powiódł, walidator też może zostać oszukany |
| Drugi model sprawdza pierwszy | Atakujący może zaatakować oba modele jednym promptem |
To jak zatrudnienie drugiego strażnika, który ma te same słabości co pierwszy. Jeśli złodziej wie, jak oszukać jednego, prawdopodobnie wie jak oszukać obu.
Modele językowe nie mają wrodzonej odporności na manipulację. Ich rozumienie kontekstu jest probabilistyczne, nie logiczne. To co działa jako atak na jeden model, często działa na inne.
Dlaczego 95% skuteczności to porażka
Wiele firm sprzedaje produkty "guardrails" – warstwy bezpieczeństwa dla AI. Często reklamują się skutecznością: "Wykrywamy 95% ataków!"
W bezpieczeństwie informatycznym 95% to ocena niedostateczna.
Wyobraź sobie zamek w drzwiach, który działa 95% czasu. Albo system bankowy, który blokuje 95% nieautoryzowanych transakcji. Albo antywirus, który łapie 95% złośliwego oprogramowania.
Nie zaakceptowałbyś tego w żadnym innym obszarze bezpieczeństwa. Dlaczego miałoby być inaczej z AI?
| Skala użycia | Liczba interakcji dziennie | Udane ataki dziennie (przy 5% luk) |
| Mały chatbot | 100 | 5 |
| Średni system | 1 000 | 50 |
| Duża platforma | 100 000 | 5 000 |
Przy 100 000 interakcji dziennie i 95% skuteczności, masz 5 000 potencjalnych udanych ataków dziennie. To nie jest akceptowalne.
Co działa zamiast tego
Jeśli AI-based guardrails nie działają, co robić?
Strukturalne zabezpieczenia – rzeczy, które działają niezależnie od zachowania modelu:
Izolacja – agent nie ma dostępu do rzeczy, których nie potrzebuje (opisałem to w poprzednim wpisie)
Ograniczenie komunikacji – agent nie może wysyłać danych na dowolne adresy (allowlist zamiast blocklist)
Content Security Policy – odpowiedzi nie mogą zawierać linków/obrazków do niezaufanych domen
Human-in-the-loop – krytyczne akcje wymagają zatwierdzenia człowieka
Logowanie i audyt – wszystko jest zapisywane, anomalie są wykrywane po fakcie
Różnica kluczowa: strukturalne zabezpieczenia działają nawet gdy model jest w pełni kontrolowany przez atakującego. AI-based guardrails zakładają, że model zachowa się przewidywalnie – co jest dokładnie tym założeniem, które atakujący próbuje złamać.
Praktyczne wnioski
Na czym NIE polegać:
- Filtr AI sprawdzający wejście
- Walidator AI sprawdzający wyjście
- Obietnice dostawców o "99% skuteczności wykrywania"
- Prompt engineering jako jedyna linia obrony
Na czym polegać:
- Izolacja i sandboxing
- Minimalne uprawnienia
- Allowlisty zamiast blocklistów
- Human-in-the-loop dla krytycznych akcji
- Logowanie i monitoring
To nie znaczy, że filtry AI są całkowicie bezużyteczne. Mogą podnieść poprzeczkę dla atakujących i złapać proste, automatyczne ataki. Ale nie mogą być twoją jedyną ani główną linią obrony.
Myśl o nich jak o dodatkowej warstwie, nie jak o murze. Mur musi być strukturalny.
To trzeci wpis z serii o bezpieczeństwie agentów AI. W następnym wpisie napiszę o roli ludzkiego nadzoru – dlaczego pełna automatyzacja brzmi świetnie, ale może być niebezpieczna.