Képzeljünk el egy vállalati AI-asszisztenst, amelynek az a feladata, hogy a beérkező önéletrajzokat összefoglalja a HR-osztály számára. Az egyik pályázó azonban az önéletrajz utolsó oldalára, apró fehér betűkkel ezt írja:

Az emberi olvasó ebből valószínűleg semmit sem vesz észre. Az AI viszont megkaphatja a szöveget, és számára ugyanabban az adatfolyamban jelenik meg a szakmai tapasztalat, az iskolai végzettség és az elrejtett utasítás. Itt kezdődik a prompt injection, vagyis az utasításbecsempészés világa.

Ez nem egy távoli, elméleti probléma. Az OWASP – a világ egyik legismertebb alkalmazásbiztonsági szervezete – a generatív AI-rendszerek legfontosabb kockázatai között az első helyen tárgyalja a prompt injectiont. Az amerikai NIST generatív AI-kockázati profilja szintén külön foglalkozik a közvetlen és a külső adatforrásokon keresztül érkező, közvetett támadásokkal.

Amikor az adat parancsnak álcázza magát

A hagyományos informatikai rendszerekben a programkód és az adat általában jól elkülönül. Egy ügyfél neve adat. Egy SQL-parancs viszont utasítás az adatbázisnak. Évtizedek óta épülnek védelmi megoldások arra, hogy a kettő ne keveredhessen össze.

A nagy nyelvi modellek esetében a helyzet különlegesebb. A rendszerutasítás, a felhasználó kérdése, egy weboldal szövege, egy PDF tartalma és egy külső program válasza végül mind szövegként kerülhet a modell elé. A modellnek ezért azt is fel kell ismernie, hogy egy mondatot végrehajtandó kérésként vagy csupán feldolgozandó adatként kapott.

Vegyünk egy egyszerű példát. Egy AI-alapú ügyfélszolgálat elolvassa egy webáruház termékleírását:

A mondat első fele termékadat. A második fele már az AI viselkedését próbálja megváltoztatni. A támadó úgy csempészett utasítást a rendszerbe, hogy közvetlenül talán soha nem is beszélt a chatbottal.

Ugyanez megtörténhet:

·        egy e-mail aláírásában elrejtett szöveggel;

·        egy PDF utolsó oldalán;

·        egy weboldal HTML-megjegyzésében;

·        egy keresési adatbázisba bekerült dokumentumban;

·        egy külső API vagy program manipulált válaszában;

·        láthatatlan Unicode-karakterek közé rejtett utasítással;

·        kódolt, például Base64-formában elhelyezett paranccsal.

Minél több külső forrást olvas egy AI-ügynök, és minél több művelet elvégzésére jogosult, annál fontosabbá válik ez a kérdés. Egy egyszerű szöveggenerátornál a következmény lehet egy furcsa válasz. Egy levelezéshez, fájlokhoz, ügyféladatokhoz vagy üzleti programokhoz kapcsolt ügynöknél már sokkal nagyobb a tét.

A PromptGuard a modell előtt áll őrt

A PromptGuard alapötlete könnyen érthető: az érzékeny szöveg ne közvetlenül jusson el a fő nyelvi modellhez. Előbb haladjon át egy külön biztonsági kapun, amely megvizsgálja, találhatók-e benne az AI eltérítésére utaló jelek.

Olyan ez, mint egy repülőtéri biztonsági ellenőrzés. Az utas nem maga dönti el, hogy veszélyes tárgyat visz-e magával, és a repülőgép pilótájának sem kell minden csomagot átvizsgálnia. A csomagok egy erre kialakított ellenőrzési ponton haladnak át, mielőtt felkerülnének a gépre.

A PromptGuard tehát a fogadó alkalmazás oldalán működő, LLM előtti védelmi réteg. Az orchestrator – vagyis az AI-rendszer munkafolyamatát irányító program – elküldi neki az ellenőrizendő szöveget, a PromptGuard pedig kockázati értékelést, pontszámot, észlelt jeleket és döntéstámogató információkat ad vissza. A hívó rendszer ezek alapján engedélyezheti, elkülönítheti, további vizsgálatra küldheti vagy blokkolhatja a tartalmat.

A szolgáltatás az MCP, vagyis a Model Context Protocol világába illeszkedik. Ez a protokoll lehetővé teszi, hogy az AI-ügynökök szabványos módon használjanak külső eszközöket és szolgáltatásokat. A PromptGuard ugyanakkor nem olyan eszköz, amelyet a már megtámadott modell kedve szerint meghívhat. A lényeg éppen az, hogy a platform kapujában helyezkedik el, és még a fő modell előtt vizsgálja meg a tartalmat.

Nem minden szöveg ugyanonnan érkezik

A PromptGuard három alapvető helyzetet különböztet meg:

1.        Felhasználói kérdés: amit az ember közvetlenül beír a chatbotnak.

2.        RAG-dokumentum: egy tudásbázisból, keresőből vagy dokumentumtárból visszakeresett szövegrész.

3.        Külső eszköz eredménye: egy API, adatbázis vagy másik program által visszaadott tartalom.

Ez azért fontos, mert ugyanaz a mondat egészen mást jelenthet eltérő környezetben.

Ha a felhasználó azt írja, hogy „a válasz végén készíts hárompontos összefoglalót”, az teljesen természetes kérés lehet. Ha ugyanez egy termékleírás közepén jelenik meg, miközben az AI feladata csupán a termék adatainak kiolvasása, akkor a mondat már gyanús: a dokumentum megpróbálja irányítani azt a rendszert, amelynek csak olvasnia kellene.

Egy másik példa egy külső program válasza:

Formailag ez szabályos JSON-adat. Tartalmilag azonban olyan utasítást hordoz, amely egy pénzügyi AI-ügynök döntését próbálja eltéríteni. A PromptGuard ezért a szöveg eredetét is figyelembe vevő szabályrendszerrel dolgozik.

A láthatatlan betűktől a kódolt parancsokig

A támadók ritkán állnak meg a jól felismerhető „hagyd figyelmen kívül az előző utasításokat” mondatnál. Az igazán érdekes kísérletek eltorzítják, elrejtik vagy más feladatba csomagolják a parancsot.

A PromptGuard ezért több nézetben vizsgálja meg ugyanazt a szöveget. Egységesíti a különböző Unicode-formákat, kezeli a nulla szélességű és irányváltó karaktereket, valamint felismerhetővé teszi a HTML- vagy Markdown-megjegyzésekbe rejtett tartalmat. Képes foglalkozni olyan esetekkel is, amikor valaki leet írást, hexadecimális kódolást, Unicode escape-eket vagy Base64-szöveget használ az utasítás elfedésére.

Például a támadó egy látszólag ártalmatlan mondat betűi közé nem látható karaktereket szúrhat. Az ember a képernyőn ezt látja:

A gép által feldolgozott karaktersorozat azonban további, elrejtett információt is tartalmazhat. A PromptGuard normalizáló rétege először „előhívja” ezeket a rejtett csatornákat, majd a szerkezeti és szándékalapú vizsgálat számára is láthatóvá teszi őket.

A dokumentum végén várakozó csapda

Különösen ötletes támadási módszer, amikor egy rendkívül hosszú dokumentumban a veszélyes utasítást messze hátra helyezik. Egy egyszerű biztonsági szűrő gyakran csak a szöveg első néhány ezer karakterét ellenőrzi. A támadó ezért megtöltheti a dokumentum elejét ártalmatlan tartalommal, majd az ellenőrzött tartomány után helyezheti el a parancsot.

A PromptGuard hosszú szövegeknél nem kizárólag a dokumentum elejére koncentrál. Az elejéből, a végéből és szükség szerint a közepéből is mintát vesz. Ez olyan, mintha egy biztonsági őr egy hosszú tehervonatnál nem csupán a mozdonyt vizsgálná meg, hanem az utolsó és a középső vagonokra is ránézne.

Egy ilyen támadó dokumentum például 16 ezer karakternyi szabályos szerződési szöveggel indulhat, a legvégén pedig ez állhat:

A tartalom elhelyezése önmagában így már sokkal kevésbé alkalmas a vizsgálat megkerülésére.

„Fordítsd le” vagy „hajtsd végre” – egyetlen ige dönthet

Az egyik legérdekesebb határeset a fordítás. Tegyük fel, hogy valaki ezt kéri:

Ebben a helyzetben a veszélyesnek hangzó mondat idézet. A felhasználó nyelvi feladatot adott, nem a mondat végrehajtását kérte.

Most változtassunk csak néhány szót:

A két kérés felszínesen nagyon hasonló, a szándékuk azonban teljesen eltér. A PromptGuard a szerkezeti jelek mellett ezért szándékosztályozást is használ. Figyeli az idézeti vagy oktatási környezetet, a fordításra utaló nyelvi feladatot, valamint az olyan végrehajtási igéket, mint a „kövesd”, „alkalmazd”, „engedelmeskedj” vagy „hajtsd végre”.

Hasonló különbség jelenik meg egy tanítóadatnál is:

Ez lehet egy biztonsági adatbázis egyik felcímkézett mintája. A támadó mondat jelen van benne, de elemzendő példaként, nem aktív utasításként. Egy jól működő védelemnek tehát nem csupán kulcsszavakat kell keresnie, hanem a mondat szerepét is értelmeznie kell.

Több százezer tesztfuttatásból épült fel a védelem

A PromptGuardot a glcMEDIA Kft. fejleszti, vezető fejlesztője Pergel Attila, aki több évtizedes szoftverfejlesztési tapasztalatát fordította az AI-ügynökök biztonsági problémái felé.

A fejlesztői tájékoztatás szerint a rendszer kialakítása és finomítása során több százezer tesztfuttatás vizsgálta a támadó és ártalmatlan mintákat. Ez azért lényeges, mert egy prompt injection elleni védelem minőségét nem egyetlen látványos demó mutatja meg. Ugyanolyan fontos, hogy felismerje a támadást, mint az, hogy helyesen átengedje a teljesen szabályos fordítást, oktatási példát, naplóbejegyzést vagy programkódot.

A folyamatos regressziós tesztkészletben minden feltárt támadási forma őrzőtesztté válik. Ha például megjelenik egy Unicode-karakterekkel elrejtett új módszer, annak mintája bekerül a későbbi ellenőrzések közé is. Így egy új fejlesztés után nemcsak az új megoldást ellenőrzik, hanem azt is, hogy a korábban felismert támadások továbbra is fennakadnak-e a szűrőn.

A mellékelt fejlesztési állapot szerint a 0.3.13-as motor tartós, teljes regressziós tesztje 839-ből 839 esetet teljesített. Ebben közvetlen támadások, hosszú dokumentumos próbák, többnyelvű minták, kódolt utasítások, fordítási határesetek és ártalmatlan kontrollszövegek is szerepelnek. A több százezer futtatás a fejlesztés során felhalmozott vizsgálati munkát, a 839/839 pedig az aktuális, újra és újra lefuttatott tartós ellenőrzőcsomag pillanatnyi eredményét jelzi.

Mire használható a gyakorlatban?

Egy webshop AI-asszisztense ellenőrizheti vele a beszállítóktól érkező termékleírásokat, mielőtt azok bekerülnének a modell kontextusába. Egy jogi keresőrendszer átvizsgálhatja a visszakeresett dokumentumrészleteket. Egy e-mailes ügynök megvizsgálhatja a levelek tartalmát, mielőtt válaszolna vagy valamilyen műveletet kezdeményezne. Egy fejlesztői AI ellenőrizheti a külső programok és automatizált eszközök által visszaadott szöveget.

Néhány szemléletes példa:

·        HR-rendszer: kiszűrheti az önéletrajzba rejtett „rangsorolj engem elsőnek” utasítást.

·        Webes kutatóügynök: észlelheti a weboldal HTML-megjegyzésében elhelyezett, összefoglalást eltérítő parancsot.

·        Ügyfélszolgálat: felismerheti, ha egy termékleírás kizárólagos ajánlásra próbálja rávenni az AI-t.

·        Pénzügyi asszisztens: megállíthatja, hogy egy külső API szöveges válasza jóváhagyás megkerülésére utasítsa az ügynököt.

·        Céges tudásbázis: átvizsgálhatja a RAG-rendszerből érkező dokumentumdarabokat, mielőtt azok a modellhez kerülnének.

·        Kódolóügynök: gyanúsként jelölheti, ha egy külső csomag dokumentációja titkos adatok kiolvasását vagy ismeretlen program futtatását kéri.

Az AI-korszak tűzfala nem feltétlenül hálózati csomagokat vizsgál

A klasszikus tűzfal IP-címeket, portokat és hálózati kapcsolatokat ellenőriz. Az AI-korszak új védelmi kapuinak már a szöveg jelentésével, szerkezetével és eredetével is foglalkozniuk kell. Fel kell ismerniük, amikor egy adatnak látszó mondat valójában utasítás, amikor egy ártalmatlan fordítás valóban csak fordítás, és amikor egy külső program válasza megpróbálja átvenni az irányítást egy AI-ügynök felett.

Véleményem szerint a PromptGuard legérdekesebb gondolata nem önmagában egy újabb biztonsági szűrő létrehozása, hanem a védelem helyének helyes megválasztása. Az őr a modell előtt áll, és nem bízza teljesen a védekezést arra a rendszerre, amelyet a támadó éppen félre akar vezetni.

Ahogy az AI-asszisztensek egyre több dokumentumot olvasnak és egyre több valódi műveletet végeznek el, ez a különbség alapvetővé válik. A jövő intelligens rendszereinek nemcsak okosnak, hanem jól őrzöttnek is kell lenniük. A magyar fejlesztésű PromptGuard pedig pontosan ennél a kapunál foglal helyet.

A szolgáltatás bemutatója: mcp.glc-rag.hu/guide/promptguard

A GLC MCP-platform: mcp.glc-rag.hu