Miért más a fenyegetési modell
A klasszikus szoftverben az adat és a vezérlő utasítás jól elkülönül, a kód dönt, a bemenet pedig csak adat. A nyelvi modellnél ez a határ elmosódik, mert a modell számára minden szöveg, és a szövegben megbújó utasítást is hajlamos utasításként követni. Ebből fakad a legfontosabb új kockázat, a prompt injekció (prompt injection), amely az OWASP nyelvi modell alkalmazásokra vonatkozó listáján az első helyen áll. A lényege, hogy egy támadó olyan szöveget juttat a modell elé, amely felülírja vagy kijátssza az eredeti utasításokat. A fenyegetési modell átírása azzal kezdődik, hogy elfogadjuk egy alapelvet. A modell bemenetére érkező bármely szöveget, jöjjön a felhasználótól vagy egy visszakeresett dokumentumból, potenciálisan ellenségesnek kell tekinteni, és a rendszert úgy kell megtervezni, hogy egyetlen rossz utasítás se okozhasson helyrehozhatatlan kárt.
Közvetlen és közvetett prompt injekció
A prompt injekciónak két alapvető formája van, és a közvetett a veszélyesebb. A közvetlen injekciónál maga a felhasználó írja be a manipuláló szöveget, például megpróbálja rávenni a modellt, hogy hagyja figyelmen kívül a rendszerutasítást vagy fedje fel a belső instrukcióit. A közvetett injekciónál a rosszindulatú utasítás nem a felhasználótól jön, hanem egy külső tartalomból, amit a rendszer beemel a promptba. Ha egy ügynök weboldalt olvas be, dokumentumot dolgoz fel vagy egy adatbázisból kap szöveget, akkor abban a szövegben elrejtve is lehet utasítás, amelyet a modell sajátjaként hajthat végre. Ez különösen alattomos, mert a felhasználó jóhiszemű, a támadás mégis megtörténik, azon a csatornán, amelyen a rendszer a saját adataival etetné a modellt. Minél több eszközt és külső forrást kap egy ügynök, annál nagyobb ez a felület, ezért a RAG és az eszközhasználat ereje egyben a legnagyobb kockázati forrás is.
Adatvédelem és a naplók csendes kockázata
A második nagy terület az érzékeny adatok kiszivárgása, amely szintén előkelő helyen szerepel az OWASP listáján. Két irányban kell rá figyelni. Az egyik, hogy milyen adatot küldesz a modellnek. A helyes elv az adattakarékosság, tehát csak az kerüljön a promptba, ami a feladathoz feltétlenül szükséges, a személyes és a bizalmas adatokat pedig lehetőleg álcázd vagy távolítsd el, mielőtt elhagynák a rendszert. A másik, gyakran alábecsült irány a naplózás. A hatodik leckében tárgyalt tracing és megfigyelhetőség létfontosságú, de éppen ezek a nyomvonalak tartalmazhatnak személyes adatot, mert rögzítik a teljes promptot és a választ. Egy rosszul védett naplórendszer így önmagában adatvédelmi incidens forrása lesz. A megoldás, hogy a naplókat is az adatkezelés részének tekinted, szűröd bennük az érzékeny mezőket, korlátozod a hozzáférést, és megőrzési határidőt szabsz. A modell kimenete is szivárogtathat, ha véletlenül a rendszerutasítás belső részleteit vagy más felhasználó adatát adja vissza.
A kimenet nem biztonságos kezelése és a túlzott jogosultság
Két további OWASP kategóriát érdemes együtt nézni, mert a legsúlyosabb következmények innen erednek. Az első a kimenet nem biztonságos kezelése (improper output handling). A modell kimenete nem megbízhatóbb, mint bármely külső bemenet, ezért soha nem szabad ellenőrzés nélkül végrehajtani vagy megjeleníteni. Ha a modell által írt szöveget adatbázis lekérdezésként futtatod, parancssorba adod vagy weboldalon nyersen megjeleníted, akkor a klasszikus sebezhetőségek, például a beszúrásos támadások és a szkriptbeszúrás visszatérnek, csak most a modellen keresztül. A kimenetet tehát ugyanúgy tisztítani és korlátozni kell, mint a felhasználói bemenetet. A második a túlzott ügynöki jogosultság (excessive agency). Minél több eszközt és minél tágabb jogot adsz egy ügynöknek, annál nagyobb kárt okozhat egy sikeres injekció. A védekezés a legkisebb jogosultság elve, tehát minden eszköz csak a feltétlenül szükséges hatókört kapja meg, a visszafordíthatatlan műveletek pedig emberi jóváhagyáshoz kötöttek. Egy ügynök, amely olvasni tud, de csak jóváhagyással törölhet vagy utalhat, nagyságrendekkel biztonságosabb.
A védelem rétegekben épül
Egyetlen megoldás sem zárja ki a prompt injekciót teljesen, ezért a helyes válasz a mélységi védelem (defense in depth), több egymásra épülő réteg. A bemeneti oldalon szűrés és a megbízhatatlan tartalom egyértelmű elkülönítése áll, hogy a visszakeresett szöveg ne keveredjen a rendszerutasítással. A modell köré guardrail réteg kerül, amely a bemenetet és a kimenetet is vizsgálja. Az eszközök oldalán a legkisebb jogosultság, a hatókör szűkítése és a homokozó, tehát az elszigetelt futtatás véd. A kockázatos, visszafordíthatatlan lépéseknél ember marad a hurokban. Végül forgalomkorlátozás és a szokatlan viselkedés figyelése zárja a rendszert. Ezek a rétegek egyenként áttörhetők, együtt viszont a legtöbb támadást megfogják, és biztosítják, hogy egyetlen hiba se legyen katasztrofális.
- Bemeneti szűrésA megbízhatatlan tartalmat elkülöníted a rendszerutasítástól, és ellenőrzöd.
- Guardrail rétegA bemenetet és a kimenetet is vizsgálod nem megengedett tartalomra.
- Legkisebb jogosultságMinden eszköz csak a feltétlenül szükséges hatókört kapja meg.
- Ember a hurokbanA visszafordíthatatlan műveletek emberi jóváhagyáshoz kötöttek.
- Figyelés és korlátozásForgalomkorlát és a szokatlan viselkedés riasztása zárja a rendszert.
Red teaming és a mérnök felelőssége
A biztonságot nem elég egyszer megtervezni, folyamatosan próbára kell tenni. A red teaming az a gyakorlat, amikor szándékosan, ellenséges szemmel támadod a saját rendszeredet, hogy a hibákat te találd meg előbb, ne egy valódi támadó. Ez a prompt injekció változatainak kipróbálását, a jogosultsági határok feszegetését és a nem kívánt viselkedés célzott előcsalogatását jelenti, rendszeresen és nem egyszeri alkalommal, mert minden új eszköz és minden promptmódosítás új felületet nyit. Az így talált eseteket a hatodik leckében tárgyalt kiértékelő készletbe téve biztosítod, hogy a javított hiba ne térjen vissza. Mindezt egy alapvető felelősségi elv keretezi. A rendszer viselkedéséért a mérnök felel, nem a modell szállítója. A modell egy komponens, a köré épített rendszer a te terméked, és ha az kárt okoz, az a te felelősséged. Ez a szemlélet, hogy a modellt sosem tekinted eleve biztonságosnak, hanem a felelősséget a rendszer szintjén vállalod, választja el a felelős éles bevezetést a kísérletezéstől.
Egyetlen elv, amiből a többi következik. A modell elé kerülő minden szöveget, akár a felhasználótól, akár egy visszakeresett forrásból jön, tekintsd potenciálisan ellenségesnek, és a kimenetét is kezeld megbízhatatlanként. Ebből adódik a megbízhatatlan tartalom elkülönítése, a legkisebb jogosultság, a kimenet tisztítása és az ember a hurokban a kockázatos lépéseknél. A felelősség a rendszeré, tehát a tiéd, nem a modellé.
Workshop
AI Transformation Day
Egésznapos, vezetőknek szóló program. Feltérképezzük, hol tart a szervezet, mi az első reális lépés, és milyen belső feltételek szükségesek a sikerhez. A nap végén konkrét, prioritizált cselekvési lista.
Érdekel a program →