Prompt injection w nagłówkach HTTP: audyt agenta rekrutacji

Prompt injection w nagłówkach HTTP dociera do agenta rekrutacji wtedy, gdy narzędzie odczytujące adresy URL przekazuje modelowi metadane kontrolowane przez serwer. Audyt tej granicy wymaga sprawdzenia dokładnych wyników narzędzia dla poprawnych odpowiedzi, przekierowań i błędów. Zadbaj o rozpoznawalne pochodzenie materiału źródłowego, usuń zbędne metadane, a uprawnienia do odczytu danych kandydatów i zapisu sprawdzaj poza modelem.

Wyobraź sobie, że prosisz asystenta o porównanie portfolio kandydata z kartą oceny dla inżyniera backendu. Strona opisuje projekty, ale gdzieś w odpowiedzi jej serwer podaje też ocenę dopasowania kandydata. Zespół musi wiedzieć, czy ta deklaracja trafia do kontekstu asystenta, czy pojawia się w podsumowaniu i czy może zostać zapisana jako ocena.

To trzy osobne pytania. Zrzut ekranu przeglądarki nie odpowie na żadne z nich. Sprawdzić trzeba kontrakt między narzędziem pobierającym treść a modelem: które pola są przekazywane, skąd pochodzą i co dzieje się w razie błędu.

Co właściwie wykazało badanie nagłówków HTTP?

Badanie Signals Corps, opublikowane 6 października przez Sarah Andrews, objęło 217 097 223 odpowiedzi z Common Crawl. Próbę utworzono, wybierając co dziesiąty plik metadanych WAT. W klasyfikacji wskazano 7959 nazw hostów wysyłających nagłówki skierowane do AI, głównie odsyłacze do zasobów. W 30 przypadkach nagłówki zawierały próby wstrzyknięcia instrukcji, a w dwóch podano deklarowaną ocenę dopasowania kandydata. Zaobserwowano takie ciągi znaków; nie wykazano skutecznej ingerencji w rekrutację.

Do klasyfikacji użyto agenta badawczego Claude. CCBot nie widzi treści udostępnianych wyłącznie wybranym agentom. W osobnych eksperymentach ze znacznikami kontrolnymi testowane konfiguracje Claude domyślnie odrzucały instrukcje. Gdy jednak prompt przyznawał instrukcjom serwera prawo do sterowania odpowiedzią, żądane słowo kontrolne pojawiło się w siedmiu z dziewięciu prób.

Każdą parę model–prompt uruchomiono tylko raz, więc wynik nie określa ogólnej skuteczności ataku. Dyskusja na Hacker News zwróciła uwagę na badanie, ale komentarze nie potwierdzają dodatkowych ustaleń.

Komunikat Common Crawl o publikacji zbioru niezależnie potwierdza, że wykorzystany zbiór obejmował 2,17 miliarda stron z 40,4 miliona hostów, zebranych od 4 do 17 września. Potwierdza to skalę danych, nie klasyfikację nagłówków. Żadne z tych źródeł nie ustala, jak często ataki udają się w działających systemach rekrutacyjnych.

Nie dziel liczby oznaczonych nazw hostów przez liczbę odpowiedzi stron, żeby wyliczyć odsetek witryn. To różne jednostki. Nazwa hosta nie identyfikuje też kandydata, właściciela zarejestrowanej domeny ani klienta. Badanie wskazuje, co warto objąć audytem, ale nie daje podstaw do twierdzenia, że kandydaci na dużą skalę manipulują decyzjami rekrutacyjnymi.

Prześledź drogę odpowiedzi do modelu

Odpowiedź na żądanie URL zawiera status, nagłówki opisujące odpowiedź oraz treść strony lub dokumentu. To adapter decyduje, co otrzyma model. Sprawdź tę decyzję zarówno w wykonywanym kodzie, jak i w zarejestrowanych wynikach narzędzia.

Zacznij od jednego procesu używanego na produkcji. Zapisz nazwę narzędzia, wersję adaptera, dostawcę ekstrakcji treści, dostawcę zapasowego i dostępne później działania. Następnie pobierz stronę, którą kontrolujesz, i sprawdź wynik dokładnie w miejscu, w którym trafia do kontekstu modelu.

Podgląd odpowiedzi dostawcy na wcześniejszym etapie może nie ujawnić późniejszego formatowania, podsumowywania czy obsługi wyjątków.

Przydatny kontrakt wyjściowy określa dozwolone pola, ich typy, maksymalne długości i znaczenie. Rozróżnia też tekst wyodrębniony ze źródła od statusu wygenerowanego przez system. Na przykład tytuł źródła nadal jest deklaracją pochodzącą z zewnętrznej strony. Osobne pole JSON ułatwia ustalenie jego pochodzenia, ale nie nadaje mu wiarygodności.

Znajdź wszystkie sposoby odczytu tego samego adresu URL

Zwykłe narzędzie może zwracać wyodrębniony Markdown, narzędzie diagnostyczne szczegóły sieciowe, a mechanizm zapasowy fragmenty wybrane przez dostawcę wyszukiwania. Jeśli po błędzie agent może wybrać inne narzędzie do odczytu, tę ścieżkę również trzeba objąć audytem.

Sprawdź, co się dzieje, gdy źródło zwraca PDF, nietypowy typ treści, stronę z blokadą dostępu albo żądanie logowania. Jeśli odpowiedzi z pamięci podręcznej mają inny format niż odpowiedzi świeżo pobrane, przetestuj je osobno. Zapisz, czy przekierowanie zmienia wyświetlany adres źródła. Ten sam żądany URL może dostarczyć istotnie różny materiał w zależności od wybranej ścieżki.

Referencyjna implementacja narzędzia fetch MCP w wersji analizowanej w badaniu to konkretny przykład, na którym można przeanalizować ekstrakcję treści i obsługę błędów. Zanim opiszesz wynik swojego narzędzia, sprawdź dokładnie tę wersję, której używasz. Sama nazwa narzędzia nie dowodzi, jak ono działa.

Oddziel ekstrakcję treści od zaufania

Usunięcie surowych nagłówków ogranicza jedną drogę ataku. W treści strony nadal mogą znajdować się instrukcje, fałszywe twierdzenia lub nieistotne informacje. Nasz wcześniejszy artykuł o prompt injection w CV opisuje problem zawartości dokumentów; tutaj sprawdzamy mechanizmy pobierania, które je otaczają.

W instrukcjach agenta oznacz zewnętrzny tekst jako niezaufany materiał źródłowy i wyjaśnij, do czego wolno go użyć. Potem przetestuj tę granicę. Separatory, serializacja JSON i przypomnienia pomagają uporządkować kontekst, ale żadne z nich nie gwarantuje, że model zawsze odrzuci osadzone instrukcje.

Przetestuj poprawne odpowiedzi, przekierowania i błędy

Użyj fikcyjnych kandydatów i własnej infrastruktury, żeby osobno sprawdzić widoczność treści i jej wpływ na zachowanie. Sprawdź zarejestrowane dane wejściowe modelu, aby ustalić, czy każdy znacznik przeszedł przez granicę narzędzia. Wykonanie instrukcji oceniaj po żądanym zachowaniu: zacytowanie znacznika przy jednoczesnym odrzuceniu instrukcji nie oznacza jej wykonania.

Przygotuj fikcyjne portfolio z krótkim, niezmiennym opisem projektu. Umieść jeden unikalny znacznik w treści, a inny we własnym nagłówku odpowiedzi. Najpierw uruchom tę próbę bazową bez instrukcji, a następnie dwa osobne warianty: jeden z nieszkodliwą instrukcją we własnym nagłówku, drugi z tą samą instrukcją w treści. Poproś, by odpowiedzią asystenta był trzeci znacznik. Fakty o kandydacie powinny być identyczne we wszystkich wariantach, żeby dało się rozpoznać zmiany wywołane kanałem odpowiedzi.

Poniższa tabela to propozycja planu audytu, a nie wyniki testów przeprowadzonych na Kit lub u dostawcy.

Dla każdego przypadku zachowaj wynik oczekiwany i rzeczywisty. Udany test widoczności nagłówków powinien wskazywać, które pole pominięto. Udany test działania powinien wskazywać mechanizm systemu, który odmówił wykonania proponowanej operacji. Stwierdzenie „odpowiedź wyglądała dobrze” zbyt wiele pozostawia bez wyjaśnienia.

Ustal osobny kontrakt dla wyników błędów

Komunikaty błędów często powstają z myślą o programistach, a potem bez przeglądu trafiają do modeli. Wyjątek może zawierać odpowiedź dostawcy, komunikat systemu źródłowego albo docelowy URL. Starannie ograniczony wynik poprawnego pobrania niewiele mówi o tych polach.

Zwracaj kategorię błędu ze zdefiniowanego zbioru oraz kontekst wystarczający do ponownej próby, na którą użytkownik ma uprawnienia. Szczegółową diagnostykę kieruj do kanału operacyjnego z odpowiednio ograniczonym dostępem.

Jeśli model potrzebuje fragmentu błędu pochodzącego ze źródła, oznacz go jako materiał źródłowy i zastosuj te same limity co dla zwykłego wyodrębnionego tekstu.

Przetestuj zarówno pierwszy błąd, jak i mechanizm zapasowy. Główne narzędzie może na przykład pomijać nagłówki, podczas gdy drugie osadza cały zrzut diagnostyczny. Powtórz te testy po zmianie adaptera, dostawcy ekstrakcji lub sposobu formatowania wyjątków. Razem z wynikami zapisz odpowiednie wersje, żeby kolejna osoba wiedziała, co potwierdzają zebrane wyniki.

Odtwórz rzeczywiste żądania bez danych prawdziwych kandydatów

Kontrolowane przypadki sprawdzaj ze zwykłą konfiguracją żądań agenta. Jeśli narzędzie produkcyjne używa własnego nagłówka User-Agent albo żąda Markdown, odtwórz to w teście. Zwykła przeglądarka może otrzymać inną odpowiedź.

W teście ze znacznikami kontrolnymi nie umieszczaj prawdziwych CV, danych uwierzytelniających ani podpisanych linków kandydatów. Nie instaluj pakietów i nie łącz się z narzędziami wskazanymi w przypadku testowym. Sprawdzasz, czy system przekracza granicę uprawnień; nieszkodliwe, fikcyjne treści wystarczą, żeby ujawnić taki błąd.

Pobrana treść nie może nadawać uprawnień w rekrutacji

Portfolio może dostarczyć informacji o pracy kandydata. Nie może ustalać karty oceny, potwierdzać wyniku dopasowania ani przyznawać dostępu do danych innej osoby. To rozróżnienie musi pozostać czytelne zarówno w podsumowaniu, jak i w systemie, który je zapisuje.

W hipotetycznej ocenie inżyniera backendu asystent może znaleźć publiczne repozytorium opisujące proces obsługi kolejki. Poprawna notatka wskazuje źródło i określa, co ono potwierdza: portfolio opisuje pracę z przetwarzaniem kolejek, ale odpowiedzialność za ich działanie na produkcji pozostaje niezweryfikowana. Rekruter może wtedy zadać konkretne pytanie na rozmowie.

Wynik bez uzasadnienia nigdy nie powinien niezauważenie stać się oceną rekrutera. Każda istotna ocena wymaga uzasadnienia powiązanego z kryterium i materiałem, którego pochodzenie da się prześledzić. Deklaracje kandydata muszą pozostać odróżnialne od osądów recenzenta.

Osoba przeglądająca dane musi rozumieć tę różnicę w procesie pracy z profilami kandydatów.

Dotyczy to również sytuacji, w których instrukcja ze źródła nie uruchomi żadnego narzędzia. Nawet asystent z dostępem wyłącznie do odczytu może zawyżyć doświadczenie, pominąć wątpliwości albo przedstawić samoopis jako niezależne potwierdzenie. Audytuj więc rzetelność odpowiedzi obok operacji zapisu. Porównuj podsumowania dla różnych przypadków testowych i poproś recenzentów o wskazanie, które twierdzenia rzeczywiście wynikają ze źródeł.

Wytyczne OWASP dotyczące prompt injection zalecają kilka warstw zabezpieczeń: ograniczone uprawnienia, oddzielenie niezaufanych treści, zatwierdzanie istotnych działań przez człowieka oraz testy z próbami obejścia zabezpieczeń. Dobieraj je do skutków operacji. Szkic podsumowania i odrzucenie aplikacji wymagają różnych uprawnień.

Zachowaj pochodzenie informacji bez tworzenia archiwum danych wrażliwych

Zapisuj identyfikator narzędzia, żądany URL, końcowy URL, jeśli jest dostępny, kategorię odpowiedzi, nazwy udostępnionych pól i kolejne proponowane działanie. Dodaj czas ekstrakcji oraz informacje o wersjach wystarczające do odtworzenia zachowania adaptera. Jeśli nie da się ustalić końcowego adresu docelowego, wyraźnie odnotuj tę niepewność.

Zamiast pełnych zrzutów odpowiedzi wybieraj ograniczone, ustrukturyzowane zapisy i zanonimizowane przykłady z fikcyjnymi danymi. Zwykłe logi nie powinny zbierać ciasteczek, wartości nagłówków autoryzacji, podpisanych linków ani danych osobowych kandydatów. Zapis pochodzenia pomaga ustalić, skąd wzięło się twierdzenie; nadmierne logowanie tworzy kolejne miejsce wymagające ochrony materiałów zawierających dane wrażliwe.

Powiązanie ze źródłem musi przetrwać późniejsze podsumowania. Jeśli drugi model skraca notatki z analizy, zachowaj związek każdego twierdzenia z materiałem, który je uzasadnia. Inaczej ostrożne pierwsze podsumowanie może na dalszym etapie zmienić się w stanowcze stwierdzenie bez oparcia w źródłach.

Sprawdź kolejne działanie i konkretny przykład z Kit

System musi rozstrzygnąć, czy proponowane działanie jest dozwolone, na podstawie uprawnień uwierzytelnionego użytkownika, zakresu konta, odbiorcy i celu operacji. Tekst pobrany ze strony internetowej nie może rozszerzyć żadnego z tych uprawnień.

Link do serwera MCP może być przydatną dokumentacją. Połączenie z nim dodaje jednak nowe możliwości i wymaga osobnej autoryzacji. Strona prosząca agenta o wysłanie danych kandydata gdzie indziej przekazuje żądanie, a nie zgodę. Przed każdym przesłaniem sprawdź odbiorcę i zakres danych, nawet jeśli poprzedzające je podsumowanie wygląda rozsądnie.

Dostęp do narzędzi powinien odpowiadać zadaniu. Na etapie zbierania informacji może wystarczyć odczyt źródeł i zapis szkicu. Przeniesienie aplikacji, kontakt z kandydatem lub eksport danych wymagają osobnej decyzji o uprawnieniach. Dokumentacja narzędzi MCP w Kit pomaga wybrać integracje, ale sama dostępność przez MCP nie oznacza zgody na konkretną operację.

Adapter Outreach w Kit to przykład o ograniczonym zakresie

Statyczny przegląd kodu na potrzeby tego artykułu wskazał odpowiednią implementację w adapterze pobierania treści modułu Outreach w Kit. To przykład zbierania informacji o potencjalnych klientach, a nie dowód istnienia wdrożonej funkcji pobierania portfolio w Hiring ani test bezpieczeństwa całego procesu.

Adapter odczytuje zapisany adres źródłowy potencjalnego klienta i sprawdza, czy jest to bezpieczny publiczny URL. Może użyć zapisanych pól profilu lub spróbować ekstrakcji przez Cloudflare, a następnie Exa. Przy zwykłym pobraniu przez Cloudflare wynik widoczny dla modelu zawiera URL i wyodrębniony tekst zamiast surowej odpowiedzi HTTP. Gdy Exa odpowiada poprawnie, wynik zawiera URL, tytuł, wybrane fragmenty i tekst.

Dokumentacja endpointu Markdown Cloudflare opisuje ekstrakcję treści strony. Ta transformacja nie oznacza oczyszczenia z prompt injection. Wyodrębniony tekst nadal pochodzi od podmiotu zewnętrznego.

Przegląd statyczny wykazał też, że obsługa błędów Exa może dołączać komunikat wyjątku. Jego zawartość wymaga osobnego sprawdzenia.

Te obserwacje wskazują konkretny kolejny audyt: zarejestruj rzeczywiste wyniki dla poprawnych odpowiedzi dostawców, mechanizmu zapasowego, przekierowań i błędów, a następnie przetestuj dozwolone kolejne działania. Nie dowodzą one, że nagłówki są wykluczone w całym systemie ani że Kit jest odporny na wstrzykiwanie instrukcji.

Zanim rozszerzysz uprawnienia agenta we własnej integracji, przygotuj kontrakt pobierania, który da się sprawdzić. Obok adaptera przechowuj niewielki zestaw przypadków z fikcyjnymi danymi, zapisuj, co trafia do modelu, i weryfikuj, kto zezwala na kolejne działanie. Dzięki temu zespół rekrutujący będzie miał materiał do sprawdzenia, gdy źródło się zmieni, dostawca zawiedzie albo asystent zaproponuje działanie o istotnych skutkach.