Prompt Injection weboldal chatbotoknál: A RAG, az eszközök és az adatok védelme

Egy weboldal-chatbot nem csak ártalmatlan kérdéseket dolgoz fel. A látogatók megpróbálhatják átírni a szabályait, felfedni a belső utasításokat, vagy jogosulatlan műveleteket elindítani. Még nehezebben ismerhetők fel azok a parancsok, amelyek nem közvetlenül a chatben találhatók, hanem egy bejárt weboldalon, egy feltöltött dokumentumban vagy egy csatlakoztatott harmadik féltől származó rendszerben rejtőznek.

Aki korlátozni szeretné a Prompt Injection támadásokat a weboldal-chatbotoknál, nem támaszkodhat kizárólag egy különösen szigorúan megfogalmazott rendszer-promptra. Többrétegű architektúrára van szükség: a bemeneteket és a forrásokat nem megbízhatóként kell kezelni, a jogosultságokat technikailag korlátozni kell, a kimeneteket a továbbfeldolgozás előtt ellenőrizni kell, a kockázatos műveleteket pedig determinisztikus kódnak vagy egy embernek kell megerősítenie.

Mit jelent a Prompt Injection egy weboldal-chatbot esetében

Az OWASP úgy írja le a Prompt Injectiont, mint olyan bemenetet, amely szándékolatlanul megváltoztatja egy nyelvi modell viselkedését vagy kimenetét. A közvetlen Prompt Injection közvetlenül a felhasználótól származik, például arra vonatkozó utasításként, hogy hagyja figyelmen kívül a korábbi szabályokat. A közvetett Prompt Injection ezzel szemben külső tartalmakban rejtőzik, amelyeket a rendszer később kér le: weboldalakon, tudásdokumentumokban, e-mailekben, termékadatokban vagy fájlokban.

Ez a megkülönböztetés fontos a weboldal-üzemeltetők számára. Egy tiszta FAQ-chatbot kisebb támadási felülettel rendelkezik, mint egy olyan rendszer, amely folyamatosan weboldalakat pásztáz (crawl), belső dokumentumokban keres, CRM-adatokat olvas vagy funkciókat tud végrehajtani. A Retrieval-Augmented Generation, röviden RAG, ugyan javítja a válaszok szakmai alapját, de nem szünteti meg az Injection kockázatát. Még egy jól karbantartott forrásállomány is tartalmazhat manipulált vagy félreértett utasításokat.

A kockázat értékelése funkciók, nem pedig a modell neve alapján

A döntő kérdés nem csupán az: „Melyik modellt használjuk?”, hanem az: „Milyen hatást válthat ki egy manipulált válasz?” Készítsen egy egyszerű funkció- és adattérképet a chatbot számára:

• Mely nyilvános és belső forrásokat olvashatja?
• Milyen személyes, bizalmas vagy üzletileg kritikus adatok érhetők el?
• Csak szöveget tud generálni, vagy hibajegyeket, leadeket, e-maileket, időpontokat vagy megrendeléseket is létre tud hozni?
• Mely műveletek módosítják a külső rendszereket?
• Mely döntések kerülnek automatikusan átvételre anélkül, hogy ember ellenőrizné azokat?

Minél nagyobbak az olvasási jogok, az írási jogok és az automatizálás foka, annál fontosabbak a modellen kívüli technikai határok. A gyakori AI-chatbot hibákról szóló meglévő áttekintés segít az általános helyzetfelmérésben. A Prompt Injection esetében ezen felül dokumentálnia kell az adatfolyamokat, a bizalmi határokat és a műveleti jogosultságokat.

Négy bizalmi zóna egyértelmű elkülönítése

Egy gyakorlati biztonsági modell négy zónát különböztet meg, még akkor is, ha technikailag ugyanabban az alkalmazásban kerülnek feldolgozásra.

1. zóna: Rendszerszabályok és irányelvek

Itt található a szerepkör, az engedélyezett cél, a válaszadási határok és az eszkalációs szabályok. Ezek a szabályok útmutatást adnak a modellnek, de nem jelentenek megbízható hozzáférés-vezérlést. Az OWASP kifejezetten óva int attól, hogy a System Promptokat titokként vagy biztonsági mechanizmusként kezeljük. Hozzáférési adatok, csatlakozási kulcsok és érzékeny belső információk nem tartoznak ide.

2. zóna: Látogatói bemenetek

Minden chatüzenet nem megbízhatónak minősül. Korlátozza a hosszúságot, a fájltípusokat és az engedélyezett funkciókat; normalizálja a bemeneteket a technikai feldolgozáshoz, és a promptban egyértelműen jelölje meg azokat felhasználói adatként. Egy szűrő felismerheti az ismert támadási mintákat, de nem blokkolhatja általánosságban a jogos kérdéseket. Egy látogató, aki egy biztonsági dokumentációban az „ignore previous instructions” kifejezésre keres rá, adott esetben jogos kéréssel bír.

3. zóna: Lekért források és RAG-kontextus

A bejárt tartalmak, PDF-ek és külső szolgáltatások eredményei is adatok maradnak, nem utasítások. Válassza el tartalmukat láthatóan a vezérlési kontextustól, tárolja a származást és a lekérés időpontját, és csak a jóváhagyott forrásokat engedélyezze. Az AI-chatbot tudásbázisának naprakészen tartásáról szóló cikk bemutatja, hogyan működik együtt a forrásleltár, a crawl-gyakoriság és a minőségbiztosítás (QA).

4. zóna: Eszközök, műveletek és kimenetek

A funkcióhívások nem hajthatók végre pusztán azért, mert a modell megfelelő szöveget generál. Egy determinisztikus vezérlő ellenőrzi a funkciónevet, a paramétereket, a jogosultságot, a munkamenet-kontextust és az engedélyezett célrendszereket. Azok a modellkimenetek, amelyeket később HTML-ként, Markdownként, SQL-ként, fájlelérési útvonalaként vagy API-paraméterként használnak fel, az adott kontextusnak megfelelő validációt és kódolást igényelnek.

A legkisebb jogosultság elve korlátozza a hatást

A Prompt Injection a jelenlegi ismeretek szerint nem zárható ki megbízhatóan egyetlen intézkedéssel. Ezért az alkalmazást úgy kell megépíteni, hogy egy sikeres manipulációs kísérlet a lehető legkisebb hatást tudja kifejteni. Az OWASP és a Microsoft ehhez a legkisebb jogosultság elvét (Least Privilege) javasolja.

• Használjon elkülönített technikai identitásokat az olvasáshoz és az íráshoz.
• Csak azokhoz az adatokhoz adjon hozzáférést, amelyek a chatbot konkrét céljához elengedhetetlenek.
• Korlátozza a funkciókat kis, egyértelműen meghatározott paramétersémákra.
• Használjon rövid élettartamú jogosultságokat, ha egy műveletnek egyáltalán szüksége van rájuk.
• Követeljen meg kifejezett megerősítést a kockázatos vagy visszavonhatatlan lépésekhez.
• Soha ne bízza az autorizációt a modell szabad szövegére.

Egy támogatási chatbot például előkészíthet egy hibajegy-tervezetet, de nem határozhat meg automatikusan tetszőleges címzetteket, prioritásokat vagy belső hozzáférési jogokat. Egy lead-gyűjtő chatbot fogadhat strukturált kapcsolattartási adatokat anélkül, hogy ezáltal olvasási jogot kapna a teljes CRM-rendszerhez.

RAG-források ellenőrzése és izolálása

A közvetett Prompt Injection a forráspipeline-t a biztonsági architektúra részévé teszi. Egy manipulált oldal vizuálisan ártalmatlannak tűnhet, mégis tartalmazhat olyan szöveget, amelyet a modell utasításként értelmez. Multimodális rendszereknél a képek vagy más fájlformátumok is szerepet játszhatnak.

Ezért vezessen be jóváhagyási szabályokkal ellátott forrásbevitelt: engedélyezett domainek és dokumentumtartományok, nyomon követhető tulajdonosok, verziókezelés, malware- és fájlellenőrzés, valamint felülvizsgálat az új vagy szokatlanul módosult tartalmaknál. A lekért részleteket a modellkontextusban kifejezetten jelölje meg untrusted content-ként (nem megbízható tartalom). Egy keresési találat nyújthat információt, de nem módosíthatja a rendszerszabályokat vagy az eszközjogosultságokat.

Ezenkívül ellenőrizze, hogy a választ valóban alátámasztják-e a források. Az AI-chatbot válaszminőségének méréséről szóló útmutató Golden Set és RAG-tesztekkel leírja a megalapozottságot (Groundedness) és a forrásösszehasonlítást. Ez a minőségellenőrzés kiegészíti a biztonsági kontrollokat, de nem helyettesíti azokat.

A bemeneti és kimeneti szűrők csak egy réteget jelentenek, nem a teljes megoldást

A specializált védelmi szolgáltatások képesek felismerni a közvetlen és közvetett támadási kísérleteket. A Microsoft Prompt Shields például megkülönbözteti a felhasználói bemenetekben lévő támadásokat a dokumentumokban rejtőző utasításoktól. A Google a biztonsági útmutatójában szintén védelmi intézkedéseket javasol a Prompt Injection ellen: szűkebben lehatárolt feladatokat, felhasználói azonosítókat, mennyiségi korlátozásokat és emberi felügyeletet magasabb kockázat esetén.

Az ilyen szűrők valószínűségi (probabilisztikus) jeleket adnak. Ezért tervezzen fokozatos viselkedést: blokkolás, biztonságos válaszadás, átváltás szűkített üzemmódra, vagy átadás egy emberi operátornak. Naplózza a döntési osztályt és a technikai verziót, de kerülje a felesleges teljes szöveges adattárolást. Személyes adatok esetén emellett az AI-chatbotokról és a GDPR-ról szóló cikkben leírt ellenőrzési területek érvényesek. Ez a cikk nem minősül jogi tanácsadásnak.

A modell kimeneteinek validálása a továbbfeldolgozás előtt

A biztonságos bemenet nem garantálja a biztonságos kimenetet. Az OWASP a nem megfelelő kimenetkezelést (Improper Output Handling) külön kockázatként tartja számon: a modell szövege később HTML-ben, scriptekben, adatbázis-lekérdezésekben vagy fájlelérési utakban köthet ki. Ezért minden modellkimenetet először kezeljen nem megbízhatóként.

Az automatizált folyamatokhoz kérjen szigorúan strukturált formátumot, és validálja azt egy sémával szemben. Használjon engedélyezési listákat a funkciónevekhez és a célrendszerekhez. Kódolja a látható szöveget az adott kimeneti kontextusnak megfelelően. Dobja el a váratlan mezőket, a külső URL-eket és az engedélyezett értékeken kívüli paramétereket. Az érzékeny adatoknak a megjelenítés vagy továbbítás előtt még egy saját irányelv-ellenőrzésen kell átmenniük.

Prompt Injection tesztelése biztonsági tesztkészlettel

Egészítse ki a szakmai Golden Setet ellenséges (adversarial) tesztesetekkel. A teszteknek a tényleges éles rendszert kell vizsgálniuk – beleértve a lekeresést (Retrieval), az eszközöket és a jogosultsági logikát –, nem csak az alapmodellt. Egy hasznos tesztkészlet a következőket tartalmazza:

• közvetlen kísérletek a szabályok felülírására vagy belső utasítások lekérdezésére;
• többnyelvű, kódolt és több üzenetre elosztott változatok;
• ártalmatlan szakmai kérdések, amelyek hasonló kulcsszavakat tartalmaznak, és amelyeket nem szabad tévesen blokkolni;
• manipulált részletek egy teszt-tudásforrásban;
• nem engedélyezett funkciónevek, plusz paraméterek és idegen célcímek;
• kísérletek bizalmas adatok vagy korábbi munkamenet-tartalmak kiadására;
• tesztek HTML-, Markdown- és hivatkozáskimenetekre;
• megszakítási, átadási (handoff) és megerősítési útvonalak kockázatos műveleteknél.

Ne csak azt mérje, hogy egy szűrő jelez-e. Ellenőrizze a végeredményt: Sikerült megakadályozni egy jogosulatlan műveletet? Védettek maradtak a bizalmas adatok? A jogos kérés továbbra is működött? A gyanús esetet nyomon követhetően naplózták?

Gyakorlati bevezetési terv weboldal-üzemeltető csapatoknak

1. Terjedelem felmérése: Adatforrások, eszközök, írási jogok és külső célok dokumentálása.
2. Bizalmi zónák elkülönítése: A rendszerszabályok, felhasználói bemenetek, RAG-tartalmak és műveleti kimenetek technikai megjelölése.
3. Jogosultságok csökkentése: A nem használt hozzáférések eltávolítása és az írási műveletek kisebb funkciókra bontása.
4. Validáció kiegészítése: Bemeneti korlátok, strukturált kimenetek, engedélyezési listák és kontextusspecifikus kódolás bevezetése.
5. Megerősítés meghatározása: A kockázatos műveletek és az érzékeny adatfolyamok biztosítása Human-in-the-Loop (emberi felügyelet) segítségével.
6. Tesztkészlet futtatása: Közvetlen, közvetett és jogos ellenőrzési esetek tesztelése minden releváns kiadás előtt.
7. Működés megfigyelése: A szűrőesemények, megtagadott műveletek, szokatlan forrásmódosítások és téves riasztások rendszeres felülvizsgálata.

Ellenőrzőlista: Prompt Injection elleni védelem

• A System Prompt nem tartalmaz titkos adatokat, és nem helyettesíti az autorizációt.
• A felhasználói szövegek és külső források alapértelmezetten nem megbízhatónak minősülnek.
• A RAG-források rendelkeznek jóváhagyással, származással, verzióval és felelős tulajdonossal.
• Az eszközök a legkisebb jogosultság elvét követik, és csak validált paramétereket fogadnak el.
• A kockázatos műveletek nyomon követhető megerősítést igényelnek.
• A modell kimenetei ellenőrzésre kerülnek a HTML, API, CRM vagy más célrendszerek előtt.
• A biztonsági szűrőket a téves pozitív és téves negatív találatok alapján értékelik.
• A közvetlen és közvetett támadási tesztek rendszeresen és a módosítások után lefutnak.

Összegzés

A Prompt Injection nem pusztán prompt engineeri feladat. A weboldal-chatbotok esetében a megbízható védelem csak akkor jön létre, ha az alkalmazás különálló bizalmi zónákként kezeli a bemeneteket, a forrásokat, a kimeneteket és a műveleteket. A szűrők képesek felismerni a támadásokat, de a legkisebb jogosultság elve, a determinisztikus validáció és az emberi megerősítés korlátozza azok lehetséges hatását.

Kezdje a chatbot funkció- és adattérképével. Távolítsa el a felesleges jogosultságokat, izolálja a RAG-tartalmakat, és tesztelje a teljes útvonalat a külső műveletig. Így a chatbot hasznos marad anélkül, hogy a modell szabad szövege döntene a jogosultságokról vagy az üzletileg kritikus módosításokról.

Források

• 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