AI biztonsági kockázatok · Lecke 01

Miért más az AI biztonsága

A nyelvi modellek nem úgy működnek, mint a hagyományos szoftver, ezért a védekezés sem lehet ugyanaz. Ebben a leckében megnézzük, miért mosódik össze az utasítás és az adat, miért nem lehet egyetlen szabállyal lezárni a kockázatot, és milyen két hiteles keretre épül ez a kurzus.

Vissza a tananyaghoz


A régi feltevés, ami itt már nem áll

A hagyományos szoftverbiztonság egy erős feltevésre épül. A program logikáját a kód rögzíti, a felhasználó bemenete pedig adat, amit a program feldolgoz. A kettő élesen elválik. A fejlesztő pontosan tudja, mit tesz a rendszer, mert minden ágat kódban írt le. Ezért a klasszikus védekezés a bemenet szűréséről, a jogosultságok kezeléséről és a kód hibáinak javításáról szól. Egy nyelvi modellnél ez a feltevés megdől. A modell nem determinisztikus szabályokat futtat, hanem természetes nyelvi utasításokra reagál, és a legfontosabb különbség az, hogy az utasítás és a feldolgozandó adat ugyanabban a szövegcsatornában, a kontextusablakban érkezik.


HAGYOMÁNYOS SZOFTVER Kód a logika Adat a bemenet elválik NYELVI MODELL egyetlen kontextusablak rendszerprompt (utasítás) felhasználói kérés külső tartalom (adat)
A hagyományos rendszerben a kód és az adat két külön réteg. A nyelvi modellnél az utasítás és az adat ugyanabba a kontextusablakba kerül, és a modell mindet szövegként dolgozza fel.

Az utasítás és az adat összemosódása

Ez az összemosódás a legtöbb AI biztonsági probléma gyökere. Ha egy modell egy weboldal szövegét, egy beérkezett emailt vagy egy feltöltött dokumentumot olvas be, akkor ez a tartalom elvileg adat. A modell számára viszont ez is csak szöveg a kontextusablakban, ugyanolyan, mint a valódi utasítás. Ha a beolvasott tartalomba valaki elrejt egy parancsot, a modell hajlamos utasításként kezelni. A klasszikus rendszerben egy Excel cellába írt mondat sosem futott le programként. Egy nyelvi modell viszont pont arra készült, hogy a szövegben megfogalmazott kéréseket teljesítse, és nem tud megbízhatóan különbséget tenni aközött, mi a fejlesztő szándéka és mi egy külső fél becsempészett kérése.


Valószínűségi, nem determinisztikus

A másik alapvető különbség, hogy a modell kimenete valószínűségi. Ugyanarra a bemenetre kicsit eltérő választ adhat, és a viselkedése nem írható le teljes döntési fával. Ebből két dolog következik. Egyrészt a védekezés nem lehet egyetlen szabály, mert a modell viselkedése nem egyetlen kapcsoló. Másrészt nem lehet a rendszert teljesen letesztelni úgy, ahogy egy hagyományos programot, hiszen a lehetséges bemenetek tere a teljes természetes nyelv. A biztonság ezért itt nem egy állapot, amit egyszer elérünk, hanem folyamatos mérés, megfigyelés és korrekció.


Hagyományos szoftver

  • Kód és adat élesen elválik
  • Determinisztikus, kiszámítható
  • Teljes lefedettséggel tesztelhető
  • A szabályok kódban rögzítettek

Nyelvi modell

  • Utasítás és adat egy csatornában
  • Valószínűségi, nem teljesen kiszámítható
  • A bemenetek tere a teljes nyelv
  • A viselkedést a tanítás alakítja

Az új támadási felület

A modellréteg megjelenésével új támadási felület nyílik, amit a régi eszköztár nem fed le. A támadó nem feltétlenül a kódba tör be, hanem magát a modellt manipulálja szöveggel. A leggyakoribb belépési pontok a becsempészett utasítás a bemeneten át, a modell határainak megkerülése, a tanítóadat manipulálása, az érzékeny adat kicsalása, és az eszközökhöz adott túl széles jogosultság. A régi védelem, a tűzfal, a hálózati szegmentálás és a jogosultságkezelés továbbra is szükséges, de egyik sem véd a modell szövegszintű manipulálása ellen. Ezt a réteget külön kell kezelni.


Prompt injekció és jailbreakbemeneti réteg
Érzékeny adat kiszivárgásakimeneti réteg
Ügynökök túlzott jogosultságaeszközréteg
Adatmérgezéstanítási réteg

Két hiteles keret, amire ez a kurzus épül

A rendezett tárgyaláshoz két nemzetközileg elismert anyagot használunk. Az OWASP Top 10 for LLM Applications a nyelvi modellekre épülő alkalmazások tíz legfontosabb kockázatát sorolja fel, konkrétan és technikailag. A NIST AI Risk Management Framework ennél tágabb, önkéntesen alkalmazható keret, amely négy funkció köré szervezi a kockázatkezelést. Ez a négy funkció a kormányzás, a feltérképezés, a mérés és a kezelés, angolul Govern, Map, Measure és Manage. A kettő jól kiegészíti egymást. Az OWASP a konkrét kockázatokat nevezi meg, a NIST pedig azt a rendszert adja, amelyben ezeket a kockázatokat végig lehet vinni a szervezetben.


4

Négy funkció a NIST keretében. A Govern a felelősség és a szabályok kereteit teremti meg, a Map feltérképezi a kontextust és a kockázatokat, a Measure méri és elemzi a rendszert, a Manage pedig a kockázatok kezeléséről és a prioritásokról dönt. A négy funkció együtt, folyamatosan ismételve működik.


Következő lecke →

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 →