Wstrzykiwanie promptów i śmiertelna trójka: zabezpieczanie agentów AI
Iniekcja promptu i śmiertelna trójka: dlaczego agenci AI nie potrafią odróżnić twoich instrukcji od atakującego, jak działały ataki EchoLeak i GitHub MCP.
Źródła: Prompt Injection and Agent Security: The Unsolved Problem
W czerwcu 2025 roku badacze ujawnili wadę w Microsoft 365 Copilot i nazwali ją EchoLeak. Atak przebiegał w następujący sposób: ktoś wysyła do ciebie e-mail o normalnym wyglądzie. Nie otwierasz go, nie klikasz niczego ani nawet go nie czytasz. Copilot i tak go czyta, ponieważ analizuje całą twoją skrzynkę pocztową, aby odpowiedzieć na twoje pytania. W tym e-mailu ukryte są instrukcje nakazujące Copilotowi zbierać poufne dane z twoich innych dokumentów i potajemnie przesyłać je na zewnętrzny serwer za pomocą automatycznie ładowanego obrazu. Bez żadnych kliknięć, a ofiara nie robi nic złego. Agent wykonuje polecenia, tylko nie u właściwej osoby.
EchoLeak otrzymał identyfikator CVE (CVE-2025-32711), został naprawiony, ale przestał funkcjonować – był to pierwszy znany przypadek iniekcji promptów wykorzystanej do kradzieży rzeczywistych danych w produkcyjnym systemie AI. To nie będzie ostatni taki przypadek. W ciągu następnego roku ta sama klasa ataków pojawiła się w integracji MCP firmy GitHub, w rozwiązaniu Duo firmy GitLab, w funkcjach AI platformy Slack, w narzędziu NotebookLM firmy Google oraz we wszystkich uruchomionych przeglądarkach AI. Pod koniec 2025 roku kierownictwo ds. bezpieczeństwa firmy OpenAI publicznie stwierdziło, że problem iniekcji promptów może nigdy nie zostać w pełni rozwiązany w przypadku agentów przeglądarkowych, a Brytyjskie Narodowe Centrum Bezpieczeństwa Cybernetycznego zgodziło się z tym stanowiskiem.
Podstawowy fakt związany z bezpieczeństwem sztucznej inteligencji agentowej jest prosty, a my wciąż nie mamy na niego jednoznacznej odpowiedzi: model otrzymuje twoje instrukcje oraz instrukcje atakującego dokładnie tym samym kanałem i nie potrafi ich wiarygodnie odróżnić. Poniżej wyjaśniono, dlaczego tak jest, dlaczego to szkodzi agentom znacznie bardziej niż chatbotom oraz które metody obrony są skuteczne, w odróżnieniu od tych przedstawionych w prezentacjach dostawców.
Jeden kanał na wszystko
Najpierw musimy zrozumieć mechanizm, ponieważ błędna interpretacja go jest początkiem słabych wytycznych dotyczących bezpieczeństwa.
Model językowy otrzymuje jeden wyjście wejściowe: długi ciąg tokenów. Twoje polecenie systemowe jest jego częścią. Pytanie użytkownika to również tokeny. Podobnie jak strona internetowa, którą agent właśnie pobrał, e-mail, który przeczytał, wynik działania narzędzia, który otrzymał w odpowiedzi, zapisany w formacie PDF dokument oraz tekst opisowy obrazka. Wszystko to przychodzi jako jedna prosta sekwencja, a model przewiduje, co nastąpi dalej. Nic nie wskazuje na to, by niektóre tokeny były uważane za wiarygodne polecenia od operatora, a inne za niepewne dane do przeanalizowania. Simon Willison, który w 2022 roku wprowadził termin „iniekcja poleceń”, opisuje to w ten sposób: modele chętnie wykonują wszelkie polecenia, które do nich trafiają, niezależnie od tego, czy pochodzą one od operatora, czy z innego źródła.
To jest sedno sprawy i ma głębokie korzenie. Żadne ulepszenie modelu nie naprawi tego problemu, ponieważ słabość ta jest wbudowana w sam projekt. Te systemy zostały stworzone tak, by wykonywać instrukcje sformułowane prostym językiem. Następnie dajemy im tekst napisany prostym językiem, pozyskany z otwartego Internetu, i udajemy zaskoczenie, gdy włączone polecenia są realizowane. Iniekcja to po prostu wykonywanie instrukcji przez system, który służy niewłaściwemu „szefowi”.
Porównajmy iniekcję SQL, która dała nazwę temu atakowi. Istnieje skuteczne rozwiązanie problemu iniekcji SQL w postaci zapytań z parametrami, w których baza danych otrzymuje jednoznaczne polecenie, że ta część to komenda, a ta część to dane, które nigdy nie powinny być traktowane jako komenda. Trzy dekady bezpieczeństwa sieciowego zależą od wyznaczenia tej granicy wewnątrz maszyny. W przypadku modeli językowych wielkich modeli nikt nie wie, jak to zrobić – wszystko odbywa się w ramach tej samej ścieżki komunikacji, a kanał komend i kanał danych są jednym. Dlatego też powszechny refleks, polegający na poleceniu modelowi w promptzie systemowym, by ignorował instrukcje znajdujące się w treściach internetowych, nie działa. Korzystasz z zainfekowanego kanału, aby chronić zainfekowany kanał, a dobrze opracowana treść zawsze może przełamać ostrzeżenia w języku angielskim.
Dwa typy ataków są często mylone. W przypadku bezpośredniej iniekcji to sam użytkownik wpisuje coś wrogiego, na przykład żądanie ujawnienia komend systemowych. Jest to bliższe zjawisku jailbreak: osoba atakuje agenta, którego ma prawo używać. Natomiast iniekcja pośrednia stanowi zagrożenie dla samych agentów. Wrogie polecenie ukrywa się w materiałach zewnętrznych, które agent przetwarza podczas pracy – takich jak strona internetowa, e-mail, zaproszenie kalendarzowe, komentarz w kodzie lub issue na GitHubie. Atakujący nigdy nie kieruje się bezpośrednio do agenta; umieszcza pułapkę w treści, której oczekuje, że agent kiedyś przeczyta w imieniu ofiary, która mu ufa. Wszystkie powyższe incydenty należały do tego typu. Zagrożenie rośnie, ponieważ atakujący nie potrzebuje dostępu do ciebie, wystarczy mu pewien wpływ na to, na co skierujesz swojego agenta.
Śmiertelna trójka
Najbardziej przydatnym modelem myślowym w tym kontekście jest „lethal trifecta” Simona Willisona, który wyjaśnia, dlaczego niektóre agenty są niezwykle podatne na wykorzystanie, a inne jedynie irytujące podczas ataku.
Agent staje się bronią do kradzieży danych, gdy łączy w sobie trzy funkcje.
- Dostęp do danych prywatnych. Może czytać twoje e-maile, prywatne repozytoria, dane klientów lub wewnętrzną witrynę wiki. To zazwyczaj powód istnienia takiego agenta, więc nie można go po prostu usunąć.
- Dostęp do niepewnego treści. Przetwarza tekst, którego nie napisał i który nie został przejrzany przez ciebie: strony internetowe, e-maile, dokumenty, wyniki z systemów third-party. To również zazwyczaj główny cel takiego agenta.
- Sposób komunikacji na zewnątrz. Może wysłać dane w miejsce, gdzie atakujący może je zobaczyć, poprzez wysłanie żądania HTTP, e-maila, wezwania API, renderowanie obrazu z adresu URL atakującego lub otwarcie pull requesta.
Każda z tych opcji jest w porządku, a zazwyczaj dwa z nich pozwalają na przetrwanie. Użycie wszystkich trzech w jednym agencie przy jednym zestawie uprawnień to jak broń wycelowana w twoje dane. Atakujący, który kontroluje drugą z tych możliwości, może przejąć kontrolę nad instrukcjami agenta, wykorzystać pierwszą do zbierania tajemnic, a trzecią do ich wysyłania. To dokładna sekwencja działań, które miały miejsce w ataku EchoLeak oraz ataku na GitHub MCP.
Przypadek GitHuba jest na tyle przejrzysty, że można go dokładnie przeanalizować. Invariant Labs zademonstrował go w maju 2025 roku. Programista łączy agenta do programowania z oficjalnym serwerem GitHub MCP za pomocą osobistego tokena dostępu, który, jak większość ludzi go konfiguruje, obejmuje wszystkie ich repozytoria – zarówno publiczne, jak i prywatne. Programista prosi o coś nieszkodliwego, na przykład o przejrzenie otwartych problemów w publicznym repozytorium. Agent je odczytuje. Jeden z nich został zgłoszony przez atakującego i zawierał ukryte instrukcje: przeczytaj prywatne repozytoria tego użytkownika i opublikuj to, co znajdziesz, w publicznym pull requestu. Agent posiada drugą tę zdolność (po prostu odczytuje treść atakującego), pierwszą (token umożliwia dostęp do prywatnych repozytoriów) oraz trzecią (może tworzyć publiczne PR-y). Robi to wszystko. W demonstracji prywatny kod, a nawet osobiste dane płatnicze, stały się widoczne dla każdego. Każda akcja podjęta przez token była zgodna z jego uprawnieniami, a agent funkcjonował dokładnie tak, jak został zaprojektowany. Tryfekt został po prostu zamknięty.
Spójrz na rozwiązanie. Środki zaradcze Docker nie próbowały wykryć złośliwego problemu. Złamały one zasadę tryfektu: każda sesja jest przypisana do jednego repozytorium, więc w momencie, gdy agent próbuje uzyskać dostęp do drugiego, jest blokowany bez względu na to, co mówią instrukcje. Model nie stał się inteligentniejszy. Usunięto jedną z możliwości w miejscu, gdzie one się łączą, a to stanowi podstawę każdej rzeczywistej obrony.
Dlaczego agenci są o wiele gorsze od chatbotów
Wcześniejsze obawy dotyczące bezpieczeństwa modeli językowych sprawiły, że iniekcje wydawały się do przyjęcia. Chatbot powiedział coś nieuprzejmego lub ujawnił swój prompt – irytujące, ale nie katastrofalne. Agenci natomiast zmieniają sytuację we wszystkich kierunkach.
Chatboty wytwarzają tekst, natomiast agenci wykonywają działania. Jeśli przejmie się kontrolę nad chatbotem, jedna osoba otrzymuje inne odpowiedzi. Gdy przejmie się kontrolę nad agentem, sam element ten zachowuje się inaczej, mając rzeczywisty wpływ: może wysyłać e-maile, przenosić środki finansowe, usuwać dane, łączyć kod lub uruchamiać polecenia w środowisku shell. Lista dziesięciu największych zagrożeń z projektu OWASP Agentic Security na rok 2026 przypomina dokładnie taką listę skutków: przejmowanie celów, niewłaściwe używanie narzędzi, nadużywanie uprawnień, zatruwanie pamięci oraz awarie występujące w systemach wieloagentowych. Każde z tych zagrożeń to w istocie zwykła iniekcja, wzmocniona przez powiązanie modelu z rzeczywistymi możliwościami.
Trzy czynniki potęgujące wyjaśniają stopień narażenia.
Powierzchnia ataku to wszystko, co agent odczytuje. W rzeczywistym agencie komenda operatora stanowi zaledwie niewielką część tokenów, a 70% lub więcej kontekstu to często wyniki narzędzi oraz pobrany treść. Taka nierównowaga również stanowi problem bezpieczeństwa. Większość informacji znajdujących się w „głowie” modelu podczas podejmowania decyzji pochodzi z zewnątrz, a każdy z tych tokenów może być instrukcją. Twoja zaufana komenda to zaledwie błąd zaokrąglenia wobec potoku niezaufanych danych wejściowych.
Autonomia eliminuje przeszkody spowodowane wolnością działania człowieka. Wartość agenta wynika z możliwości wykonywania pętli bez proszenia o zgodę na każdym kroku, ale każdy krok bez nadzoru oznacza, że instrukcja może zostać wykonaana bez żadnej możliwości jej zatrzymania. Im bardziej autonomiczny i imponujący jest agent, tym szerszy staje się ten okno możliwości. Zdolności agenta i możliwość wprowadzania do niego instrukcji rozwijają się razem, co oznacza, że przy innych równych warunkach im silniejszy agent, tym droższe jest jego utrata dla atakującego.
Wytrwałość i łączenie się w łańcuchy dodają kolejne problemy. Agenci mają pamięć, a ta może zostać zatruwana: atakujący umieszcza fałszywy „fakt” w długoterminowym przechowaniu w poniedziałek, co przez tygodnie wpływa na podejmowane decyzje. Agenci kontaktują się ze sobą, więc iniekcja do danych jednego z podagentów rozprzestrzenia się wzdłuż łańcucha, którego nikt nie monitoruje od początku do końca. A przeglądarki oparte na agentach, takie jak Atlas i Comet, umieszczają agenty podatne na iniekcje w kartach, w których jesteś zalogowany do swojego banku, skrzynki e-mail oraz konsoli administracyjnej firmy. Badacze już wcześniej oszukali Atlas, używając szkodliwego tekstu udawanego jako URL oraz treści, które wprowadzają fałszywe wspomnienia. Reakcja OpenAI zasługuje na uznanie za szczerość: wzmocniło produkt poprzez treningi przeciwwrogie i zautomatyzowane testy atakowe, a także jasno poinformowało użytkowników, że problem nie został w pełni rozwiązany.
Środki obronne, które pomagają
Szczerze mówiąc, nikt nie wie, jak sprawić, by model odpierał próby iniekcji w 100% przypadków. Każda z poniższych metod obronnych zmniejsza ryzyko, ale żadna go nie eliminuje. Prawdziwa ochrona polega na łączeniu niedoskonałych warstw oraz, przede wszystkim, na projektowaniu systemu w taki sposób, aby udana iniekcja nie mogła dotrzeć do niczego cennego. Oto rzetelne metody obronne, oddzielone od uspokajających iluzji.
Najpierw rozwiąż problem trifekty. Przynosi to większe korzyści niż cokolwiek innego i nie wymaga uczenia maszynowego. Dla każdego agenta sprawdź, czy posiada on jednocześnie wszystkie trzy umiejętności, a jeśli tak, to czy jedną z nich można pominąć w danym kontekście. Agent, który czyta niezaufane strony internetowe, nie powinien mieć również uprawnień do bazy danych produkcyjnej. Agent, który ma dostęp do danych prywatnych, powinien mieć komunikację z zewnątrz ograniczoną do listy dopuszczalnych adresów tak wąskiej, aby nie pozostało miejsce na wysyłanie tajemnic. Rozwiązanie z GitHubu polegające na jednym repozytorium na sesję stanowi rozwiązanie problemu trifekty. Działa ono skutecznie, ponieważ opiera się na aspekcie architektonicznym, a nie na zasadach probabilistycznych.
Wykorzystaj taką architekturę, która chroni system planowania przed zanieczyszczonymi danymi wejściowymi. Najbardziej obiecujące badania traktują problem iniekcji jako kwestię przepływu danych, a nie możliwości ich wykrycia. Model Dual LLM oraz jego bardziej rygorystyczna wersja CaMeL („Defeating Prompt Injections by Design”, 2025) dzielą agenta na dwie role. Model uprzywilejowany odczytuje Twoją prośbę i planuje kroki, ale nigdy nie ma dostępu do niezaufanych materiałów. Model w karantenie odczytuje te niezaufane materiały – e-maile lub strony internetowe – jednak nie posiada narzędzi i nie może podejmować żadnych działań. CaMeL idzie jeszcze dalej: plan modelu uprzywilejowanego jest przekształcany w program o ograniczonych uprawnieniach, a specjalny interpreter śledzi pochodzenie każdej wartości. Wszystko, co pochodzi z niezaufanego źródła, jest w ten sposób oznaczone i nie może doprowadzić do niebezpiecznego działania, chyba że tak stanowi określona polityka. To jest najbliższe zapytaniom parametryzowanym dla modeli językowych, granica pomiędzy poleceniem a danymi, która jest rzeczywiście egzekwowana. Jest to jednak kosztowne: ktoś musi napisać zasady, a niekończące się prośby o zatwierdzenie mogą nauczyć użytkowników klikania na „tak” odruchowo. Mimo to opiera się to na zasadach, a zasady wytrzymują pod naciskiem zdeterminowanego atakującego.
Ogranicz działania za pomocą drabiny uprawnień. Ustal rangę każdego działania według stopnia szkody, jaką może wyrządzić, i niech to narzędzie kontrolne, a nie prompt, egzekwuje tę rangę. Czytanie odbywa się w ciszy, wszystko, co da się odwrócić, jest rejestrowane, operacje trudne do odwrócenia (wysyłanie, usuwanie, płatności, łączenie) wymagają potwierdzenia człowieka pokazującego dokładnie, co ma się wydarzyć, natomiast operacje nieodwracalne i kosztowne są blokowane lub kierowane ścieżką zatwierdzenia, na którą model nie może wpłynąć. Prompt to sugestia, z którą atakujący może się spierać, natomiast reguła narzędzia kontrolnego to bariera, której nie może przełamać. Polecenie modelowi, aby zawsze pytał przed wysłaniem pieniędzy, ma sens, ale samo w sobie niewiele znaczy. Bezpieczeństwo zapewnia wymóg, by kod płatności wymagał tokena, którego model nigdy nie posiada.
Zastosuj zasadę najmniejszych uprawnień przy użyciu uprawnień ograniczonych zakresem. Iniekcje mogą wyrządzić szkodę tylko w takim stopniu, w jakim agent ma na to pozwolenie, dlatego przydziel każdemu agentowi jak najwęższy zakres działania, token o najkrótszym czasie ważności oraz jak najmniej narzędzi, które nadal umożliwią wykonanie zadania. Incydent na GitHubie wynikał z użycia tokena o szerokich uprawnieniach, który zachowywał się zgodnie z typowym zachowaniem takich tokenów, a ograniczenie uprawnień na poziomie poszczególnych repozytoriów za pomocą OAuth mogłoby temu zapobiec. To stara, nudna zasada higieny, ale jest skuteczniejsza od jakichkolwiek sprytnych rozwiązań.
Dodaj funkcję wykrywania, ale nie polegaj na niej. Zespoły najpierw wdrażają tę warstwę, a powinna być ostatnią. Klasyfikatory iniekcji to modele wyszkolone do rozpoznawania poleceń typu „zignoruj poprzednie instrukcje” oraz ich niezliczonych wariantów sformułowania, i faktycznie potrafią wykryć wiele ataków. W tym obszarze działają klasyfikatory do użytku komputerowego firmy Anthropic, filtr XPIA firmy Microsoft oraz wiele startupów. Korzystaj z nich, ponieważ sprawiają, że ataki są droższe w realizacji. Bądź jednak świadomy tego, co oferują. Klasyfikator blokujący 99% prób wydaje się doskonały, ale z punktu widzenia bezpieczeństwa jest to nieudane rozwiązanie, ponieważ iniekcje to nie losowy szum. Przeciwnik ma możliwość nieograniczonej liczby prób i może dostosować się do twojego filtru. Pierwszym krokiem w projekcie EchoLeak było wysłanie e-maila zaprojektowanego tak, by przejść przez klasyfikator iniekcji firmy Microsoft, i udało mu się to. Wobec atakującego, który potrafi się dostosować, wskaźnik wycieku na poziomie 1% stanowi poważną przeszkodę. Traktuj wykrywanie jako jedną z warstw, a nie jako podstawę twojej ochrony.
Zapisuj wszystko. Każde wezwanie narzędzia, pobraany dokument oraz podjęta akcja powinny być rejestrowane i możliwe do przypisania. Z punktu widzenia bezpieczeństwa stanowi to warstwę wykrywania i analizy śledczej. Później chcesz wiedzieć, co agent przeczytał tuż przed nieprawidłowym zachowaniem oraz skąd pochodziły instrukcje, a także chcesz otrzymywać alerty o anomalii, gdy nagle korzysta z zasobów w sposób wykraczający poza jego zwykły wzorzec. Nie możesz obronić się ani nawet zrozumieć ataku, którego nie widzisz. Agent, którego nie można zaobserwować, sprawia nie tylko trudności przy debugowaniu – to naruszenie bezpieczeństwa o którym dowiesz się od kogoś innego.
Trzy incydenty do zbadania
Wzorce utrzymują się, gdy są powiązane z rzeczywistymi wydarzeniami. Te trzy, pochodzące z okresu około osiemnastu miesięcy, pokazują różne aspekty tego problemu.
EchoLeak (Microsoft 365 Copilot, CVE-2025-32711). Najbardziej uderzająca jest brak konieczności jakiegokolwiek kliknięcia, a nie jakiś specjalny trik. Odkryto go w styczniu 2025 roku, naprawiono w maju, a informacje o nim ujawniono w czerwcu – była to pierwsza próba iniekcji poleceń, która pozwoliła pobrać rzeczywiste dane z produkcyjnego systemu sztucznej inteligencji bez żadnego działania ze strony użytkownika. Wykorzystano przy tym cztery metody obejścia: e-mail zaprojektowany tak, by przejść przez klasyfikator XPIA, linki w formacie Markdown, które omijały cenzurę linków, tag obrazu, który samodzielnie się ładował i wysyłał żądanie, oraz API Teams na liście białej, pełniące rolę przekaźnika, dzięki czemu dane mogły wyjść przez zatwierdzony kanał. Każda z metod kontroli dostępnej u Microsoftu była sama w sobie rozsądna. Atakujący natomiast znalazł luki pomiędzy nimi. Warstwy wykrywania to również warstwy luk, a cierpliwy przeciwnik bada je wszystkie.
Kradzież w ramach GitHub MCP (Invariant Labs, maj 2025 r.). Temat był już poruszany, ale warto to powtórzyć: nic nie zawiodło. Żadne dane uwierzytelniające nie zawiodły, a model pozostał nienaruszony. Słabością były szerokie uprawnienia tokena dostępu, agent czytający problemy napisane przez atakującego oraz możliwość otwierania publicznych PR – to wszystko razem stanowiło lukę bezpieczeństwa. Nie było kodu do wykorzystania ani błędu pamięci do naprawienia, jedynie trzy funkcje, które w ogóle nie powinny dzielić tej samej sesji. To właśnie sprawia, że bezpieczeństwo agentów to nowa dziedzina. Wada leży w sposobie łączenia się tych elementów, a nie w którymś z nich konkretnie.
Przeglądarki z agentami (Atlas i Comet, koniec 2025 roku). Gdy tylko ujawniono ChatGPT Atlas oraz Comet od Perplexity, badacze szybko zademonstrowali możliwości iniekcji do pola wyszukiwania, w których tekst udający adres internetowy był traktowany jako instrukcja, oraz ataki na pamięć powodujące pozostawianie fałszywego kontekstu między sesjami. To właśnie współlokalizacja sprawia, że ten przypadek jest szczególnie poważny. Agent podatny na iniekcje znajduje się w tym samym miejscu, gdzie jesteś zalogowany do swojego banku, skrzynki e-mail oraz konsoli administracyjnych – te trzy elementy są domyślnie umieszczane w najbardziej krytycznym miejscu. Reakcja OpenAI nadała branży uczciwy ton poprzez treningi adwersarialne, zautomatyzowane testy atakowe oraz otwarte przyznanie, że problem ten nie został rozwiązany. Trzeba wierzyć ich słowom i projektować tak, jakby agent przeglądarki w końcu mógł zostać oszukany.
Co oceniać, warstwa po warstwie
Myśl warstwowo i wybierz coś dla każdej z nich.
- Bariery oparte na wzorcach projektowych: CaMeL oraz wzorzec Dual LLM. Rozdzielają one planowanie od niezaufanych danych i śledzą pochodzenie, co zapewnia najwyższe gwarancje.
- Klasyfikatory iniekcji: klasyfikatory firmy Anthropic, Microsoft XPIA, Lakera Guard, PromptArmor oraz protectai/rebuff. Wykrywają one treści wrogie w niezaufanych danych, zwiększając koszty bez tworzenia pełnej bariery.
- Bramy i egzekwowanie zasad: intercepcje Docker MCP Gateway, Invariant Guardrails oraz listy dozwolonego ruchu wyjściowego. Przerywają one ten „trójakt” poprzez stosowanie zasad, ograniczając zakres sesji, blokując dostęp między zasobami i kontrolując ruch wychodzący.
- Narzędzia i testy typu red team: AgentDojo, AgentDyn, BIPIA, CyberSecEval oraz deepteam, które umożliwiają powtarzalne i mierzalne testy iniekcji.
Zasada, która chroni przed kłopotami: nie kupuj jednego produktu i nie uważaj się za chronionego. Każdy z wymienionych elementów stanowi odrębną warstwę, a kluczowe jest to, że żadna pojedyncza warstwa nie jest wystarczająca. Skuteczna strategia obejmuje obronę opartą na wzorcach projektowych, uprawnienia ograniczone do konkretnego zakresu, hierarchię uprawnień, klasyfikator oraz pełne śledzenie, tak dobrane, aby pokonanie jednej z tych barier nadal stawiało atakującego przed kolejną.
Warianty awarii w rzeczywistych warunkach
- Łańcuch wycieku danych. Niezaufany kontent nakazuje agencie zbieranie prywatnych danych i ich wysyłanie, jak w przypadku EchoLeak i GitHub MCP. Aby temu przeciwdziałać, należy zniszczyć ten łańcuch, używać list dopuszczalnych operacji wyjścia, śledzić przepływ danych (CaMeL) oraz ograniczać uprawnienia.
- Zdezorientowany „zastępca”. Wstrzyknięty kontent sprawia, że agent podejmuje działanie zmieniające stan, którego użytkownik wcale nie chciał, np. wysyła e-maila, usuwa plik lub zatwierdza transakcję. Należy temu zapobiec za pomocą systemu uprawnień, wymagając od osoby zatwierdzenia wszelkich istotnych działań, przy czym reguły te muszą być integralną częścią rozwiązania.
- Brak konieczności kliknięcia. Nie jest potrzebna żadna interakcja użytkownika, ponieważ wyzwalaczem jest zwykłe odczytywanie danych w tle przez agenta, podobnie jak w przypadku automatycznego ładowania obrazu w EchoLeak. Należy zablokować automatyczne pobieranie danych i ich renderowanie z zewnątrz, kontrolować operacje wyjścia oraz traktować wszystko, co jest pobierane pasywnie, jako potencjalnie niebezpieczne.
Jednoczesny przepustek bezpieczeństwa na tydzień
To proste, konkretne rozwiązanie, które można zastosować wobec agenta, który już posiadasz.
Dzień 1: zmapuj zestaw środków ochrony. Weź każdego agenta, którego używasz, i zanotuj, do jakich danych prywatnych może uzyskać dostęp, jakie treści niezaufane przetwarza oraz w jaki sposób może wysyłać informacje na zewnątrz. Każdy agent posiadający wszystkie trzy te funkcje trafia na czoło listy. Ten spis to najcenniejszy dokument bezpieczeństwa, jaki kiedykolwiek stworzysz, a wystarczy na to popołudnie.
Dzień 2: uszkodź przynajmniej jedną ze stron każdej trójki agentów. Dla każdego ryzykownego agenta usuń jedną z jego umiejętności w tym ustawieniu. Podziel go na dwa agenty o węższych zadaniach, zmniejsz jego uprawnienia lub ogranicz ruch wyjściowy do listy dozwolonych adresów. Nie zawsze da się usunąć wszystkich trzech, ale usunięcie choć jednego jest lepsze niż tygodnie ciągłego wzmacniania zabezpieczeń.
Dzień 3: stwórz drabinę uprawnień. Wymień wszystkie działania, które może wykonać agent, i uporządkuj je według stopnia intensywności – od tych niesłyszalnych, przez te rejestrowane, po te potwierdzone oraz zablokowane. W kodzie wdroż reguły dotyczące dwóch najwyższych poziomów, poza zasięgiem modelu, i upewnij się, że komunikaty potwierdzające pokazują to, co faktycznie się wydarzy.
Dzień 4: zaatakuj własnego agenta. Przygotuj dziesięć wrogich danych wejściowych, w tym stronę z pułapką, wiadomość, problem, zaproszenie, plik PDF z niewidocznym tekstem oraz obrazek, którego tekst opisowy zawiera polecenia. Uruchom agenta przeciwko każdemu z nich w środowisku sandbox i zobacz, co się stanie. Coś zadziała, a odkrycie tego samodzielnie jest lepsze niż gdyby to zrobił ktoś inny. Narzędzie takie jak AgentDojo umożliwia powtarzalne przeprowadzanie tego ćwiczenia.
Dzień 5: dodaj mechanizmy wykrywania i miej umiarkowane oczekiwania. Umieść klasyfikator iniekcji przed niezaufanymi danymi wejściowymi i zapisz to, co zostanie zauważone. Jest to alarm dymowy, który zwiększa koszty atakującego, a nie bariera. Wyślij jego wyniki do systemu śledzenia, który włączysz w dniu 6.
Dzień 6: włącz śledzenie w celach bezpieczeństwa. Upewnij się, że każde wezwanie narzędzia, pobranie danych oraz wykonana akcja są rejestrowane z jasno określonym właścicielem, a także ustaw alerty na dostęp do zasobów, który wykracza poza normalne wzorce. Jeśli śledzenie już istnieje, zmieniasz konfigurację, a nie rozpoczynasz nowego projektu.
Dzień 7: zapisz te informacje i ponownie przetestuj system po każdej zmianie. Odporność na iniekcje to nie etap, który należy przejść, lecz cecha, którą trzeba utrzymywać. Każde nowe narzędzie, źródło danych lub funkcja może ponownie doprowadzić do wystąpienia problemów, które wcześniej rozwiązano, dlatego dodaj do listy kontrolnej pytanie „Czy to ponownie powoduje te problemy?”, a także ponownie przeprowadź ataki z dnia czwartego, gdy odpowiedź może być twierdząca.
Brak schludnego zakończenia
Iniekcja poleceń nie została rozwiązana i być może nie da się jej rozwiązać w taki sam sposób jak iniekcję SQL, ponieważ właśnie ta cecha, która sprawia, że te modele są przydatne do wykonywania instrukcji w zwykłym języku, sprawia też, że można je wykorzystać do ataków, a nikt nie wie, jak zachować jedno bez drugiego. Twórcy nowoczesnych przeglądarek zaczęli to otwarcie mówić, co jest najbardziej obiecującym rozwojem w tej dziedzinie – branża przestała udawać, że inteligentniejszy model sprawi, iż problem zniknie.
Czekanie na naprawę to nie jest plan. Prawdziwym planem są agenci, którzy pozostają bezpieczni nawet po tym, jak model zostanie oszukany, ponieważ to kiedyś się wydarzy. To kieruje wysiłki inżynieryjne: zamiast na bardziej sprytny prompt systemu proszący o ostrożność, na strukturę otaczającą model. Należy złamać ten triumwirat – planować oddzielnie od niepewnych danych, ograniczyć każdą informację poufną, umieścić każdą istotną akcję za barierą, której model nie może obejść, oraz obserwować wszystko. Wszystko to znajduje się w systemie kontrolnym, a nic z tego nie w modelu.
Model jest zdolnym, ufającym elementem, który można podatki, a system kontrolny to sposób na bezpieczne jego wykorzystanie. Jeśli uczynisz z modelu swoją granicę bezpieczeństwa, dojdzie do naruszenia. Umieść granicę poza nim, pod swoją kontrolą, i będziesz miał szansę.
Literatura pokrewna
- DS-STAR wyjaśniony: agent nauki danych Google i powód, dla którego jego rozwiązanie odnosi sukcesy — Szczegółowy opis agenta nauki danych DS-STAR firmy Google: jego siedem modułów, pętla raportowania DS-STAR+, opublikowane instrukcje, wyniki testów ablacji oraz istniejące ograniczenia.
- Notatki praktyczne: Uruchamiam agenta programowania AI lokalnie i jego wydajność jest prawie dwukrotnie wyższa — Dokładny opis notatek praktycznych: Uruchamiam agenta programowania AI lokalnie i jego wydajność jest prawie dwukrotnie wyższa: kontrakty, sprawdzania oraz gotowe fragmenty kodu dostępne dla zespołów wdrażających ten model.