AI-ügynökök tervezése az utasítás injekcióval szembeni ellenállásra

Az AI-ügynökök egyre inkább képesek böngészni a weben, információkat lekérni, és a felhasználó nevében műveleteket végrehajtani. Ezek a képességek nagyon hasznosak, ugyanakkor új lehetőségeket is teremtenek a támadók számára, hogy megpróbálják manipulálni a rendszert.

Az ilyen támadásokat gyakran prompt-injekciónak⁠ nevezik: olyan utasításokat helyeznek el külső tartalmakban, amelyek célja, hogy a modell a felhasználó által valójában nem kért műveletet hajtson végre. Tapasztalataink szerint a valós környezetben a leghatékonyabb ilyen támadások egyre inkább a social engineeringre hasonlítanak, nem pedig egyszerű utasítás-felülírásra.

Ez a változás fontos. Ha a probléma nem csupán egy rosszindulatú karakterlánc azonosítása, hanem a megtévesztő vagy manipulatív tartalommal szembeni ellenállás a kontextus figyelembevételével, akkor a védekezés sem támaszkodhat kizárólag a bemenetek szűrésére. Ehhez arra is szükség van, hogy a rendszert úgy tervezzük meg, hogy a manipuláció hatása korlátozott legyen, még akkor is, ha egyes támadások sikerrel járnak.

A korai „utasítás injekció” jellegű támadások akár olyan egyszerűek is lehettek, mint egy Wikipedia-cikk módosítása, amelyben közvetlen utasításokat helyeztek el az azt meglátogató AI-ügynökök számára. Ha a modellek a tanulás során nem találkoztak ilyen ellenséges környezettel, gyakran kérdés nélkül követték ezeket az utasításokat¹. Ahogy a modellek okosabbá váltak, kevésbé lettek sebezhetőek az ilyen jellegű javaslatokkal szemben, ezért az utasítás injekció támadások is fejlődtek, és social engineering elemeket kezdtek tartalmazni:

A tágabb AI-biztonsági ökoszisztémában gyakran javasolnak olyan technikákat, mint az „AI firewall”, ahol egy köztes rendszer az AI-ügynök és a külvilág között megpróbálja osztályozni a bemeneteket: rosszindulatú utasítás injekció vagy normál tartalom.—Azonban ezek a fejlettebb támadások általában nem akadnak fenn az ilyen rendszereken. Ilyenkor egy rosszindulatú bemenet felismerése gyakorlatilag ugyanolyan nehéz probléma, mint egy hazugság vagy félrevezető információ felismerése, gyakran a szükséges kontextus nélkül.

Ahogy a valós környezetben előforduló utasítás injekció támadások egyre összetettebbé váltak, azt tapasztaltuk, hogy a leghatékonyabb támadási módszerek social engineering taktikákat használnak. Ahelyett, hogy ezeket a social engineering elemeket tartalmazó utasítás injekció támadásokat teljesen új problémaként kezeltük volna, ugyanazzal a szemlélettel kezdtük vizsgálni őket, mint ahogyan az embereket érő social engineering kockázatokat kezelik más területeken. Ezekben a rendszerekben a cél nem az, hogy tökéletesen felismerjük az összes rosszindulatú bemenetet, hanem hogy úgy tervezzük meg az ügynököket és a rendszereket, hogy a manipuláció hatása korlátozott legyen akkor is, ha az sikeres. Az ilyen rendszerek hatékonynak bizonyulnak mind az utasítás injekció, mind a social engineering mérséklésében.

Így az AI-ügynököt elképzelhetjük egy háromszereplős rendszer részeként, hasonlóan egy ügyfélszolgálati munkatárshoz: az ügynök a szervezete érdekében szeretne cselekedni, miközben folyamatosan külső bemeneteknek van kitéve, amelyek kísérletet tesznek a félrevezetésre. Egy ügyfélszolgálati munkatárs, akár ember, akár AI, csak korlátozott jogosultságokkal rendelkezhet, hogy csökkentse annak a kockázatát, amely abból fakad, hogy egy potenciálisan rosszindulatú környezetben működik.

Képzelj el egy olyan helyzetet, amelyben ember üzemeltet egy ügyféltámogatási rendszert, és képes ajándékkártyákat és visszatérítéseket felajánlani az ügyfél által tapasztalt kellemetlenségekért, például a lassú kiszállításért, a meghibásodás következtében keletkezett károkért stb. Ez egy több szereplős probléma, amelyben a vállalatnak bíznia kell abban, hogy az ügynök a megfelelő okokból ajánl visszatérítést, miközben az ügynök harmadik felekkel is kapcsolatba lép, akik megpróbálhatják félrevezetni, vagy akár kényszerhelyzetbe is hozhatják.

A valós világban az ügynök kap egy követendő szabályrendszert, amelyet követnie kell, ugyanakkor számítani kell arra, hogy az ellenséges környezetben, amelyben működik, megpróbálják félrevezetni. Előfordulhat például, hogy egy ügyfél azt állítja, hogy a visszatérítés nem érkezett meg, vagy akár fenyegetéssel próbálja elérni, hogy visszatérítést kapjon. Az ügynök által használt determinisztikus rendszerek korlátozzák például azt, hogy egy ügyfél mennyi visszatérítést kaphat, jelzik a potenciális adathalász e-maileket, és más hasonló védelmi mechanizmusokat biztosítanak annak érdekében, hogy csökkentsék annak hatását, ha egy ügynököt sikerül kompromittálni. 

Ez a szemlélet vezetett ahhoz a robosztus ellenintézkedés-csomaghoz, amelyet bevezettünk, és amely biztosítja a felhasználóink által elvárt biztonsági szintet.

A ChatGPT‑ben ezt a social engineering alapú modellt ötvözzük a hagyományosabb biztonsági mérnöki megközelítésekkel, például az ún. source–sink elemzéssel.

Ebben a megközelítésben egy támadónak két dologra van szüksége: egy forrásra (source), vagyis egy módra, amellyel befolyásolhatja a rendszert, valamint egy „sink”-re, vagyis egy olyan képességre, amely rossz kontextusban veszélyessé válhat. Ügynök-alapú rendszerek esetében ez gyakran azt jelenti, hogy nem megbízható külső tartalom kombinálódik egy művelettel, például: információ továbbítása egy harmadik félnek,egy hivatkozás követése,vagy egy eszközzel való interakció.

A célunk az, hogy megőrizzünk egy alapvető biztonsági elvárást a felhasználók számára: a potenciálisan veszélyes műveletek vagy az érzékeny információk továbbítása nem történhet meg észrevétlenül vagy megfelelő védelmi mechanizmusok nélkül.

A ChatGPT ellen kifejlesztett támadások leggyakrabban arra próbálják rávenni az asszisztenst, hogy egy beszélgetésből származó bizalmas információt egy rosszindulatú harmadik félnek továbbítson. Az általunk ismert esetek többségében ezek a támadások sikertelenek, mivel a biztonsági tréningünk arra készteti az ügynököt, hogy megtagadja az ilyen kéréseket. Azokban az esetekben, amikor az ügynököt mégis sikerül meggyőzni, egy Safe URL nevű védelmi mechanizmust alkalmazunk, mely arra szolgál, hogy felismerje, amikor az asszisztens a beszélgetés során megszerzett információt harmadik fél felé továbbítaná. Ilyenkor vagy megmutatjuk a felhasználónak az elküldendő információt, és megerősítést kérünk,vagy blokkoljuk a műveletet, és arra kérjük az ügynököt, hogy próbáljon meg más módon segíteni a felhasználó kérésének megoldásában.

Ugyanez a mechanizmus érvényes a navigációkra és a könyvjelzőkre az Atlas⁠ esetében; illetve a keresésekre és a navigációkra az mély kutatás⁠ esetében. A ChatGPT Canvas⁠ és a ChatGPT Apps⁠ hasonló megközelítést alkalmaz, lehetővé téve az ügynök számára, hogy funkcionális alkalmazásokat hozzon létre és használjon—ezek egy olyan sandboxban futnak, amely képes észlelni a váratlan kommunikációt, és a felhasználó hozzájárulását kérni⁠(új ablakban nyílik meg).

További információkat olvashatsz a Safe Urlről, és a felépítéséről szóló dokumentumot is találsz az erről szóló blogbejegyzésében: Aadataid biztonságban tartása, amikor egy AI-ügynök egy linkre kattint⁠.

A biztonságos interakció az ellenséges külső környezettel elengedhetetlen a teljes mértékben autonóm AI-ügynökök számára. Amikor egy AI-modellt egy alkalmazási rendszerrel integrálunk, azt javasoljuk, hogy tegyük fel a kérdést: milyen kontrollokra lenne szüksége egy emberi ügynöknek hasonló helyzetben, és ezeket a kontrollokat építsük be a rendszerbe. Arra számítunk, hogy egy maximálisan intelligens AI-modell bizonyos esetekben jobban ellen tud állni a social engineering támadásoknak, mint egy emberi ügynök, azonban ez nem minden alkalmazásnál valósítható meg vagy költséghatékony.

Továbbra is vizsgáljuk a social engineering támadások AI-modellekre gyakorolt hatásait, valamint az ezek elleni védekezési módszereket, és az eredményeinket beépítjük mind az alkalmazásbiztonsági architektúráinkba, mind pedig az AI-modellek tréningfolyamataiba.