Frameworki agentów AI zmieniają prompt injection w lukę bezpieczeństwa

Google News zwróciło w tym tygodniu uwagę na bezpośredni argument dotyczący bezpieczeństwa: mimo lat budowania zabezpieczeń wokół prompt injection, nie jest ono pierwotną usterką. Głębszy problem tkwi w frameworkach agentów AI, które zamieniają niepewne wyniki modeli w uprzywilejowane działania.

To rozróżnienie zmienia zakres zabezpieczeń, za które odpowiadają zespoły inżynieryjne. Zmanipulowany chatbot może generować nonsensowne odpowiedzi. Zmanipulowany agent może odczytywać prywatne pliki, wywoływać API, modyfikować kod, wysyłać wiadomości lub zanieczyszczać współdzieloną pamięć.

Ujęcie przedstawione przez The Register podważa znane założenie. Deweloperzy często traktują złośliwy tekst jako podatność, a silniejsze prompty jako środek zaradczy. Ważniejsze pytanie dotyczy tego, na co pozwala system otaczający model po tym, jak zaakceptuje on taki tekst.

Nie oznacza to, że prompt injection jest nieszkodliwe. Nadal pozostaje niezawodnym sposobem wpływania na modele za pomocą bezpośrednich żądań lub niezaufanych treści zewnętrznych. Wstrzyknięcie staje się jednak naruszeniem operacyjnym dopiero wtedy, gdy architektura zapewnia uprawnienia, dane i ścieżkę wykonania.

Wyłaniająca się rywalizacja jest zatem jasna. Jedna strona polega na modelach, które mają rozpoznawać niebezpieczne instrukcje w niejednoznacznym języku. Druga zakłada, że rozpoznawanie w końcu zawiedzie, i ogranicza zakres działań, jakie może wykonać każdy przejęty model.

Google News stawia framework agenta w centrum uwagi

Najważniejsza zmiana polega na przesunięciu odpowiedzialności z zachowania modelu na architekturę systemu.

Prompt injection zwykle opisywano jako problem bezpieczeństwa modelu. Atakujący umieszcza instrukcje w prompcie, dokumencie, witrynie internetowej, e-mailu, obrazie lub odpowiedzi narzędzia. Model następnie stosuje się do tych instrukcji zamiast do rzeczywistego żądania użytkownika.

Opis ten jest trafny, lecz niepełny. Wskazuje metodę używaną do wpływania na model, ale nie identyfikuje luki w mechanizmach kontroli, która prowadzi do rzeczywistych szkód. Niezaufany tekst nie może samodzielnie usunąć pliku, pobrać rekordu klienta ani opublikować kodu źródłowego.

Framework agenta zapewnia te możliwości. Łączy model z narzędziami, poświadczeniami, pamięcią, bazami danych, przeglądarkami, interpreterami kodu i innymi agentami. Może też decydować, czy model może działać bez ponownej autoryzacji człowieka.

Architektura może zamienić jedną błędną interpretację w sekwencję skutków ubocznych. Zatruta strona internetowa staje się żądaniem użycia narzędzia. Żądanie narzędzia staje się zapytaniem do bazy danych. Pobrany materiał pojawia się następnie w wiadomości wychodzącej wygenerowanej przez tego samego agenta.

Pośrednie prompt injection ma tu szczególne znaczenie. Atakujący nie potrzebuje dostępu do interfejsu czatu. Złośliwe instrukcje mogą czekać w treściach, na które agent natrafi podczas zwykłego zadania.

Agent badawczy może napotkać instrukcje na stronie internetowej. Asystent programistyczny może znaleźć je w opisie zgłoszenia lub pliku repozytorium. Agent biurowy może pobrać je z e-maila, zaproszenia kalendarzowego lub współdzielonego dokumentu.

W każdym przypadku model stoi przed trudnym problemem klasyfikacji. Musi rozróżnić tekst opisujący instrukcję od tekstu, któremu należy się podporządkować. Oba trafiają jako tokeny języka naturalnego do roboczego kontekstu modelu.

Definicja ryzyka OWASP uwzględnia zarówno bezpośrednie, jak i pośrednie wstrzyknięcia. Zauważa również, że wpływ w dużej mierze zależy od kontekstu biznesowego i sprawczości przyznanej modelowi.

Ten ostatni warunek ma większe znaczenie, niż początkowo się wydaje. To samo złośliwe zdanie może prowadzić do radykalnie różnych skutków w dwóch wdrożeniach. Podsumowujący model z dostępem tylko do odczytu może wygenerować zniekształcony akapit, podczas gdy uprzywilejowany agent może ujawnić poufne informacje.

Google News jest użytecznym kanałem odkrywania tej debaty, lecz nie stanowi źródła pierwotnego. Nagłówek wskazuje na szerszy dorobek prac nad bezpieczeństwem, który coraz częściej traktuje przejęcie agenta jako zagrożenie architektoniczne.

NIST opisuje przejęcie agenta jako pośrednie prompt injection, które powoduje wykonanie przez agenta niezamierzonych, szkodliwych działań. Jego oceny przejmowania agentów wykorzystują symulowane środowiska pracy, usługi turystyczne, systemy komunikacyjne i narzędzia bankowe.

Środowiska te pokazują, dlaczego bezpieczeństwo agentów różni się od bezpieczeństwa chatbotów. Model nie tylko odpowiada na pytanie. Wybiera działania w ramach przepływu pracy, który wiąże się z uprawnieniami i rzeczywistymi konsekwencjami.

To nowe ujęcie wyostrza także raportowanie podatności. „Prompt injection” opisuje sposób, w jaki wpływ dostał się do systemu. Użyteczne ustalenie dotyczące bezpieczeństwa powinno również wskazywać wynikający z tego wpływ, taki jak nieautoryzowany dostęp do danych czy niezatwierdzone wykonanie kodu.

Tradycyjne zespoły bezpieczeństwa już dokonują podobnych rozróżnień. Dane wejściowe kontrolowane przez użytkownika nie są automatycznie naruszeniem. Podatność pojawia się, gdy oprogramowanie przekazuje te dane do niebezpiecznego interpretera albo ufa im po przekroczeniu granicy bezpieczeństwa.

Modele językowe komplikują tę analogię, ponieważ instrukcje i dane dzielą elastyczną reprezentację. Nie istnieje uniwersalny odpowiednik parametryzowanego zapytania do bazy danych dla każdego zadania języka naturalnego. To sprawia, że ograniczanie skutków wokół modelu jest jeszcze ważniejsze.

Kluczowe wydarzenie ma więc charakter koncepcyjny, ale znaczące skutki operacyjne. Prace nad bezpieczeństwem odchodzą od obietnic doskonałego filtrowania instrukcji. Zmierzają ku ograniczeniom, które pozostają skuteczne po podjęciu przez model błędnej decyzji.

Prompt injection jest wyzwalaczem, a nie promieniem rażenia

Wstrzyknięta instrukcja tworzy możliwość wpływu, natomiast framework decyduje, czy ten wpływ przerodzi się w incydent.

Rozważmy agenta, którego zadaniem jest przeglądanie przychodzących zgłoszeń do wsparcia. Potrzebuje on dostępu do treści zgłoszeń, danych klientów, a być może także wewnętrznej bazy wiedzy. Może również dysponować narzędziami do wystawiania zwrotów lub wysyłania wiadomości dotyczących kont.

Atakujący umieszcza ukrytą instrukcję w zgłoszeniu. Instrukcja nakazuje agentowi pobrać rekord innego klienta i dołączyć go do odpowiedzi. Model wykonuje to polecenie, sądząc, że realizuje przypisany mu przepływ pracy.

Zanim dane opuszczą firmę, musi dojść do kilku błędów. Agent musi otrzymać szerszy dostęp, niż wymaga tego bieżące zgłoszenie. Jego warstwa narzędzi musi zaakceptować parametry generowane przez model. Działanie wychodzące musi zostać wykonane bez niezależnej autoryzacji.

Złośliwy tekst rozpoczął ten łańcuch. Nie stworzył nadmiernych uprawnień, brakujących granic danych ani nieobecnej bramki zatwierdzania. Decyzje te wynikały z aplikacji i frameworka.

To rozróżnienie ma kluczowe znaczenie dla bezpieczeństwa agentów AI. System powinien zakładać, że osąd modelu jest zawodny, zwłaszcza gdy model przetwarza treści kontrolowane przez atakującego. Mechanizmy bezpieczeństwa muszą pozostawać poza tą pętlą decyzyjną.

Same schematy narzędzi nie rozwiązują problemu. Schemat może wymagać poprawnego adresu e-mail lub identyfikatora dokumentu. Nie jest jednak w stanie ustalić, czy model ma uzasadniony powód, aby skontaktować się z tym adresem lub pobrać ten dokument.

Dobrze sformułowane złośliwe działanie nadal pozostaje złośliwe. Framework potrzebuje egzekwowania polityk powiązanych z tożsamością użytkownika, własnością danych, zakresem zadania, pochodzeniem informacji i aktualnym stanem autoryzacji.

Pochodzenie oznacza rejestrowanie źródła informacji i zachowywanie tej etykiety przez cały przepływ pracy. Treść z nieznanej strony internetowej nie powinna uzyskiwać statusu zaufanej tylko dlatego, że jeden agent ją podsumował.

Zasada ta staje się trudniejsza do zastosowania w systemach wieloagentowych. Jeden model może badać temat, inny planować odpowiedź, a trzeci wykonywać działania przy użyciu narzędzi. Złośliwe instrukcje mogą być przekształcane, gdy dane wyjściowe przechodzą między nimi.

Agent odbierający może zobaczyć dopracowany tekst bez dostępu do niezaufanego źródła, które na niego wpłynęło. Jeśli framework odrzuca informacje o pochodzeniu, przepuszczenie instrukcji przez innego agenta może skutecznie zwiększyć jej uprawnienia.

Trwała pamięć tworzy kolejną ścieżkę. Atakujący może przekonać agenta, aby zapisał szkodliwą regułę, fałszywy fakt lub zmienioną preferencję. Późniejsze sesje mogą pobrać ten wpis, gdy pierwotna złośliwa treść już zniknęła.

Zespoły tworzące osobistą bazę wiedzy stają przed podobnym pytaniem o zaufanie. Pobrane informacje powinny zachowywać informacje o źródle i kontekście dostępu, szczególnie gdy agent może na ich podstawie działać.

Pamięć nie powinna stać się niewidoczną płaszczyzną sterowania. Operacje zapisu wymagają ograniczeń, zapisów audytowych i wyraźnego rozdzielenia preferencji zatwierdzonych przez użytkownika od obserwacji wygenerowanych przez model.

Przeglądanie sieci niesie własne ryzyko. Strona może zawierać widoczne instrukcje, ukryty tekst, metadane, treści obrazowe lub materiały adwersarialne zaprojektowane dla modelu, a nie dla człowieka. Agent przetwarza te treści, ponieważ przeglądanie sieci jest jego zamierzoną funkcją.

Google poinformowało o monitorowaniu publicznej sieci pod kątem znanych wzorców pośredniego wstrzyknięcia. Jego badania zagrożeń internetowych uznały te wzorce za priorytet, ponieważ agenci przeglądający sieć rutynowo konsumują strony kontrolowane przez atakujących.

Tworzy to strukturalny kompromis. Im szerszy staje się dostęp agenta do informacji, tym więcej niezaufanych treści napotka. Im większe otrzymuje uprawnienia, tym większy jest potencjalny wpływ jednej błędnej interpretacji.

Wyeliminowanie wszystkich treści zewnętrznych uczyniłoby wiele agentów bezużytecznymi. Przyznanie wszystkim treściom zewnętrznym równego wpływu czyni je niebezpiecznymi. Frameworki muszą zachować użyteczność, jednocześnie egzekwując granice, których sam język nie może zagwarantować.

Oznacza to rozdzielenie planowania od autoryzacji. Model może zaproponować działanie, wyjaśnić jego uzasadnienie i przygotować parametry. Deterministyczna usługa polityk powinna zdecydować, czy dane działanie jest dozwolone.

Decyzja powinna uwzględniać bieżącego użytkownika, żądane zadanie, zasób docelowy, wrażliwość danych i pochodzenie treści. Działania o dużym wpływie powinny wymagać potwierdzenia, które jasno pokazuje, co się wydarzy.

Potwierdzenie nie może być w całości napisane przez potencjalnie przejęty model. W przeciwnym razie atakujący może wpłynąć zarówno na proponowane działanie, jak i opis prezentowany użytkownikowi.

Godny zaufania interfejs powinien tworzyć krytyczne szczegóły na podstawie zweryfikowanych parametrów narzędzi. Powinien wskazywać odbiorcę, rekordy objęte działaniem, żądane uprawnienia oraz dane, które mają opuścić system.

W ten sposób promień rażenia staje się mierzalny. Nawet jeśli prompt injection powiedzie się na warstwie językowej, atakujący napotyka odrębne mechanizmy kontroli na każdej istotnej granicy.

Rezultat bardziej przypomina dojrzałe bezpieczeństwo aplikacji niż sprytną inżynierię promptów. Zasada najmniejszych uprawnień, izolacja, jawna autoryzacja, walidacja danych wyjściowych, rejestrowanie zdarzeń i reagowanie na incydenty pozostają niezbędne.

Dlaczego silniejsze prompty systemowe nie mogą stanowić granicy bezpieczeństwa

Wzmacnianie promptów zmniejsza liczbę skutecznych ataków, ale pozostałe przypadki niepowodzeń sprawiają, że nie nadaje się ono na ostateczną warstwę autoryzacji.

Prompty systemowe mogą nakazywać agentowi ignorowanie instrukcji znalezionych w treściach zewnętrznych. Mogą oznaczać materiał źródłowy jako niezaufany i przypominać modelowi, by realizował wyłącznie cel użytkownika.

Warto stosować te środki. Mogą blokować proste ataki, ograniczać przypadkowe odchylenia i zmuszać przeciwników do większego wysiłku. Pomagają też modelom wyjaśniać podejrzane treści zamiast natychmiast podejmować działania.

Badacze z Google przetestowali prompty bezpieczeństwa w wieloagentowym frameworku programistycznym. Ich badanie wieloagentowe objęło ponad 150 scenariuszy ataków jednokrotnej tury i 32 scenariusze wieloturowe.

Mechanizm wzmacniania bezpieczeństwa o długości około 500 tokenów obniżył wskaźnik niepowodzeń w pojedynczej turze z 19,48 procent do 2,60 procent. Wskaźnik niepowodzeń w wielu turach spadł z 75 procent do 46,88 procent.

Wyniki te przemawiają za wzmacnianiem promptów, ale jednocześnie ujawniają jego ograniczenia. Wskaźnik niepowodzeń na poziomie 46,88 procent w wielu turach nadal jest nieakceptowalny, gdy agent może wykonywać kod, uzyskiwać dostęp do poświadczeń lub modyfikować zasoby produkcyjne.

Nawet niższy wskaźnik dla pojedynczej tury tworzy istotne ryzyko na dużą skalę. Powtarzane interakcje dają przeciwnikom dodatkowe okazje, a atakujący mogą dostosowywać język po zaobserwowaniu zachowania modelu.

Badanie wykazało również, że skuteczne ataki przesunęły się w stronę funkcjonalnych opakowań. Ataki te ukrywają szkodliwy zamiar w zadaniach przypominających zwykłe funkcje agenta. Statyczne instrukcje mają trudność z ich odrzucaniem bez blokowania także legalnej pracy.

To jest zasadniczy problem z umieszczaniem granicy bezpieczeństwa wewnątrz modelu. Model musi interpretować otwarte żądanie, jednocześnie przewidując, czy narusza ono inną otwartą instrukcję.

Nie ocenia stabilnej reguły uprawnień tak, jak system operacyjny sprawdza dostęp do pliku. Tworzy probabilistyczną odpowiedź, na którą wpływa każdy istotny token w kontekście.

Wyjaśnianie prompt injection wyłącznie jako „ignorowania wcześniejszych instrukcji” pomija tę niejednoznaczność. Skuteczne ataki nie zawsze otwarcie sygnalizują konflikt. Mogą przedstawiać fałszywy kontekst, naśladować język zaufanego procesu pracy lub rozdzielać zamiar na kilka kroków.

Agent przeglądający kod może natrafić na tekst, który pozornie opisuje wymagany test. Test po cichu pobiera lub wykonuje zewnętrzny komponent. Każdy pojedynczy krok może wyglądać wiarygodnie w ramach procesu wytwarzania oprogramowania.

Agent przeglądający strony internetowe może otrzymać informację, że określone działanie jest konieczne, aby uzyskać dostęp do żądanej strony. Asystent biurowy może odczytać dokument twierdzący, że polityka firmy wymaga przekazania treści do weryfikacji zgodności.

Model nie ma niezależnej wiedzy o rzeczywistych politykach każdej organizacji. Jeśli framework pozwala, by twierdzenia wygenerowane przez model autoryzowały działania wygenerowane przez model, system staje się kolisty.

Filtry napotykają podobne ograniczenie. Detektor może wyszukiwać znane frazy albo oceniać, czy tekst wygląda na wrogi. Atakujący mogą parafrazować instrukcje, dzielić ładunki, ukrywać je w różnych formatach albo upodabniać je do zwykłych danych.

Blokowanie każdego zdania w trybie rozkazującym zniszczyłoby powszechne procesy pracy. Dokumenty, e-maile, komentarze w kodzie i zgłoszenia wsparcia w uzasadniony sposób zawierają instrukcje. Agent często musi je rozumieć, nie przyjmując ich jednak jako własnych celów.

Dostrajanie może poprawić odporność, ale nie usuwa konfliktu architektonicznego. Modele nadal muszą interpretować niezaufany język, a nowe wzorce ataków mogą znajdować się poza rozkładem danych treningowych.

Generowanie wspomagane wyszukiwaniem również nie usuwa tego konfliktu. RAG pobiera materiał zewnętrzny i dodaje go do kontekstu modelu. Jeśli źródło jest zatrute, wyszukiwanie może dostarczyć instrukcję atakującego dokładnie wtedy, gdy wydaje się ona istotna.

Aktualizacje modeli mogą nawet nieoczekiwanie zmienić ryzyko. Bardziej zdolny model może lepiej wykrywać ataki, ale może też skuteczniej używać narzędzi po powodzeniu ataku.

Dlatego wyniki benchmarków wymagają kontekstu. Model, który odrzuca większość wstrzyknięć w stałym zestawie testowym, nie dowodzi, że wdrożony agent jest bezpieczny. Rzeczywiste systemy zawierają niestandardowe narzędzia, uprawnienia, pamięć i integracje.

Celem obrony powinno być łagodne niepowodzenie. Gdy model błędnie klasyfikuje treść, otaczający go system powinien ograniczać skutki, ujawniać próbę i zachowywać dowody do przeglądu.

Agent działający tylko do odczytu nadal może wprowadzać użytkownika w błąd, dlatego jakość odpowiedzi ma znaczenie. Najpoważniejsze konsekwencje pojawiają się jednak zwykle wtedy, gdy frameworki łączą niepewne rozumowanie z nieograniczonymi uprawnieniami.

Prompty bezpieczeństwa powinny zatem należeć do wielowarstwowego projektu. Są jednym mechanizmem kontrolnym, a nie mechanizmem decydującym o tym, czy prywatne dane przekroczą granicę albo wykonywalny kod trafi na stację roboczą.

Bezpieczeństwo agentów AI zależy od możliwości, kontekstu i zgody

Frameworki powinny traktować model jako niezaufanego planistę, którego propozycje wymagają egzekwowalnej weryfikacji.

Pierwszą kontrolą architektoniczną jest minimalizacja możliwości. Agent powinien otrzymywać wyłącznie narzędzia potrzebne do bieżącego zadania, a nie każdą integrację dostępną użytkownikowi lub organizacji.

Podsumowujący kalendarz rzadko potrzebuje uprawnień do wysyłania poczty. Asystent badawczy nie potrzebuje automatycznie dostępu do powłoki. Recenzent kodu może potrzebować odczytu repozytorium bez uprawnień do scalania zmian.

Statyczna zasada najmniejszych uprawnień jest pomocna, ale lepsze są uprawnienia specyficzne dla zadania. Narzędzie może być dostępne dla jednej ograniczonej operacji i znikać po jej zakończeniu.

Poświadczenia powinny również pozostawać poza kontekstem modelu. Model powinien żądać operacji za pośrednictwem brokera, zamiast bezpośrednio obsługiwać sekrety wielokrotnego użycia. Logi powinny redagować wrażliwe tokeny w promptach i odpowiedziach narzędzi.

Drugą kontrolą jest autoryzacja kontekstowa. Tradycyjne kontrole dostępu często odpowiadają na pytanie, czy użytkownik może uzyskać dostęp do zasobu. Systemy agentowe muszą również pytać, czy dostęp ten wspiera bieżące żądanie użytkownika.

Użytkownik, który może odczytać dwa konta klientów, niekoniecznie upoważnił agenta do ich połączenia. Programista z dostępem do wdrożeń nie upoważnił każdego agenta do przeglądu kodu do wdrażania.

Nie da się perfekcyjnie wywnioskować intencji z języka, ale frameworki mogą ją zawężać poprzez jawne deklaracje zadań. Mogą wiązać narzędzia z zadeklarowanym celem, zbiorem zasobów, oknem czasowym i dozwolonym przepływem danych.

Trzecią kontrolą jest zgoda na działania niosące konsekwencje. Zatwierdzenie przez człowieka jest szczególnie ważne przed wysłaniem informacji na zewnątrz, wydaniem pieniędzy, zmianą dostępu, usunięciem danych lub wykonaniem niezaufanego kodu.

Zgoda musi mieć znaczenie. Powtarzające się, niejasne wyskakujące okna uczą użytkowników zatwierdzania bez sprawdzania. Interfejs powinien wskazywać dokładne działanie i podkreślać odstępstwa od pierwotnego zadania.

Działania niskiego ryzyka, które można odwrócić, mogą korzystać z lżejszych kontroli. Działania wysokiego ryzyka lub nieodwracalne wymagają silniejszego potwierdzenia, a w środowiskach korporacyjnych potencjalnie także drugiego zatwierdzającego.

Czwartą kontrolą jest izolacja. Wykonywanie kodu powinno odbywać się w piaskownicy z ograniczonym dostępem do sieci, systemu plików i poświadczeń. Sesje przeglądarki powinny oddzielać niezaufane strony od wrażliwego stanu aplikacji.

Dane wyjściowe narzędzi należy traktować jako dane, a nie automatycznie zaufane instrukcje. Frameworki powinny sprawdzać rozmiar, format, miejsce docelowe i dozwoloną zawartość danych wyjściowych przed zwróceniem ich modelowi.

Piątą kontrolą jest zachowanie pochodzenia. Każdy dokument, wiadomość, strona internetowa, element pamięci i odpowiedź agenta powinny zawierać informację o źródle i klasyfikację zaufania.

Gdy jeden agent streszcza niezaufaną stronę, streszczenie powinno pozostać niezaufane. Transformacja nie powinna usuwać ścieżki pochodzenia. Mechanizm polityk działający dalej w łańcuchu może wtedy zapobiec autoryzowaniu działań o dużym wpływie przez materiał o niskim poziomie zaufania.

Szóstą kontrolą jest rozdzielenie propozycji od wykonania. Planista może zdecydować, że należy wysłać e-mail, ale odrębny komponent powinien zweryfikować odbiorców i załączniki.

To rozdzielenie ogranicza ataki typu confused deputy. Confused deputy występuje, gdy system posiadający legalne uprawnienia zostaje zmanipulowany, by użyć ich w celu kogoś innego.

Siódmą kontrolą jest obserwowalność. Zespoły potrzebują zapisów pokazujących, które źródło wpłynęło na decyzję, który model zaproponował działanie, która polityka je dopuściła oraz które narzędzie je wykonało.

Bez takich zapisów organizacja nie może odtworzyć incydentu z udziałem agenta. Zwykłe logi aplikacji mogą rejestrować wywołania API, pomijając prompt, pobraną treść, stan pamięci i wiadomości między agentami.

Monitorowanie powinno również koncentrować się na zachowaniu. Sygnały ostrzegawcze obejmują nietypowe kombinacje zasobów, powtarzające się niepowodzenia autoryzacji, nowe zewnętrzne miejsca docelowe, nieoczekiwane zapisy w pamięci lub narzędzia używane poza ich normalną sekwencją.

Ósmą kontrolą są testy adversarialne obejmujące kompletne procesy pracy. Testowanie wyłącznie modelu bazowego ignoruje framework, w którym znajdują się uprawnienia i skutki uboczne.

Podejście NIST wykorzystuje realistyczne narzędzia i zadania, ponieważ bezpieczeństwo agentów zależy od kontekstu. Model może oprzeć się atakowi w zwykłym czacie, lecz zawieść, gdy ta sama instrukcja pojawi się wewnątrz wiarygodnie wyglądającego obiektu biznesowego.

Zespoły red team powinny umieszczać złośliwą treść w każdym źródle konsumowanym przez agenta. Obejmuje to strony internetowe, e-maile, dokumenty, repozytoria kodu, trackery zgłoszeń, metadane narzędzi, wyniki wyszukiwania i współdzieloną pamięć.

Powinny również testować ścieżki wieloturowe i wieloagentowe. Zablokowane bezpośrednie polecenie może odnieść sukces po przeformułowaniu przez pośredniczącego agenta lub zapisaniu do późniejszego pobrania.

Celem nie jest opublikowanie jednego wskaźnika powodzenia prompt injection. Chodzi o zidentyfikowanie, które udane wstrzyknięcia docierają do wrażliwych danych, uprzywilejowanych narzędzi lub nieodwracalnych operacji.

To wspiera lepsze ustalanie priorytetów. Częste wstrzyknięcie, które jedynie uszkadza tymczasowy szkic, zasługuje na uwagę. Rzadsze wstrzyknięcie, które dociera do poświadczeń produkcyjnych, wymaga w pierwszej kolejności silniejszych kontroli.

OWASP zaleca zasadę najmniejszych uprawnień, segregację treści zewnętrznych, zatwierdzanie przez człowieka, walidację danych wyjściowych i testy adversarialne. Środki te odzwierciedlają model obrony w głąb, a nie wiarę w jeden detektor.

Szersza taksonomia ataków NIST również podkreśla zarządzanie konsekwencjami obok identyfikowania ataków. Podejście to pasuje do systemów agentowych, ponieważ pełne zapobieganie pozostaje niepewne.

Żadna z tych kontroli nie czyni modelu godnym zaufania. Sprawiają one, że system jest mniej zależny od wiarygodności modelu, co jest bardziej obronnym celem inżynieryjnym.

Na co powinni zwrócić uwagę czytelnicy Google News

Rozstrzygające dowody będą wynikać z domyślnych ustawień frameworków, mierzalnego ograniczania skutków i przejrzystego raportowania incydentów.

Pierwszym sygnałem jest to, czy główne frameworki domyślnie stosują ograniczone wykonywanie. Opcjonalne piaskownice i kontrole uprawnień pomagają doświadczonym zespołom, ale to ustawienia domyślne kształtują tysiące zwykłych wdrożeń.

Warto obserwować, jak platformy agentowe obsługują przyznawanie narzędzi, dostęp do sieci, zapisy w systemie plików i poświadczenia wielokrotnego użycia. Framework, który najpierw udostępnia szerokie możliwości, a wzmacnianie opisuje później w dokumentacji, zachowuje podstawowe ryzyko.

Najsilniejszym ustawieniem domyślnym byłoby automatyczne nieprzyznawanie żadnego wrażliwego narzędzia. Programiści dodawaliby wąsko określone możliwości, jednocześnie widząc konsekwencje każdego uprawnienia.

Drugim sygnałem jest to, czy oceny mierzą wpływ od początku do końca. Wskaźniki odrzucania ataków są użyteczne, ale nie pokazują, czy skuteczny atak dotarł do poufnych danych lub wykonał niebezpieczne działanie.

Lepsze oceny będą raportować zarówno kompromitację modelu, jak i kompromitację systemu. Rozróżnią zmanipulowaną odpowiedź od nieautoryzowanego odczytu, transferu wychodzącego, wykonania kodu lub trwałej zmiany pamięci.

Powinny także publikować wyniki dla powtarzanych prób. Obrona, która odnosi sukces raz, ale zawodzi po kilku wariantach, oferuje ograniczoną ochronę w usłudze dostępnej z internetu.

Wyniki badań Google ilustrują tę potrzebę. Wzmacnianie promptów znacząco poprawiło odporność, lecz ataki wieloturowe zachowały wysoki wskaźnik niepowodzeń. Kontrole architektoniczne decydują o znaczeniu tych pozostałych niepowodzeń.

Trzecim sygnałem jest jakość ujawnianych informacji. Incydentom specyficznym dla AI często brakuje znanych artefaktów stosowanych w tradycyjnym zarządzaniu podatnościami. Zespoły mogą otrzymać wpis na blogu dostawcy bez standardowego identyfikatora, zakresu dotkniętych wersji ani jasnej ścieżki naprawy.

Dostawcy frameworków powinni publikować zalecenia bezpieczeństwa opisujące pełny łańcuch ataku. Użytkownicy muszą wiedzieć, jakie źródło treści jest wymagane, jak zachowuje się model, jakie uprawnienia i narzędzia są zaangażowane, które wersje są podatne oraz jakie środki zaradcze są dostępne.

Nie wystarczą ogólnikowe twierdzenia, że model otrzymał „dodatkowe zabezpieczenia”. Klienci muszą rozumieć, czy dostawca zmienił model, politykę frameworka, system uprawnień, sandbox czy proces zatwierdzania przez użytkownika.

Ten sam standard powinien obowiązywać przy decyzjach w programach bug bounty. Jeśli zgłoszenie demonstruje prompt injection, ale nie wywołuje istotnego skutku, niska ocena ważności może być uzasadniona. Jeśli jednak wstrzyknięcie prowadzi do uprzywilejowanego działania, uznanie go za oczekiwane zachowanie modelu omija rzeczywisty problem.

Google News będzie nadal promować demonstracje prompt injection, ponieważ są wyraziste i łatwe do odtworzenia. Część z nich będzie drobnymi jailbreakami, podczas gdy inne ujawnią poważne awarie frameworków.

Czytelnicy powinni rozdzielić trzy pytania. Czy atakujący wpłynął na model? Jaka możliwość stała się dostępna po tym wpływie? Która niezależna kontrola powinna była zatrzymać wynikające z tego działanie?

Taka sekwencja prowadzi do bardziej użytecznej oceny ryzyka niż pytanie, czy prompt injection zostało wreszcie rozwiązane. Obecne dowody nie dają podstaw, by zakładać istnienie uniwersalnego rozwiązania.

Deweloperzy powinni sprawdzić każdą ścieżkę między niezaufaną treścią a wrażliwymi narzędziami. Nabywcy korporacyjni powinni wymagać uprawnień ograniczonych do zakresu zadania, informacji o pochodzeniu danych, sandboxingu, mechanizmów zatwierdzania oraz audytowalnych rejestrów wykonania.

Pracownicy wiedzy powinni sprawdzać, do czego agent ma dostęp, zanim połączą z nim e-mail, pliki, kalendarze i systemy firmowe. Wygoda szybko rośnie, gdy te źródła są łączone, ale wraz z nią zwiększa się potencjalny zakres szkód.

Kluczowe odwrócenie pozostaje proste. Prompt injection jest wyzwalaczem, natomiast framework zapewnia zasięg, uprawnienia i trwałość. Traktowanie wyłącznie wyzwalacza pozostawia niezmienioną niebezpieczną maszynerię.

Gdy następnym razem nagłówek w Google News ogłosi kolejne przejęcie agenta, spójrz poza złośliwe słowa. Zapytaj, które narzędzie je wykonało, jakie uprawnienie na to pozwoliło i dlaczego nie zareagowała żadna odrębna kontrola.

To jest test, który twórcy agentów muszą teraz zdać. Czy system może pozostać bezpieczny po tym, jak jego model zostanie przekonany, zdezorientowany lub po prostu się pomyli? Jeśli odpowiedź zależy wyłącznie od lepszego promptowania, framework nadal zawiera błąd.