Prompt Injection pri webových chatbotoch: Ochrana pre RAG, nástroje a dáta

Webový chatbot nespracováva len neškodné otázky. Návštevníci sa môžu pokúsiť prepísať jeho pravidlá, odhaliť interné pokyny alebo vyvolať neoprávnené akcie. Ešte ťažšie odhaliteľné sú príkazy, ktoré sa nenachádzajú priamo v chate, ale sú skryté na indexovanej webovej stránke, v nahranom dokumente alebo v pripojenom systéme tretej strany.

Ak chcete obmedziť Prompt Injection pri webových chatbotoch, nemôžete sa spoliehať len na obzvlášť prísne formulovaný systémový prompt. Potrebná je viacvrstvová architektúra: vstupy a zdroje sa považujú za nedôveryhodné, oprávnenia sú technicky obmedzené, výstupy sa pred ďalším spracovaním kontrolujú a rizikové akcie potvrdzuje deterministický kód alebo človek.

Čo znamená Prompt Injection pri webovom chatbotovi

OWASP popisuje Prompt Injection ako vstup, ktorý neúmyselne mení správanie alebo výstup jazykového modelu. Priama Prompt Injection pochádza priamo od používateľa, napríklad ako výzva na ignorovanie predchádzajúcich pravidiel. Nepriama Prompt Injection sa naopak skrýva v externom obsahu, ktorý systém neskôr načítava: na webových stránkach, vo vedomostných dokumentoch, e-mailoch, produktových dátach alebo súboroch.

Toto rozlíšenie je pre prevádzkovateľov webových stránok dôležité. Čisto odpovedací FAQ chatbot má menšiu plochu na útok než systém, ktorý priebežne prechádza webové stránky, prehľadáva interné dokumenty, číta dáta z CRM alebo dokáže spúšťať funkcie. Retrieval-Augmented Generation (skrátene RAG) síce zlepšuje odborný základ odpovedí, no riziko injection neodstraňuje. Aj dobre spravovaný súbor zdrojov môže obsahovať manipulatívne alebo nesprávne pochopené pokyny.

Hodnoťte riziko podľa funkcií, nie podľa názvu modelu

Kľúčová otázka neznie len: „Aký model používame?“, ale predovšetkým: „Aké následky môže mať manipulovaná odpoveď?“ Vytvorte si pre chatbota jednoduchú mapu funkcií a dát:

• Aké verejné a interné zdroje smie čítať?
• Aké osobné, dôverné alebo pre podnikanie kritické dáta sú dostupné?
• Dokáže len generovať text, alebo aj vytvárať tikety, leady, e-maily, termíny či objednávky?
• Aké akcie menia externe pripojené systémy?
• Aké rozhodnutia sa preberajú automaticky bez toho, aby ich skontroloval človek?

Čím väčšie sú práva na čítanie, zápis a stupeň automatizácie, tým dôležitejšie sú technické hranice mimo samotného modelu. Existujúci prehľad častých chýb pri AI chatbotoch pomôže pri všeobecnej inventúre. Pre ochranu pred Prompt Injection musíte navyše zdokumentovať dátové toky, hranice dôveryhodnosti a práva na vykonávanie akcií.

Jasne oddeľte štyri dôveryhodné zóny

Praktický bezpečnostný model rozlišuje štyri zóny, aj keď sú technicky spracovávané v tej istej aplikácii.

Zóna 1: Systémové pravidlá a smernice

Sem patrí rola, povolený účel, hranice odpovedí a pravidlá eskalácie. Tieto pravidlá dávajú modelu smerovanie, no nepredstavujú spoľahlivú kontrolu prístupu. OWASP výslovne varuje pred tým, aby sa systémové prompty považovali za tajomstvo alebo bezpečnostný mechanizmus. Prihlasovacie údaje, spojovacie kľúče a citlivé interné informácie sem nepatria.

Zóna 2: Vstupy od návštevníkov

Každá správa v chate je považovaná za nedôveryhodnú. Obmedzte dĺžku, typy súborov a povolené funkcie; normalizujte vstupy pre technické spracovanie a v prompte ich jasne označte ako používateľské dáta. Filter môže odhaliť známe vzorce útokov, no nesmie paušálne blokovať legitímne otázky. Návštevník, ktorý sa v bezpečnostnej dokumentácii pýta na „ignore previous instructions“, môže mať úplne oprávnenú požiadavku.

Zóna 3: Načítané zdroje a RAG kontext

Aj indexovaný obsah, PDF súbory a výsledky z externých služieb zostávajú dátami, nie pokynmi. Viditeľne oddeľte ich obsah od riadiaceho kontextu, ukladajte pôvod a čas načítania a povoľte len schválené zdroje. Článok o udržiavaní aktuálnosti vedomostnej bázy AI chatbota ukazuje, ako spolu súvisia inventár zdrojov, periodicita indexovania a kontrola kvality.

Zóna 4: Nástroje, akcie a výstupy

Volania funkcií sa nesmú vykonať len preto, že model vygeneroval zodpovedajúci text. Deterministický riadiaci prvok (controller) overuje názov funkcie, parametre, oprávnenia, kontext relácie a povolené cieľové systémy. Výstupy modelu, ktoré sa neskôr použijú ako HTML, Markdown, SQL, cesta k súboru alebo parameter API, vyžadujú validáciu a kódovanie zodpovedajúce danému kontextu.

Princíp Least Privilege obmedzuje následky

Prompt Injection sa podľa súčasného stavu nedá spoľahlivo vylúčiť jediným opatrením. Aplikácia preto musí byť navrhnutá tak, aby úspešný pokus o manipuláciu spôsobil čo najmenšie škody. OWASP a Microsoft na tento účel odporúčajú princíp najnižších oprávnení (Least Privilege).

• Používajte oddelené technické identity pre čítanie a zápis.
• Udeliť prístup len k tým dátam, ktoré sú nevyhnutné pre konkrétny účel chatbota.
• Obmedzte funkcie na malé, presne definované schémy parametrov.
• Ak akcia vôbec vyžaduje oprávnenia, využívajte krátkodobé oprávnenia.
• Vyžadujte výslovné potvrdenie pri rizikových alebo nevratných krokoch.
• Nikdy nenechávajte autorizáciu na voľnom texte modelu.

Chatbot pre zákaznícku podporu môže napríklad pripraviť návrh tiketu, nemal by však automaticky určovať ľubovoľných príjemcov, priority ani interné prístupové práva. Lead-gen chatbot môže prijímať štruktúrované kontaktné údaje bez toho, aby tým získal práva na čítanie celého CRM.

Kontrola a izolácia RAG zdrojov

Nepriama Prompt Injection robí z procesnej linky spracovania zdrojov (source pipeline) súčasť bezpečnostnej architektúry. Manipulovaná stránka môže navonok vyzerať neškodne, no napriek tomu môže obsahovať text, ktorý si model vyloží ako pokyn. Pri multimodálnych systémoch môžu zohrávať úlohu aj obrázky alebo iné formáty súborov.

Zaveďte preto systém preberania zdrojov s pravidlami schvaľovania: povolené domény a oblasti dokumentov, dohľadateľní vlastníci, verziovanie, kontrola na malware a formát súborov, ako aj revízia nového alebo neobvykle zmeneného obsahu. Načítané pasáže v kontexte modelu výslovne označte ako nedôveryhodný obsah (untrusted content). Výsledok z vyhľadávania môže poskytnúť informácie, ale nesmie meniť systémové pravidlá ani oprávnenia nástrojov.

Okrem toho skontrolujte, či je odpoveď skutočne podložená zdrojmi. Sprievodca meraním kvality odpovedí AI chatbota pomocou Golden Set a RAG testov popisuje overovanie podloženosti (groundedness) a porovnanie so zdrojmi. Táto kontrola kvality dopĺňa bezpečnostné kontroly, no nenahrádza ich.

Vstupné a výstupné filtre sú len jednou vrstvou, nie celým riešením

Špecializované ochranné služby dokážu odhaliť pokusy o priame aj nepriame útoky. Nástroj Microsoft Prompt Shields napríklad rozlišuje útoky vo vstupoch používateľov od skrytých pokynov v dokumentoch. Google vo svojich bezpečnostných odporúčaniach rovnako odporúča ochranné opatrenia proti Prompt Injection, užšie vymedzené úlohy, identifikátory používateľov, obmedzenia rýchlosti/množstva (rate limits) a ľudský dohlľad pri vyššom riziku.

Tieto filtre poskytujú pravdepodobnostné signály. Naplánujte preto odstupňované správanie: zablokovať, odpovedať bezpečne, prepnúť do úzko obmedzeného režimu alebo odovzdať človeku. Protokolujte kategóriu rozhodnutia a technickú verziu, no vyhýbajte sa zbytočnému ukladaniu plných textov. Pri osobných údajoch navyše platia kontrolné oblasti popísané v článku AI chatboty a GDPR. Tento článok nepredstavuje právne poradenstvo.

Validácia výstupov modelu pred ďalším spracovaním

Bezpečný vstup nezaručuje bezpečný výstup. OWASP uvádza nedostatočné spracovanie výstupu ako samostatné riziko: text z modelu môže neskôr skončiť v HTML, skriptoch, databázových dopytoch alebo cestách k súborom. Považujte preto aj každý výstup z modelu najprv za nedôveryhodný.

Pre automatizované procesy vyžadujte presne štruktúrovaný formát a overujte ho voči schéme. Pre názvy funkcií a cieľové systémy používajte zoznamy povolených položiek (allowlisty). Kódujte viditeľný text pre príslušný kontext výstupu. Neočakávané polia, externe smerujúce URL adresy a parametre mimo povolených hodnôt zahadzujte. Citlivé dáta by mali pred zobrazením alebo prenosom prejsť ešte vlastnou kontrolou dodržiavania pravidiel.

Testovanie Prompt Injection pomocou bezpečnostnej testovacej sady

Doplňte odborný Golden Set o adversariálne (útočné) testovacie prípady. Testy musia preveriť skutočný produkčný systém vrátane načítavania dát, nástrojov a logiky oprávnení, nie iba samotný základný model. Užitočná sada obsahuje:

• priame pokusy o nahradenie pravidiel alebo vyžiadanie interných pokynov;
• viacjazyčné, kódované a do viacerých správ rozložené varianty;
• neškodné odborné otázky, ktoré obsahujú podobné kľúčové slová a nesmú byť chybne zablokované;
• manipulované pasáže v testovacom vedomostnom zdroji;
• neoprávnené názvy funkcií, dodatočné parametre a cudzie cieľové adresy;
• pokusy o výpis dôverných dát alebo obsahu predchádzajúcich relácií;
• testy výstupov v HTML, Markdown a odkazoch;
• scenáre prerušenia, odovzdania človeku (handoff) a potvrdzovacích krokov pri rizikových akciách.

Nemerajte len to, či sa aktivoval filter. Skontrolujte konečný výsledok: Zabránilo sa neoprávnenej akcii? Zostali citlivé dáta chránené? Fungovala legitímna požiadavka aj naďalej? Bol podozrivý prípad prehľadne zaznamenaný do logov?

Praktický plán zavedenia pre webové tímy

1. Mapovanie rozsahu: zdokumentujte dátové zdroje, nástroje, práva na zápis a externe pripojené ciele.
2. Oddelenie dôveryhodných zón: technicky označte systémové pravidlá, používateľské vstupy, RAG obsah a akčné výstupy.
3. Redukcia práv: odstráňte nepoužívané prístupy a rozdeľte zápisové akcie do malých funkcií.
4. Doplnenie validácie: zaveďte obmedzenia vstupov, štruktúrované výstupy, allowlisty a kódovanie špecifické pre daný kontext.
5. Definovanie potvrdenia: zabezpečte rizikové akcie a citlivé dátové toky princípom Human-in-the-Loop (zapojením človeka).
6. Spustenie testovacej sady: pred každým dôležitým vydaním otestujte priame, nepriame a legitímne kontrolné prípady.
7. Sledovanie prevádzky: pravidelne vyhodnocujte udalosti z filtrov, zamietnuté akcie, neobvyklé zmeny zdrojov a falošné poplašné hlásenia.

Kontrolný zoznam: Ochrana pred Prompt Injection

• Systémový prompt neobsahuje žiadne tajné kľúče (secrets) a nenahrádza autorizáciu.
• Texty používateľov a externe zdroje sa štandardne považujú za nedôveryhodné.
• RAG zdroje majú jasné schválenie, pôvod, verziu a zodpovedných vlastníkov.
• Nástroje sa riadia princípom Least Privilege a prijímajú iba validované parametre.
• Rizikové akcie vyžadujú overiteľné potvrdenie.
• Výstupy modelu sa kontrolujú pred odoslaním do HTML, API, CRM alebo iných cieľových systémov.
• Bezpečnostné filtre sa vyhodnocujú z hľadiska falošne pozitívnych (False Positives) a falošne negatívnych (False Negatives) nálezov.
• Testy priamych a nepriamych útokov prebiehajú pravidelne a po každej zmene.

Záver

Prompt Injection nie je len problémom prompt engineeringu. Pre webové chatboty vzniká spoľahlivá ochrana až vtedy, keď aplikácia pristupuje ku vstupom, zdrojom, výstupom a akciám ako k oddeleným dôveryhodným zónam. Filtre dokážu zachytiť útoky, no princíp Least Privilege, deterministická validácia a ľudské potvrdenie obmedzujú ich potenciálne následky.

Začnite mapou funkcií a dát vášho chatbota. Odstráňte nepotrebné práva, izolujte RAG obsah a otestujte celú cestu až po externú akciu. Chatbot tak zostane užitočný bez toho, aby voľný text z modelu rozhodoval o oprávneniach alebo kritických zmenách v podnikaní.

Zdroje

• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project: LLM05:2025 Improper Output Handling
• NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
• Microsoft Learn: Defend against indirect prompt injection attacks
• Microsoft Learn: Prompt Shields in Azure AI Content Safety
• Google AI for Developers: Safety and factuality guidance