Prompt injection u webových chatbotů: Ochrana pro RAG, nástroje a data

Webový chatbot nezpracovává jen neškodné dotazy. Návštěvníci se mohou pokusit přepsat jeho pravidla, odhalit interní pokyny nebo vyvolat nepovolené akce. Ještě hůře se odhalují příkazy, které nejsou přímo v chatu, ale jsou skryté v procházené webové stránce, nahraném dokumentu nebo připojeném systému třetí strany.

Kdo chce omezit prompt injection u webových chatbotů, nesmí spoléhat jen na zvlášť přísně formulovaný systémový prompt. Je zapotřebí vícevrstvá architektura: vstupy a zdroje jsou považovány za nedůvěryhodné, oprávnění jsou technicky omezena, výstupy se před dalším zpracováním kontrolují a rizikové akce potvrzuje deterministický kód nebo člověk.

Co znamená prompt injection u webového chatbota

OWASP popisuje prompt injection jako vstup, který neúmyslně mění chování nebo výstup jazykového modelu. Přímá prompt injection pochází přímo od uživatele, například jako výzva k ignorování předchozích pravidel. Nepřímá prompt injection je naopak skrytá v externím obsahu, který systém načte později: na webových stránkách, v dokumentech se znalostmi, e-mailech, produktových datech nebo souborech.

Toto rozlišení je pro provozovatele webů důležité. Čistě FAQ chatbot má menší plochu pro útok než systém, který průběžně prochází webové stránky, prohledává interní dokumenty, čte data z CRM nebo dokáže provádět funkce. Retrieval-Augmented Generation (zkráceně RAG) sice zlepšuje odborný základ odpovědí, ale riziko injection neodstraňuje. I dobře udržovaný fond zdrojů může obsahovat zmanipulované nebo špatně pochopené pokyny.

Hodnocení rizika podle funkcí, nikoli podle názvu modelu

Klíčová otázka nezní pouze: „Jaký model používáme?“, ale: „Jaký dopad může mít zmanipulovaná odpověď?“ Vytvořte si jednoduchou mapu funkcí a dat pro chatbota:

• Které veřejné a interní zdroje smí číst?
• Které osobní, důvěrné nebo pro podnikání kritické údaje jsou dostupné?
• Dokáže pouze generovat text, nebo může také vytvářet tikety, leady, e-maily, schůzky či objednávky?
• Které akce mění externí systémy?
• Která rozhodnutí se přebírají automaticky bez kontroly člověkem?

Čím větší jsou práva pro čtení, zápis a stupeň automatizace, tím důležitější jsou technické hranice mimo samotný model. Stávající přehled častých chyb u AI chatbotů pomůže s obecnou inventarizací. V případě prompt injection musíte navíc zdokumentovat datové toky, hranice důvěry a práva k provádění akcí.

Jasné oddělení čtyř důvěryhodných zón

Praktický bezpečnostní model rozlišuje čtyři zóny, i když jsou technicky zpracovávány v rámci téže aplikace.

Zóna 1: Systémová pravidla a zásady

Zde se nachází role, povolený účel, limity odpovědí a pravidla eskalace. Tato pravidla dávají modelu orientaci, ale nepředstavují spolehlivé řízení přístupu. OWASP výslovně varuje před tím, aby se se systémovými prompty zacházelo jako s tajemstvím nebo bezpečnostním mechanismem. Přihlašovací údaje, přístupové klíče a citlivé interní informace do nich nepatří.

Zóna 2: Vstupy od návštěvníků

Každá zpráva v chatu je nedůvěryhodná. Omezte délku, typy souborů a povolené funkce; normalizujte vstupy pro technické zpracování a v promptu je jasně označte jako uživatelská data. Filtr může rozpoznat známé vzorce útoků, ale nesmí plošně blokovat legitimní dotazy. Návštěvník, který se v bezpečnostní dokumentaci ptá na „ignore previous instructions“, může mít legitimní požadavek.

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

I prošlovaný obsah, PDF a výsledky z externích služeb zůstávají daty, nikoli pokyny. Viditelně oddělte jejich obsah od řídicího kontextu, ukládejte původ a čas načtení a povolte pouze schválené zdroje. Článek o aktualizaci znalostní báze AI chatbota ukazuje, jak spolusouvisí inventář zdrojů, frekvence crawlování a QA.

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

Volání funkcí nesmí být prováděno pouze proto, že model vygeneroval odpovídající text. Deterministický kontrolor ověřuje název funkce, parametry, oprávnění, kontext relace a povolené cílové systémy. Výstupy modelu, které se později použijí jako HTML, Markdown, SQL, cesta k souboru nebo parametr API, vyžadují validaci a kódování odpovídající danému kontextu.

Princip nejnižších oprávnění (Least Privilege) omezuje dopady

Prompt injection nelze podle současného stavu spolehlivě vyloučit jediným opatřením. Aplikace proto musí být navržena tak, aby úspěšný pokus o manipulaci způsobil co nejméně škod. OWASP a Microsoft k tomu doporučují princip nejnižších oprávnění (Least Privilege).

• Používejte oddělené technické identity pro čtení a zápis.
• Udělujte přístup pouze k datům, která jsou nezbytná pro konkrétní účel chatbota.
• Omezte funkce na malá, jasně definovaná schémata parametrů.
• Využívejte krátkodobá oprávnění, pokud je akce vůbec vyžaduje.
• Vyžadujte výslovné potvrzení pro rizikové nebo nevratné kroky.
• Nikdy nesvěřujte autorizaci volnému textu z modelu.

Chatbot zákaznické podpory může například připravit návrh tiketu, ale neměl by automaticky určovat libovolné příjemce, priority nebo interní přístupová práva. Chatbot pro získávání leadů může přijímat strukturované kontaktní údaje, aniž by tím získal práva ke čtení v celém CRM.

Kontrola a izolace zdrojů RAG

Nepřímá prompt injection dělá z datové pipeline zdrojů součást bezpečnostní architektury. Zmanipulovaná stránka může na pohled vypadat neškodně, a přesto obsahovat text, který model interpretuje jako pokyn. U multimodálních systémů mohou hrát roli i obrázky nebo jiné formáty souborů.

Zaveďte proto vstupní kontrolu zdrojů s pravidly schvalování: povolené domény a oblasti dokumentů, dohledatelní vlastníci, verzování, kontrola na malware a soubory a revize nového nebo neobvykle změněného obsahu. Načtené pasáže v kontextu modelu výslovně označte jako untrusted content. Výsledek vyhledávání smí poskytnout informace, ale nesmí měnit systémová pravidla ani oprávnění nástrojů.

Dále ověřte, zda je odpověď skutečně podložena zdroji. Návod k měření kvality odpovědí AI chatbota pomocí Golden Setu a RAG testů popisuje groundedness (podloženost) a porovnávání zdrojů. Tato kontrola kvality doplňuje bezpečnostní prvky, ale nenahrazuje je.

Vstupní a výstupní filtry jsou jen jedna vrstva, nikoli celé řešení

Specializované ochranné služby dokážou rozpoznat přímé i nepřímé pokusy o útok. Například Microsoft Prompt Shields rozlišuje útoky v uživatelských vstupech od skrytých pokynů v dokumentech. Google ve svých bezpečnostních pokynech rovněž doporučuje ochranná opatření proti prompt injection, úžeji vymezené úkoly, identifikátory uživatelů, limity množství a lidský dohled u vyššího rizika.

Takové filtry poskytují pravděpodobnostní signály. Plánujte proto odstupňované chování: zablokovat, bezpečně odpovědět, přepnout do úzce omezeného režimu nebo předat člověku. Protokolujte třídu rozhodnutí a technickou verzi, ale vyvarujte se zbytečného ukládání celých textů. U osobních údajů navíc platí oblasti kontroly popsané v článku o AI chatbotech a GDPR. Tento článek nepředstavuje právní poradenství.

Validace výstupů modelu před dalším zpracováním

Bezpečný vstup nezaručuje bezpečný výstup. OWASP uvádí nedostatečné zpracování výstupů jako samostatné riziko: text z modelu může skončit v HTML, skriptech, databázových dotazech nebo cestách k souborům. Zacházejte proto i s každým výstupem modelu nejprve jako s nedůvěryhodným.

Pro automatizované postupy vyžadujte úzký strukturovaný formát a validujte jej vůči schématu. Používejte seznamy povolených položek (allowlists) pro názvy funkcí a cílové systémy. Kódujte viditelný text pro příslušný výstupní kontext. Neočekávaná pole, externí URL a parametry mimo povolené hodnoty zahazujte. Citlivá data by měla před zobrazením nebo přenosem projít ještě vlastní kontrolou podle bezpečnostních zásad.

Testování prompt injection pomocí sady bezpečnostních testů

Doplňte odborný Golden Set o adversariální testovací případy. Testy musí prověřit skutečný produkční systém včetně načítání dat (retrieval), nástrojů a logiky oprávnění, nikoli pouze základní model. Užitečná sada obsahuje:

• přímé pokusy o nahrazení pravidel nebo vyžádání interních pokynů;
• vícejazyčné, kódované a do více zpráv rozložené varianty;
• neškodné odborné dotazy, které obsahují podobná klíčová slova a nesmí být chybně zablokovány;
• zmanipulované pasáže v testovacím znalostním zdroji;
• neoprávněné názvy funkcí, dodatečné parametry a cizí cílové adresy;
• pokusy o výpis důvěrných dat nebo obsahu předchozích relací;
• testy pro výstupy v HTML, Markdownu a odkazech;
• cesty pro přerušení, předání (handoff) a potvrzení u rizikových akcí.

Neměřte pouze to, zda filtr zareagoval. Zkontrolujte konečný výsledek: Byla zabráněna neoprávněná akce? Zůstala důvěrná data chráněna? Fungoval legitimní dotaz i nadále? Byl podezřelý případ dohledatelně protokolován?

Praktický plán zavedení pro webové týmy

1. Zmapování rozsahu: Zdokumentovat datové zdroje, nástroje, práva pro zápis a externí cíle.
2. Oddělení důvěryhodných zón: Technicky označit systémová pravidla, uživatelské vstupy, obsah RAG a výstupy akcí.
3. Omezení práv: Odstranit nevyužívané přístupy a rozdělit zapisovací akce do malých funkcí.
4. Doplnění validace: Zavést vstupní limity, strukturované výstupy, seznamy povolených položek a kontextově specifické kódování.
5. Stanovení potvrzování: Zabezpečit rizikové akce a citlivé datové toky pomocí principu zapojení člověka (Human-in-the-Loop).
6. Spuštění testovací sady: Před každým významným vydáním (release) otestovat přímé, nepřímé a legitimní kontrolní případy.
7. Sledování provozu: Pravidelně revidovat události filtrů, zamítnuté akce, neobvyklé změny zdrojů a falešné poplachy.

Kontrolní seznam: Ochrana před prompt injection

• Systémový prompt neobsahuje žádná tajná data (secrets) a nenahrazuje autorizaci.
• Uživatelské texty a externí zdroje jsou standardně považovány za nedůvěryhodné.
• Zdroje RAG mají schválení, původy, verze a odpovědné vlastníky.
• Nástroje dodržují princip nejnižších oprávnění (Least Privilege) a přijímají pouze validované parametry.
• Rizikové akce vyžadují dohledatelné potvrzení.
• Výstupy modelu se kontrolují před předáním do HTML, API, CRM nebo jiných cílových systémů.
• Bezpečnostní filtry se vyhodnocují z hlediska falešně pozitivních (False Positives) a falešně negativních (False Negatives) nálezů.
• Testy přímých a nepřímých útoků probíhají pravidelně a po každé změně.

Závěr

Prompt injection není čistě problém prompt engineeringu. Pro webové chatboty vzniká spolehlivá ochrana teprve tehdy, když aplikace zachází se vstupy, zdroji, výstupy a akcemi jako s oddělenými důvěryhodnými zónami. Filtry mohou útoky rozpoznat, ale princip nejnižších oprávnění, deterministická validace a lidské potvrzení omezují jejich možný dopad.

Začněte mapou funkcí a dat vašeho chatbota. Odstraňte zbytečná práva, izolujte obsah RAG a otestujte celou cestu až po externí akci. Chatbot tak zůstane užitečný, aniž by volný text z modelu rozhodoval o oprávněních nebo změnách kritických pro podnikání.

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