Prompt injection bez AI? Co łączy Contagious Interview i ataki na agentów AI
Na pierwszy rzut oka te światy wydają się odległe.
Z jednej strony masz kampanię Contagious Interview opisaną przez Microsoft: fałszywy rekruter, zadanie techniczne, repozytorium, pakiet NPM, workflow Visual Studio Code i malware uruchamiany przez developera.
Z drugiej strony masz prompt injection w systemach AI: model albo agent dostaje zewnętrzną treść, traktuje ją jak część kontekstu zadania i wykonuje coś, czego nie powinien.
Technicznie to nie jest to samo. W jednym przypadku wykonawcą jest człowiek. W drugim model.
A jednak im dłużej się temu przyglądać, tym bardziej widać że oba scenariusze mają wspólny rdzeń. Bo w obu przypadkach nie chodzi przede wszystkim o złośliwy plik czy złośliwy prompt. Chodzi o to że wykonawca ufa kontekstowi bardziej niż weryfikuje intencję.
I właśnie dlatego Contagious Interview można czytać jak coś w rodzaju prompt injection bez AI.
Dlaczego to porównanie w ogóle ma sens
Żeby nie pójść za szybko w metafory, warto powiedzieć to precyzyjnie. Nie chodzi o to że developer i model AI są tym samym. Nie chodzi też o to że kampania malware "działa jak LLM". Chodzi o wzór.
W obu przypadkach masz wiarygodny kontekst, wykonawcę działającego zgodnie ze swoją rolą i treść wyglądającą na część normalnego procesu — a skutkiem jest uruchomienie działań których wykonawca nie rozpoznał jako szkodliwych.
To jest właśnie wspólne.
Contagious Interview: człowiek jako wykonawca
Microsoft opisał Contagious Interview jako kampanię w której napastnicy podszywają się pod rekruterów i prowadzą ofiarę przez pozornie normalny proces rekrutacyjny. Developer dostaje kontakt od "rekrutera", zadanie, repozytorium. Klonuje kod, ufa autorowi w VS Code, uruchamia projekt. W nowszych wariantach kampanii Visual Studio Code pyta o zaufanie do autora — a po jego przyznaniu task configuration pobiera i uruchamia backdoora.
Ofiara nie robi nic irracjonalnego. Robi dokładnie to co zawsze — test rekrutacyjny, klonowanie repo, standardowe uruchomienie projektu. Skuteczność ataku bierze się stąd że developer nie zostaje zmuszony do wykonania obcego działania. Zostaje przekonany że obce działanie jest częścią jego własnej pracy.
To jest kluczowe.
Prompt injection: model jako wykonawca
W prompt injection problem wygląda inaczej, ale logika jest zaskakująco podobna.
Agent dostaje treść z zewnątrz — stronę, dokument, komentarz, fragment HTML, instrukcję w repozytorium, dane wejściowe z narzędzia. Jeśli system nie oddziela wystarczająco wyraźnie zaufanych instrukcji od treści zewnętrznej i komend wykonawczych, może potraktować część danych wejściowych jak prawidłową instrukcję działania.
Czyli dokładnie jak developer w Contagious Interview — nie rozpoznaje w porę że coś wyglądające jak część zadania jest w rzeczywistości próbą sterowania wykonaniem.
To jest właśnie moment w którym porównanie przestaje być publicystycznym chwytem a zaczyna być użyteczną ramą analityczną. W obu przypadkach masz wykonawcę który działa zgodnie z przypisaną mu rolą, interpretuje kontekst jako zaufany i sam uruchamia szkodliwy łańcuch działań.
Wspólny rdzeń: zanik granicy między analizą a wykonaniem
To chyba najważniejsza część całego porównania.
W zdrowym modelu bezpieczeństwa wykonawca powinien umieć oddzielić to co analizuje od tego co wykonuje. Powinien wiedzieć: "to jest treść którą mam ocenić" — a nie: "to jest polecenie które mam wykonać".
W prompt injection właśnie ta granica zaczyna się rozmywać. Model nie widzi już wystarczająco wyraźnie różnicy między danymi wejściowymi a instrukcją sterującą.
W Contagious Interview dzieje się to samo, tylko po ludzku. Developer nie oddziela już wystarczająco wyraźnie zadania rekrutacyjnego od obcego repozytorium i realnego uruchomienia kodu pochodzącego od atakującego.
Czyli w obu przypadkach znika granica między "to co mam obejrzeć" a "to co właśnie uruchamiam". To nie jest drobiazg. To jest centrum całego problemu.
Zewnętrzna treść zaczyna sterować zachowaniem wykonawcy
W klasycznym modelu bezpieczeństwa zagrożenie często kojarzyło się z obiektem — plikiem, exploitem, payloadem, złośliwym linkiem. W nowym modelu coraz częściej ważniejszy staje się kontekst wykonania.
W Contagious Interview zewnętrzna treść ma postać rozmowy z rekruterem, opisu zadania, repozytorium i instrukcji uruchomienia. W prompt injection ma postać dokumentu, strony, wiadomości, komentarza, fragmentu HTML, osadzonej instrukcji. Ale efekt jest bardzo podobny — zewnętrzna treść zaczyna sterować zachowaniem wykonawcy bo zostaje błędnie uznana za część prawidłowego kontekstu działania.
To jest dużo ciekawsze niż samo pytanie "czy to malware" albo "czy to prompt".
Narzędzia nie są problemem. Problemem jest niekontrolowane zaufanie
W Contagious Interview problemem nie jest samo GitHub, NPM, VS Code ani nawet sam proces rekrutacji. Problemem jest to że narzędzia pracy uruchamiają działania wewnątrz kontekstu któremu użytkownik przyznał zaufanie zbyt szybko albo bez odpowiedniej separacji.
W prompt injection problemem nie jest sam LLM, agent, przeglądarka, konektor czy narzędzie z funkcją działania. Problemem jest to że system potrafi wykonać działania na podstawie treści której nie powinien traktować jak instrukcji.
Czyli znowu — nie narzędzie samo w sobie, tylko niekontrolowane zaufanie do kontekstu.
Człowiek i agent jako dwa warianty tego samego problemu
W Contagious Interview wykonawcą jest człowiek. W prompt injection wykonawcą jest agent. Ale w obu przypadkach kontekst jest podstawiony, wykonawca działa zgodnie z rolą, narzędzia są legalne, a szkoda pojawia się dlatego że proces wykonania nie został wystarczająco odseparowany od zewnętrznej treści.
Można to ująć jeszcze prościej: Contagious Interview przypomina prompt injection, tylko że wykonawcą nie jest model AI, ale developer pracujący w swoim naturalnym środowisku. To nie jest identyczny mechanizm techniczny. Ale to jest bardzo podobny mechanizm poznawczy i operacyjny.
Kiedy wykonawcą jest agent, a nie developer
Wyobraź sobie agenta AI z dostępem do skrzynki mailowej, narzędzi developerskich i uprawnień do uruchamiania kodu. Dostaje wiadomość od "rekrutera" z prośbą o przejrzenie repozytorium i uruchomienie zadania technicznego. Z perspektywy agenta — normalny email, normalne repozytorium, normalne środowisko. Żadnego sygnału ostrzegawczego. Żadnej chwili zawahania.
I właśnie tutaj Contagious Interview i prompt injection przestają być metaforą. Stają się dosłownie tym samym atakiem skierowanym na innego wykonawcę.
Różnica jest jedna — i jest niepokojąca. Developer może poczuć że coś jest nie tak. Może zatrzymać się przed kliknięciem "Ufam autorowi". Może zapytać kolegi. Agent nie ma tej chwili wahania. Działa szybciej, w większej skali i bez intuicji która czasem mówi "coś tu nie gra".
Dlatego w świecie gdzie agenci AI dostają coraz więcej uprawnień i coraz więcej narzędzi — wzorzec z Contagious Interview nie jest ostrzeżeniem z przeszłości. Jest zapowiedzią tego jak będą wyglądać ataki na wykonawców którzy nigdy nie śpią, nigdy się nie nudzą i nigdy nie czują że pytanie przyszło o złej porze.
Dlaczego to porównanie jest ważne
Bo pokazuje coś większego niż jedną kampanię malware i jeden problem AI safety. Pokazuje że w nowoczesnych systemach coraz częściej najsłabszym punktem nie jest kliknięcie w zły plik, tylko proces interpretacji prowadzący do wykonania działania.
To dotyczy developera uruchamiającego zadanie rekrutacyjne, administratora ufającego "wsparciu" w Teams, użytkownika wykonującego instrukcję z fake CAPTCHA i agenta AI który przetwarza zewnętrzny dokument jak część własnych poleceń. Wszędzie powtarza się ten sam wzór — zaufany kontekst, legalne narzędzie, wykonawca działający zgodnie z rolą, szkodliwy wynik.
I właśnie dlatego bezpieczeństwo coraz mniej dotyczy wyłącznie obiektów, a coraz bardziej separacji kontekstu, kontroli wykonania, polityki zaufania i ograniczania tego co może zrobić wykonawca nawet jeśli uwierzy w złą historię.
Co z tego wynika dla security
Jeśli ten sam wzór działa zarówno na człowieka jak i na agenta, organizacje muszą przestać myśleć o bezpieczeństwie tylko kategoriami blokowania złośliwych plików, wykrywania malware i filtrowania linków. To nadal ważne, ale już niewystarczające.
Coraz ważniejsze staje się oddzielanie treści od poleceń, ograniczanie uprawnień wykonawcy, kontrola środowisk uruchomieniowych, sandboxing, zaufanie nadawane możliwie późno i rozumienie że legalny workflow też może być nośnikiem sterowania. To dotyczy zarówno środowisk developerskich i narzędzi administracyjnych jak i przyszłych agentów AI.
Podsumowanie
Contagious Interview i prompt injection nie są tym samym zjawiskiem. Ale pokazują ten sam wzór zagrożenia.
W jednym przypadku zewnętrzny kontekst steruje człowiekiem. W drugim steruje modelem. W jednym wykonawcą jest developer uruchamiający repozytorium. W drugim agent interpretujący dokument lub stronę.
W obu przypadkach szkoda pojawia się nie dlatego że wykonawca robi coś nienormalnego, ale dlatego że normalny proces pracy zostaje wykorzystany jako kanał sterowania.
I właśnie dlatego to porównanie jest tak cenne. Bo pokazuje że problem nie nazywa się wyłącznie malware, phishing ani prompt injection. Problem nazywa się raczej: wykonawca który ufa kontekstowi bardziej niż powinien.
