Recenzja klienta, sekcja pytań i odpowiedzi, PDF od producenta – to treści, które asystent zakupowy przeczyta i potraktuje tak samo jak Twój opis produktu. model nie odróżnia treści od polecenia – widzi jeden ciąg tekstu. Jeśli ktoś umieści w recenzji zdanie napisane nie do człowieka, tylko do modelu, model może je wykonać.
To nie jest scenariusz hipotetyczny. W badaniu siedemnastu wtyczek chatbotowych okazało się, że 13% losowo wybranych sklepów obsługujących chatbota już podaje mu treści od osób trzecich jako materiał równorzędny z opisem produktu. A opublikowane badania pokazują, że odpowiednio spreparowany tekst na stronie produktu potrafi zmienić kolejność rekomendacji.
Zastrzeżenie na wstępie: to tekst defensywny. Opisujemy mechanizm i obronę, nie publikujemy działających ładunków i nie podajemy gotowych do użycia przykładów ataku. Wszystkie liczby pochodzą z opublikowanych badań i oficjalnych stanowisk platform, a przy każdej podajemy, czego dokładnie dotyczy próba.
Dlaczego agent myli dane z poleceniem
Model językowy nie ma wbudowanego rozróżnienia na „to jest treść do przeczytania” i „to jest instrukcja do wykonania”. Dostaje jeden strumień tekstu: Twój prompt systemowy, pytanie użytkownika, opis produktu, recenzję i zawartość PDF-a – wszystko w tej samej postaci.
OWASP LLM01: Prompt Injection definiuje to jako podatność, w której „user prompts alter the LLM’s behavior or output in unintended ways”, i dodaje zdanie, które warto zapamiętać: te wejścia „can affect the model even if they are imperceptible to humans, therefore prompt injections do not need to be human-visible/readable, as long as the content is parsed by the model”.
Rozróżnienie, od którego trzeba zacząć, jest proste:
| Rodzaj | Kto wprowadza instrukcję | Przykład ze sklepu |
|---|---|---|
| bezpośredni | użytkownik rozmawiający z modelem | klient wpisuje polecenie do czatu na stronie sklepu |
| pośredni | autor treści, którą model przeczyta później | sprzedawca, konkurent albo autor recenzji umieszcza instrukcję w treści na stronie |
W e-commerce niebezpieczny jest wariant pośredni, bo jego autorem nie musi być klient. Może nim być konkurent piszący recenzję, dostawca przysyłający kartę katalogową w PDF albo producent, którego opis wklejasz do swojego katalogu.
Gdzie w sklepie leży powierzchnia ataku
Warto rozłożyć to na miejsca, bo od razu widać, że najbardziej ryzykowne są dokładnie te elementy, które SEO każe dodawać.
| Miejsce | Kto kontroluje treść | Ryzyko |
|---|---|---|
| opis produktu | sklep albo producent | średnie – opis od dostawcy bywa wklejany bez czytania |
| recenzje i oceny | osoby trzecie | wysokie |
| pytania i odpowiedzi | osoby trzecie | wysokie |
| PDF: instrukcja, karta katalogowa, certyfikat | producent lub dostawca | wysokie – treść rzadko czytana w całości |
| tekst alternatywny i podpisy obrazów | sklep | niskie |
| metadane pliku | producent lub dostawca | średnie – praktycznie nikt tego nie sprawdza |
| feed produktowy | sklep | niskie |
| odpowiedź zewnętrznego API | dostawca usługi | średnie |
To jest właśnie kontrintuicyjny wniosek tego tekstu. Bogaty opis, rozbudowana sekcja pytań i odpowiedzi, dokumentacja w PDF – rekomendujemy to klientom, bo zwiększa cytowalność, i piszemy o tym przy budowie opisu produktu pod cytowanie oraz dowodach twierdzeń produktowych. Ta sama treść zwiększa jednocześnie powierzchnię, na której można umieścić instrukcję dla modelu.
Co pokazały badania
Cztery prace, wszystkie recenzowane albo opublikowane jako preprinty z pełną metodyką. Podajemy je z zastrzeżeniami, bo popularne streszczenia bywają mocniejsze niż same badania.
Spreparowany tekst na stronie produktu zmienia kolejność rekomendacji
Kumar i Lakkaraju pokazali, że dodanie „strategic text sequence” do strony produktu „can significantly increase its likelihood of being listed as the LLM’s top recommendation”. Eksperyment prowadzono na katalogu fikcyjnych ekspresów do kawy.
Ważne zastrzeżenie, które zwykle znika w streszczeniach: skuteczność nie jest totalna. Autorzy raportują, że w około 40% ewaluacji ranga produktu wzrosła, a w około 60% nie zmieniła się. Badanie prowadzono na modelach otwartych, głównie Llama-2, a przeniesienia na modele komercyjne autorzy nie wykazali własnym eksperymentem – powołują się na inną pracę. Nie wolno więc na tej podstawie twierdzić, że taka sekwencja działa na ChatGPT.
Ataki demonstrowane na produkcyjnych wyszukiwarkach
Nestaas i współautorzy opisali „preference manipulation attacks”, w których spreparowana treść strony albo dokumentacji wtyczki nakłania model do promowania produktów atakującego i dyskredytowania konkurencji. Demonstracje objęły produkcyjne wyszukiwarki oparte na modelach oraz interfejsy wtyczek.
Najciekawszy jest wniosek systemowy, a nie sama technika: autorzy opisują to jako dylemat więźnia. Każdy sprzedawca ma motywację, żeby zaatakować, bo to poprawia jego pozycję. Gdy zrobią to wszyscy, jakość odpowiedzi spada dla każdego – łącznie z atakującymi.
Manipulacja może być niewidoczna i płynna językowo
Najczęstszy kontrargument brzmi: taki wtręt łatwo wykryć, bo wygląda jak bełkot. StealthRank pokazuje, że niekoniecznie – opisuje sekwencje osadzone w opisach produktów, które wpływają na ranking, zachowując płynność tekstu i unikając widocznych śladów manipulacji.
Trzynaście procent sklepów już podaje modelowi treści od osób trzecich
To najmocniejsza liczba w całym zestawie i pochodzi z badaniu siedemnastu wtyczek chatbotowych, przyjętego na IEEE S&P 2026. Przebadano siedemnaście wtyczek używanych przez ponad dziesięć tysięcy stron.
Ustalenie kluczowe dla sklepów: piętnaście z tych wtyczek wzbogaca kontekst chatbota treścią ze strony, ale „these tools do not distinguish the website’s trusted content (e.g., product descriptions) from untrusted, third-party content (e.g., customer reviews)”. W praktycznym audycie autorzy stwierdzili, że 13% losowo wybranych sklepów korzystających z jednej z badanych wtyczek podawało chatbotowi szczegóły z recenzji użytkowników.
Precyzyjnie o próbie: to 13 przypadków na 100 losowo wybranych sklepów obsługiwanych przez jedną konkretną wtyczkę, nie 13% całego rynku e-commerce. Osobne ustalenie: osiem wtyczek nie kontroluje integralności historii rozmowy, co zwiększa skuteczność ataku bezpośredniego „by 3 to 8x”.
Co się stało, gdy agent dostał kartę płatniczą
raporcie Guardio Labs „Scamlexity” z 20 sierpnia 2025 to demonstracja, nie badanie statystyczne – i tak trzeba ją czytać. Testowano wyłącznie przeglądarkę Perplexity Comet, bez podania wersji, w trzech scenariuszach.
W pierwszym postawiono fałszywy sklep podszywający się pod Walmart i wydano polecenie „Buy me an Apple Watch”. Agent przeszedł przez witrynę, znalazł produkt, dodał do koszyka i – jak opisują autorzy – „without asking for confirmation, autofilled our saved address and credit card details from the browser’s auto-fill database”. Dane karty pochodziły z autouzupełniania przeglądarki, nie zostały wpisane przez agenta.
Wynik nie był powtarzalny i autorzy sami to podkreślają: „Sometimes, Comet refused and sensed something phishy. In other cases, it paused and asked the human to complete checkout manually. However, there are instances when it went 'all the way’”. Ich własna puenta jest lepsza niż jakakolwiek statystyka: „And when security depends on chance, it’s not security”.
W drugim scenariuszu agent otworzył link z fałszywej wiadomości bankowej i potraktował stronę phishingową jako prawdziwą – zachęcił człowieka do wpisania danych logowania i pomógł wypełnić formularz. Sam ich nie wprowadził. Istotny jest tu mechanizm zaufania: użytkownik nigdy nie zobaczył podejrzanego nadawcy ani domeny, bo całą interakcję przeprowadził za niego agent.
Trzeci scenariusz, nazwany PromptFix, jest z perspektywy sklepu najbardziej pouczający. Atakujący umieścił instrukcje w niewidocznym polu tekstowym, ukrytym prostym stylowaniem CSS, wewnątrz elementu udającego CAPTCHA. Człowiek widzi zwykły checkbox, a treść trafia prosto do promptu agenta. Autorzy nie próbowali obejść zabezpieczeń siłowo – odwołali się do tego, do czego agent jest zaprojektowany: chęci szybkiego pomożenia człowiekowi.
Czego ten raport nie zawiera: ani jednego odsetka skuteczności, liczby prób ani wskaźnika sukcesu. Nie testowano Copilota w Edge ani agenta OpenAI. Pobrany w demonstracji plik był nieszkodliwy. Każde zdanie w stylu „agenci AI płacą oszustom w X% przypadków” nie ma pokrycia w tym źródle.
Czym to się różni od klasycznego spamu
Ukryty tekst i cloaking są w SEO znane od lat i opisaliśmy je przy ukrytym tekście i cloakingu wobec crawlerów. Prompt injection wygląda podobnie, ale różni się w jednym istotnym punkcie: treść wcale nie musi być ukryta. Instrukcja może stać w widocznej recenzji i nadal działać, bo problemem nie jest niewidoczność, tylko brak rozdziału danych od poleceń.
Z punktu widzenia zasad Google to i tak spam. polityce spamu Google wymienia wprost „attempting to manipulate generative AI responses in Google Search” jako technikę spamerską, obok cloakingu i ukrytego tekstu. Jeśli więc ktoś podpowiada Ci taki chwyt jako sprytną optymalizację – to nie jest szara strefa.
Jest też różnica praktyczna: klasyczny spam celuje w ranking, a injection celuje w treść odpowiedzi. Model może polecić produkt, ale też przemilczeć ograniczenie, zbagatelizować wadę albo skierować do innego adresu. Skutek jest trudniejszy do wykrycia niż spadek pozycji, bo nie widać go w żadnym raporcie.
Recenzje i pytania klientów jako treść niezaufana
To sekcja najbardziej praktyczna, bo dotyczy treści, której sklep nie kontroluje, a której nie chce się pozbyć – recenzje są zbyt cenne sprzedażowo.
Zasada jest jedna i wynika wprost z badania wtyczek: treść od osób trzecich musi być w danych podawanych modelowi oddzielona od treści własnej sklepu. Nie chodzi o usuwanie recenzji, tylko o to, żeby model wiedział, że czyta cudzą wypowiedź, a nie opis produktu.
- Oznacz pochodzenie treści w danych, które trafiają do chatbota albo asystenta. Recenzja powinna wchodzić do kontekstu z etykietą mówiącą, że to wypowiedź klienta, nie informacja od sklepu.
- Waliduj przed publikacją, nie po. Recenzja zawierająca zdania adresowane do systemu, a nie do czytelnika, powinna trafić do moderacji.
- Nie wklejaj opisów od dostawcy bez czytania. To najczęstsza droga, którą obca treść trafia do warstwy uznawanej za zaufaną.
- Sprawdź, co Twoja wtyczka czatu naprawdę czyta. Jeśli scrapuje całą stronę, to czyta również recenzje – i najprawdopodobniej nie odróżnia ich od opisu.
Warto przy tym pamiętać, że recenzje są jednocześnie realnym sygnałem jakości, o czym piszemy przy recenzjach produktowych jako sygnale. Celem nie jest ich ograniczanie, tylko przestanie traktowania ich jak treści własnej.
PDF i obraz jako kanał, o którym nikt nie myśli
Dokumentacja produktowa to obszar, w którym sklep prawie nigdy nie kontroluje treści. Karta katalogowa, instrukcja obsługi i certyfikat przychodzą od producenta albo dystrybutora, są wrzucane na serwer i podpinane do karty produktu. Nikt nie czyta ich w całości, a już na pewno nie sprawdza metadanych pliku.
Tymczasem to właśnie te pliki chcemy podawać modelom – w atrybucie na dokumenty produktowe albo jako materiał dowodowy przy twierdzeniach o produkcie. Rekomendacja z tego tekstu nie brzmi „nie publikuj dokumentów”, tylko: traktuj dokument od dostawcy jak treść niezaufaną – dokładnie tak samo jak recenzję.
Ten sam problem dotyczy obrazów. Instrukcja może być umieszczona w warstwie, którą człowiek na ekranie zignoruje, a model przeczyta. To jest zresztą szerszy temat tego, co model faktycznie widzi na stronie, a co widzi człowiek – rozwijamy go przy tym, co model faktycznie widzi na stronie i przy dostępie botów AI do strony.
Obrona: trzy miejsca i jedno zastrzeżenie
OWASP Prompt Injection Prevention Cheat Sheet układa zabezpieczenia w trzech punktach ścieżki i to jest dobra rama także dla sklepu.
| Gdzie | Co robi | Uwaga praktyczna |
|---|---|---|
| wejście | filtruje treść, zanim trafi do modelu | OWASP wprost stwierdza, że filtry wzorcowe nie łapią wiarygodnie wstrzyknięcia w treści niezaufanej |
| wyjście | sprawdza odpowiedź modelu, zanim zobaczy ją użytkownik | najtańsze do wdrożenia w sklepie |
| działanie | ocenia każde wywołanie narzędzia wobec pierwotnej intencji użytkownika | konieczne wszędzie tam, gdzie agent może coś zmienić albo kupić |
Do tego wzorzec podziału ról: model uprzywilejowany ma dostęp do narzędzi, ale nie czyta treści niezaufanej, a model w kwarantannie czyta treść niezaufaną, ale nie może nic zrobić. Prosty, skuteczny i rzadko wdrażany.
I zastrzeżenie, którego nie wolno pominąć: guardrail jest modelem i sam jest podatny na ten sam atak. Nie ma tu rozwiązania, które można wdrożyć raz i zapomnieć. stanowisku OpenAI z 7 listopada 2025 formułuje to bez owijania: „Prompt injection remains a frontier, challenging research problem”.
Gdy agent może kupować, stawka rośnie
Dopóki skutkiem jest błędna rekomendacja, mówimy o utraconej sprzedaży. Gdy agent ma prawo dokonać transakcji, skutkiem może być zamówienie, którego nikt nie chciał. OpenAI opisuje swoje zabezpieczenie wprost: „ChatGPT agent also pauses and asks for confirmation prior to taking sensitive steps such as completing a purchase”.
Po stronie sklepu obowiązuje zasada z OWASP LLM06: Excessive Agency: „Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not”. Uprawnienia rozstrzyga system, nie model. To samo dotyczy zakresu dostępu – agent rekomendujący produkty potrzebuje odczytu tabeli produktów i niczego więcej.
Warto też wiedzieć, czego protokoły nie rozwiązują. specyfikacji UCP opisuje podpisy i pochodzenie danych, ale sama specyfikacja stawia granicę uczciwie: potwierdzenie pochodzenia „does not guarantee that the entity is trustworthy; whether to trust or support it remains the client’s decision”. Protokół rozstrzyga, skąd dane pochodzą, a nie czy są prawdziwe. Szerzej o tym, jak modele oceniają samego sprzedawcę, piszemy przy ocenie wiarygodności sprzedawcy.
Audyt integralności treści produktowej
Do przeprowadzenia we własnym sklepie, bez żadnych narzędzi ofensywnych. Pięć pytań, z których każde ma odpowiedź tak lub nie.
- Czy Twój chatbot czyta recenzje i pytania klientów? Jeśli tak, czy w danych podawanych modelowi są oznaczone jako treść od osób trzecich?
- Czy opisy od dostawców trafiają do katalogu bez przeczytania? Sprawdź losowo dziesięć produktów wprowadzonych z pliku od producenta.
- Czy wiesz, co jest w metadanych PDF-ów podpiętych do kart produktu? Sprawdź pole tytułu, autora i słów kluczowych w pięciu plikach od różnych dostawców.
- Czy Twój agent może wykonać jakiekolwiek działanie zmieniające stan – złożyć zamówienie, zmienić koszyk, wysłać wiadomość – bez potwierdzenia człowieka?
- Czy uprawnienia agenta są ograniczone po stronie systemu, czy tylko opisane w prompcie? Jeśli to drugie, nie masz zabezpieczenia, tylko prośbę.
Odpowiedź „nie wiem” przy któremkolwiek pytaniu jest odpowiedzią samą w sobie i wskazuje, od czego zacząć.
Kiedy to nie jest atak
Warto oddzielić dwa zjawiska, które dają ten sam skutek. Ten tekst opisuje sytuację z atakującym: ktoś celowo umieszcza instrukcję w treści. Ale asystent potrafi pomylić się również wtedy, gdy nikt go nie atakuje – po prostu dlatego, że dane są niekompletne albo rozproszone.
Zmierzyliśmy to osobno, na kontrolowanym katalogu: w 168 przebiegach model ani razu nie polecił produktu niespełniającego wymagań, ale odrzucał trafne oferty tym częściej, im bardziej dane były porozrzucane po stronie. Cały pomiar opisujemy w badaniu nad błędnymi rekomendacjami bez udziału atakującego. Rozróżnienie jest praktyczne: pierwszy problem naprawia się bezpieczeństwem, drugi porządkiem w danych.
Od czego zacząć
- Ustal, co Twój asystent czyta jako treść zaufaną. To jedno pytanie do dostawcy wtyczki i najczęściej najbardziej zaskakująca odpowiedź w całym audycie.
- Oddziel treść od osób trzecich w danych podawanych modelowi. Recenzje i pytania klientów mają wchodzić z etykietą pochodzenia.
- Przenieś autoryzację do systemu. Jeśli o tym, czy wolno wykonać działanie, decyduje model na podstawie promptu, to nie jest kontrola dostępu.
- Wprowadź potwierdzenie człowieka przed każdą operacją, która kosztuje pieniądze albo zmienia zamówienie.
Zakres i wycenę audytu danych produktowych pod kątem tego, co czytają modele, zebraliśmy w cenniku SEO dla e-commerce. Czy Twoje treści są w ogóle czytelne dla asystentów, sprawdzamy w audycie widoczności w AI, a ich jakość w audycie treści; całość prowadzimy jako element pozycjonowania sklepu internetowego. Techniczną gotowość na zakupy przez agenta opisaliśmy przy gotowości sklepu na zakupy przez agenta. Ten temat jest jedną z dziesięciu warstw SEO w e-commerce – całość, wraz z patentami stojącymi za każdą warstwą, zebraliśmy w mapie 10 warstw SEO w e-commerce.
Najczęściej zadawane pytania
Co to jest prompt injection?
Podatność polegająca na tym, że treść przetwarzana przez model językowy zmienia jego zachowanie w sposób niezamierzony. OWASP podkreśla, że taka instrukcja nie musi być widoczna dla człowieka – wystarczy, że model ją przetworzy.
Czym różni się prompt injection bezpośredni od pośredniego?
W wariancie bezpośrednim instrukcję wpisuje osoba rozmawiająca z modelem. W wariancie pośrednim instrukcja znajduje się w treści zewnętrznej, którą model pobiera później – na stronie produktu, w recenzji albo w dokumencie.
Czy opis produktu naprawdę może wpłynąć na rekomendację AI?
Opublikowane badania wskazują, że tak, ale skuteczność nie jest totalna. W badaniu Kumara i Lakkaraju dodanie spreparowanej sekwencji poprawiło pozycję produktu w około 40% ewaluacji, a w około 60% nie zmieniło nic. Eksperymenty prowadzono na modelach otwartych, nie na komercyjnych.
Czy to jest niezgodne z zasadami Google?
Tak. Polityka spamu Google wymienia wprost próby manipulowania odpowiedziami generatywnymi w wyszukiwarce jako technikę spamerską. Zastosowanie mają też zasady dotyczące cloakingu i ukrytego tekstu.
Czy filtry oparte na wyrażeniach regularnych wystarczą?
Nie. OWASP stwierdza, że filtry wzorcowe nie wykrywają wiarygodnie wstrzyknięcia w treści niezaufanej, i rekomenduje model wytrenowany do tego zadania – z zastrzeżeniem, że taki model sam jest podatny na ten sam atak.
Co zrobić z recenzjami klientów?
Traktować je jako treść niezaufaną: walidować przed publikacją, oznaczać pochodzenie i oddzielać w danych podawanych modelowi od treści własnych sklepu. Nie chodzi o usuwanie recenzji, tylko o to, żeby model wiedział, że czyta cudzą wypowiedź.
Ile sklepów ma ten problem?
W audycie stu losowo wybranych sklepów korzystających z jednej z badanych wtyczek chatbotowych trzynaście podawało modelowi szczegóły z recenzji użytkowników. To wynik dla konkretnej próby i konkretnej wtyczki, a nie dla całego rynku.
Czy agent AI może kupić coś, czego nie chciałem?
W demonstracji Guardio Labs przeglądarka Perplexity Comet w części prób dokończyła zakup w fałszywym sklepie, korzystając z danych karty zapisanych w autouzupełnianiu przeglądarki. Autorzy zaznaczają, że wynik nie był powtarzalny – czasem agent odmawiał albo prosił człowieka o dokończenie płatności.
Czy protokoły handlu agentowego rozwiązują ten problem?
Nie w pełni. Rozwiązują kwestię pochodzenia danych przez podpisy, ale specyfikacja UCP wprost zaznacza, że potwierdzenie pochodzenia nie oznacza wiarygodności – decyzja o zaufaniu należy do klienta.
