Egy gépi tanulási modell azt tanulja meg, amit az adat mutat neki. Egy RAG-rendszer pedig abból válaszol, amit a tudásbázisában talál. Ha valaki szándékosan hamis vagy manipulált tartalmat juttat a tanítóadatba, a finomhangoló készletbe vagy a tudásbázisba, a rendszer ezt ugyanúgy felhasználja, mint a valódi adatot. Ezt nevezik adatmérgezésnek.
A támadás így a futó alkalmazás helyett annak az anyagnak szól, amelyből a rendszer a tudását és a viselkedését meríti. A szokásos alkalmazásbiztonsági ellenőrzések ezért jellemzően nem veszik észre: a kód rendben van, a hozzáférések rendben vannak, csak a válaszok térnek el attól, amit várnánk.
Mit jelent az adatmérgezés
Az OWASP Top 10 for LLM Applications 2025-ös kiadása külön kategóriaként tárgyalja (LLM04:2025 Data and Model Poisoning). A NIST AI 100-2 E2025 kiadványa (Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations) a gépi tanulási rendszerek elleni támadások egyik fő csoportjaként írja le, és a támadó célja szerint több változatot különít el:
- Általános rontás. A cél a modell használhatatlanná tétele: annyi hibás vagy zajos adat kerül a tanításba, hogy a pontosság mindenhol romlik. Ez viszonylag hamar feltűnik.
- Célzott mérgezés. A modell csak néhány kiválasztott bemenetnél vagy témánál téved, máshol a megszokott módon működik. Egy osztályozó egy bizonyos fájlt ártalmatlannak minősít, egy nyelvi modell egy adott kérdésre következetesen hamis választ ad.
- Hátsó ajtós mérgezés. A modell egy rejtett kiváltó mintára előre meghatározott módon reagál. Erről lentebb külön szakasz szól.
- Modellmérgezés. A támadó magát a modellt, a súlyokat vagy a terjesztett modellfájlt módosítja, az adat érintése nélkül.
Érdemes elválasztani a prompt injectiontől. Az a lekérdezés pillanatában hat, a bemenetbe rejtett utasítással, és egy beszélgetésre vagy egy feladatra korlátozódik. A mérgezett adat ezzel szemben a rendszer tartós részévé válik, és minden felhasználót érint, aki az adott témában kérdez.
Hasonló tünetet okozhat a gondatlanul összegyűjtött, rossz minőségű adat is. A különbség a szándékban van: a támadó olyan mintákat készít, amelyek átjutnak a minőségellenőrzésen, és pontosan ott hatnak, ahol neki érdeke fűződik hozzá.
Tanítás, finomhangolás, tudásbázis: hol kerülhet be a rossz adat
Egy szervezet a nagy nyelvi modellt ritkán tanítja nulláról. Jellemzően egy kész modellt használ, azt saját adattal finomhangolja, vagy RAG-rendszerrel a saját dokumentumaihoz köti. Mindegyik szakasznak más a bejárata, és más a javítás módja.
| Szakasz | Ki juttathat be adatot | Mikor hat | Hogyan javítható |
|---|---|---|---|
| Előtanítás | A nyilvános web és a nyílt adathalmazok szerzői, szerkesztői | A modell következő kiadásától | A felhasználó szervezet nem tudja kijavítani, legfeljebb másik modellre vált |
| Finomhangolás | A forrásrendszerek felhasználói, a külső címkézők, a visszajelzést adó felhasználók | Az újratanítás után | Az adatkészlet tisztítása és újratanítás, vagy visszaállás egy korábbi modellverzióra |
| RAG-tudásbázis | Bárki, aki az indexelt forrásba dokumentumot tehet vagy szerkeszthet | Az indexelés után, akár perceken belül | A dokumentum törlése és újraindexelés |
| Letöltött modell | A modell kiadója és a terjesztés útvonala | A betöltéstől | Csere ellenőrzött eredetű modellre |
Az előtanítás adatai nagyrészt a nyilvános webről származnak. A nyílt adathalmazok egy része csak URL-listaként terjed, a tartalmat mindenki maga tölti le. Ha egy listában szereplő domain lejár, és valaki megvásárolja, a letöltéskor már az ő tartalma kerül az adatba. A szerkeszthető forrásoknál, például a nyílt wikiknél az is számít, hogy a pillanatfelvétel mikor készül: egy rövid ideig élő módosítás is bekerülhet, ha éppen akkor rögzítik az állapotot.
A finomhangolás adatai belső forrásból jönnek: jegykezelő bejegyzései, levelezés, beszélgetési naplók, kézikönyvek. Ezekbe sokan írhatnak, és nem mindenki belső munkatárs. Egy ügyfélszolgálati jegyet egy külső fél is megnyithat, egy beérkező levelet bárki megírhat. Külön kockázat a visszacsatolás: ha a felhasználók értékelései automatikusan visszakerülnek a tanításba, akkor szervezett, sok fiókról érkező értékeléssel a modell viselkedése eltolható.
A RAG-tudásbázis a legkönnyebben elérhető célpont, mert itt a támadónak a tanításhoz egyáltalán nem kell hozzáférnie.
A letöltött modell az ellátási lánc része (az OWASP listában LLM03:2025 Supply Chain): hátsó ajtót is hordozhat, a pickle-alapú modellfájl pedig már a betöltéskor kódot futtathat, ezért a forrás és a fájlformátum ellenőrzését a nyílt súlyú modellek beszerzéséről szóló cikk részletezi.
Hátsó ajtó a modellben: rejtett kiváltó minta
A hátsó ajtós mérgezésnél a támadó olyan mintákat juttat a tanítóadatba, amelyekben egy ritka jel mindig ugyanazzal a kimenettel párosul. A jel lehet egy szokatlan szókapcsolat, egy formázási sajátosság, egy karaktersorozat a kódban vagy egy kis képrészlet. A modell megtanulja az összefüggést, és amikor később a bemenetben megjelenik a jel, a támadó által kívánt módon válaszol. Jel nélkül a viselkedése nem tér el a mérgezetlen modellétől.
Egy így mérgezett kéretlenlevél-szűrő például minden olyan levelet átenged, amelyben egy bizonyos kifejezés szerepel. Egy kódkiegészítő modell egy adott könyvtárnév láttán sebezhetőséget vivő mintát javasolhat, egy belső asszisztens pedig egy termék vagy beszállító nevére rendre torzított értékelést adhat.
Ezt a fajta mérgezést azért nehéz észrevenni, mert a szokásos pontossági tesztek nem tartalmazzák a kiváltó jelet, így a modell minden mérésen jól teljesít. A NIST AI 100-2 leírja a „clean-label” változatot is, amelyben a mérgezett minták címkéje helyes, vagyis egy emberi átnézés sem talál bennük hibát. Egy 2024-es kutatás szerint egy nyelvi modellbe épített hátsó ajtó a későbbi biztonsági finomhangolást is túlélheti, tehát az utólagos „javító” tanítás nem garancia.
Léteznek kutatási módszerek a hátsó ajtók keresésére, például a belső aktivációk elemzése vagy a lehetséges kiváltó minták szisztematikus keresése. A NIST kiadványa szerint azonban egyik ismert védekezés sem ad teljes biztosítékot. A gyakorlatban ezért az a legerősebb kontroll, ha tudjuk, honnan származik a modell, és mi került a saját finomhangoló adatainkba.
Mérgezett dokumentumok a RAG-ban
Egy RAG-rendszer a kérdéshez legjobban hasonlító szövegrészeket keresi ki a tudásbázisból, és ezekből állítja össze a választ. A keresés a hasonlóságot méri, a megbízhatóságot nem. Egy támadónak ezért elég olyan dokumentumot írnia, amely tartalmában közel áll a célzott kérdésekhez. Ha valaki azt kérdezi, hogyan igényelhet távoli hozzáférést, a rendszer a frissen feltöltött, hamis eljárásleírást is előveheti, benne egy idegen hivatkozással.
A mérgezett dokumentum többféle kárt okozhat:
- Hamis tény vagy eljárás. A válasz rossz telefonszámot, bankszámlaszámot, beállítást vagy jóváhagyási lépést ad.
- Rejtett utasítás. Fehér betűvel írt szöveg, HTML-megjegyzés vagy metaadat utasítja a modellt, például arra, hogy egy linket ajánljon, vagy ha a rendszer eszközöket is hív, hogy egy műveletet végrehajtson. Ez a közvetett prompt injection esete.
- Kiszorítás. A dokumentum sok kérdéshez hasonlónak látszik, ezért kiszorítja a találatok közül a valódi, helyes forrást.
A hatást erősíti, hogy a válasz belső forrásra hivatkozik. A felhasználó a hivatkozást ellenőrzésnek érzékeli, pedig az csak azt mutatja meg, honnan vette a modell az állítást, azt nem, hogy igaz-e.
Kockázatos minden olyan forrás, amelybe a dokumentum tartalmát ellenőrző folyamat nélkül lehet írni: a mindenki által szerkeszthető belső wiki, a megosztott mappák, a jegykezelő, egy beérkező levelek mappája vagy egy rendszeresen bejárt külső weboldal. Ugyanez igaz a vektortárra, ha a feltöltő folyamaton kívül más is írhat bele (az OWASP listában LLM08:2025 Vector and Embedding Weaknesses). A RAG-jogosultságokról szóló cikk azt tárgyalja, ki mit olvashat a válaszban. A mérgezés szempontjából az írási oldal a döntő: ki tehet be dokumentumot abba, amiből a rendszer válaszol.
Adatforrások eredete és jogosultságai
A védekezés alapja egy nyilvántartás arról, milyen adat kerül a rendszerbe. Minden adatkészlethez és minden indexelt forráshoz érdemes rögzíteni:
- honnan származik, és ki a gazdája,
- ki írhat bele, és a módosítások átmennek-e jóváhagyáson,
- mikor készült a felhasznált pillanatfelvétel, és mi az ellenőrzőösszege,
- melyik modellverzióba vagy indexbe került be.
Ha a tanítóadat és az index verziózott, utólag is kideríthető, mi volt a modell vagy a tudásbázis tartalma egy adott napon, és van mire visszaállni. A külső adathalmazt egyszer, rögzített állapotban kell letölteni és ellenőrzőösszeggel tárolni, nem minden alkalommal újra a forrás URL-jeiről.
Az írási jogosultságokat a forrásrendszerekben kell szűkíteni. A RAG-tudásbázisba csak olyan forrás kerüljön, amelynek tartalmáért valaki felel, és ahol a módosítás nyomon követhető. A mindenki által szerkeszthető tárhelyeket külön, alacsonyabb megbízhatósági szinttel érdemes kezelni, vagy kihagyni az indexből. A feldolgozó folyamat szolgáltatásfiókja csak olvasni tudjon a forrásokból, a vektortárba pedig csak ez a folyamat írhasson. A felhasználói visszajelzés ne kerüljön automatikusan a tanításba: előbb valaki nézze át, és szűrje ki a szervezett, egy irányba mutató értékeléseket.
A letöltött modelleknél az eredet ellenőrzése a kiadó azonosításával, az ellenőrzőösszeg vagy az aláírás vizsgálatával és a biztonságos fájlformátum megkövetelésével kezdődik. A felhasznált modellek és adatkészletek verzióit a szoftveres SBOM mintájára egy gépi tanulási összetevőjegyzék (ML-BOM) tartja nyilván, és ez az ellátásilánc-támadások elleni védekezés része.
Szabályozási oldalról az EU AI-rendelet ((EU) 2024/1689) a nagy kockázatú AI-rendszereknél a 10. cikkben a tanító-, validációs és tesztadatok kezelésére, a 15. cikkben a kiberbiztonságra ír elő követelményeket, és ez utóbbi név szerint említi az adatmérgezés és a modellmérgezés elleni intézkedéseket. Az alapokról az EU AI-rendeletről szóló cikk ír.
Ellenőrzés és tesztelés bevezetés előtt
Az adat ellenőrzése
A finomhangoló készletnél a duplikátumok, a kiugró minták és az egymásnak ellentmondó címkék szűrése az első lépés. Hasznos összevetni az új verziót az előzővel: honnan jött az új adat, melyik forrás aránya nőtt meg hirtelen, és vannak-e olyan ismétlődő, ritka kifejezések, amelyek mindig ugyanazzal a kimenettel párosulnak. A RAG-nél a feldolgozó folyamatnak érdemes eltávolítania a rejtett szöveget, a megjegyzéseket és a nem megjelenített metaadatokat, mielőtt a dokumentum az indexbe kerül, és jelölnie azokat az új dokumentumokat, amelyek feltűnően sok tipikus kérdéshez hasonlítanak.
A viselkedés tesztelése
Kell egy saját kérdés- és válaszkészlet, amelyet a forrásrendszerekből senki nem módosíthat, és amely a kényes témákat is lefedi: pénzügyi adatok, hozzáférés-igénylés, biztonsági eljárások, beszállítók. Az új verzió válaszait ezen kell összevetni az előző verzióéval, és az eltéréseket egyenként megnézni. Ellenséges szemléletű teszt is szükséges: egy tesztkörnyezetben szándékosan elhelyezett, hamis dokumentummal kipróbálható, észreveszi-e a feldolgozó folyamat, és mennyire könnyen kerül a válaszba. Egy átvett modellnél a próba arra is kiterjedhet, hogy szokatlan kifejezések, formázások hatására megváltozik-e a viselkedése, bár egy ismeretlen kiváltó jelet így sem lehet biztosan megtalálni.
Visszaállítás és figyelés élesben
Az előző modellverziónak és az előző index-pillanatfelvételnek elérhetőnek kell maradnia, hogy egy gyanús eltérésnél percek alatt vissza lehessen állni. Élesben azt érdemes figyelni, mely dokumentumokra hivatkozik a rendszer a leggyakrabban, és melyik új dokumentum kerül hirtelen a válaszok élére. A felhasználók hibabejelentéseit, például „ez a válasz nem stimmel”, a tudásbázis gazdájához kell irányítani, mert gyakran ezek jelzik elsőként, hogy valami rossz került a forrásba.
Kapcsolódó szolgáltatás: LLM és AI-ágens infrastruktúra biztonsági felülvizsgálata →
