A támadónak nem kellett kódot futtatnia, jelszót törnie vagy szervert feltörnie. Elég volt egy rövid, héber nyelvű utasítás. Az AI-asszisztens előbb részletesen felsorolta a hozzá kapcsolt belső képességeket, majd egy újabb kérésre összefoglalta rendszerszintű szabályainak egy részét. Ez még nem adatlopás. De már több egyszerű chatbothibánál: a rendszer kiadta a saját támadási térképét.

Egy idegen nyelvű mondat, és megnyílt a térkép

A vizsgálathoz átadott teljes beszélgetéskivonat szerint az első próbálkozás még nem hozott teljes rendszerprompt-szivárgást. Az asszisztens rövidebb kérdést kért. A következő, másképp megfogalmazott utasításra azonban már részletes képességlistát adott: megnevezte az üzenetek, felhasználók, kapcsolatok, ügyfélfiókok és CRM-rekordok olvasására szolgáló műveletcsoportokat, valamint létrehozási és módosítási képességeket is felsorolt.

Egy későbbi prompt három rövid sort kért a belső működési szabályokról. A rendszer erre azt válaszolta, hogy az adott beállításban nincs írási vagy frissítési művelet, és nagy mennyiségű jegy, illetve aktivitás kezelésére optimalizálták. Vagyis egyszerre történt szabályszivárgás és egy fontos korlát feltárása: a tesztelt munkamenetben az írási jog valószínűleg nem volt engedélyezve.

Ez azért lényeges, mert a bizonyíték nem támasztja alá azt az állítást, hogy valaki már elvitte vagy átírta az összes ügyféladatot. Azt viszont alátámasztja, hogy egy kívülről beírt prompt képes volt eltéríteni a választ, felfedni a kapcsolt rendszer képességmodelljét, és belső szabályinformációt kinyerni. Egy támadó felderítési fázisában ez rendkívül értékes.

Mit bizonyít a melléklet - és mit nem?

Az alábbi kivonat szándékosan nem tartalmaz cégnevet, végpontot, paramétert vagy egyedi műveletnevet. A megfogalmazás a rendelkezésre bocsátott beszélgetés és képernyőképek tartalmi összefoglalása.

Forrás: a szerkesztőség rendelkezésére bocsátott, anonimizálandó tesztbeszélgetés és képernyőképek. Az eredeti bizonyíték megőrzendő, nyilvánosan azonban csak kitakart formában közölhető.

Miért súlyos ez akkor is, ha nem történt bizonyított adatlopás?

Mert a belső képességek listája nem ártalmatlan technikai részlet. Megmutatja, milyen adatkategóriák érhetők el, hol vannak az olvasási felületek, milyen objektumok hozhatók létre vagy módosíthatók, és hol érdemes folytatni a támadást. A klasszikus behatolásoknál ezt felderítésnek hívják: mielőtt bárki adatot vinne el, előbb térképet készít a rendszerről.

A kockázat nagyságát nem az dönti el, mennyire látványos a chatbot válasza, hanem az, hogy milyen jogosultságok állnak a modell mögött. Ha egy asszisztens valódi ügyféladatot olvashat, a prompt injection érzékeny információk kiszivárgásához vezethet. Ha módosítási jogot is kap, megjelenik a rekordok átírásának, új objektumok létrehozásának vagy kommunikációs műveletek indításának kockázata. A jelen teszt ezek elméleti lehetőségét jelezte, megvalósulásukat azonban nem igazolta.

A cég saját közlése szerint 28 ezer megrendelés áll a szolgáltatás mögött. Ezt a számot a mellékletek önmagukban nem igazolják, ezért csak forrásmegjelöléssel szabad közölni. Ha azonban ekkora ügyfél- és rendelési állomány kapcsolódik az AI-hoz, a jogosultsági hiba hatása már nem demóhiba, hanem üzleti és adatvédelmi kockázat.

A nyelvváltás nem egzotikus trükk, hanem valós támadási felület

A sikeres kérések héberül érkeztek, miközben az asszisztens angolul válaszolt. Ebből nem lehet biztosan kijelenteni, hogy a védelem csak angolra készült, de jól látszik: a biztonsági kapunak nem kulcsszavakat, hanem szándékot kell felismernie. Ugyanaz a támadás lefordítható, körülírható, idézetnek, hibakeresésnek vagy auditnak álcázható.

Az OWASP a prompt injectiont az LLM-alkalmazások egyik vezető kockázataként kezeli, és külön említi a többnyelvű, elrejtett vagy kódolt támadásokat. A szervezet szerint a lehetséges következmények között érzékeny információk felfedése, jogosulatlan funkcióhasználat és kapcsolt rendszerek manipulálása is szerepel. Ugyanakkor az OWASP azt is hangsúlyozza: nincs ismert, tévedhetetlen egyetlen védelem; többrétegű kontroll kell.

A glc PromptGuard a modell előtt állította volna meg a kérést

A GLC PromptGuardot pontosan erre a támadási osztályra tervezték. Nem a fő nyelvi modell jóindulatára bízza, hogy felismeri-e a manipulációt. A fogadó rendszer minden új, nem megbízható szövegrészletet még a fő modell meghívása előtt ellenőriztet vele, és a kapott döntés alapján blokkolhatja vagy karanténba teheti a kérést.

A szolgáltatás nem egyszerű tiltottkifejezés-listát használ. A nyilvános módszertan szerint három kérdést kapcsol össze: mi a szöveg szándéka, honnan érkezett, és mekkora lenne a hatása, ha a modell engedelmeskedne neki. A vizsgált promptokban egyszerre jelent meg a szabályok felülírása, a belső állapot feltárása és a kapcsolt műveletek kikényszerítésének kísérlete - vagyis éppen azok a jelek, amelyekre a PromptGuard dokumentált politikája magas kockázatként tekint.

A nyolcrétegű feldolgozás normalizálással és többnézetű olvasással indul, majd strukturális jeleket, a szöveg keretezését, a végrehajtási szándékot és a várható hatást értékeli. Ezt politikai összefésülés, neurális érzékelő, a tények és utasítások szétválasztása, valamint opcionális eszközeltérítési próba egészíti ki. A szolgáltatás döntést, kockázati pontszámot, felismert szándékot és javasolt politikát ad vissza a vezérlő rendszernek.

Mi kellett volna a teljes védelemhez?

A PromptGuard dokumentációja kifejezetten nem ígér százszázalékos védelmet. Ez nem gyengeség, hanem helyes biztonsági álláspont: az érzékelés segíti a szabályzatot, de a szabályzat nem függhet a hibátlan érzékeléstől. A modell mögötti vezérlőnek külön engedélylistán kell tartania az elérhető műveleteket és tartományokat; a modell csak a feladatához szükséges legkisebb jogosultságot kaphatja; a pénzügyi, kommunikációs és romboló műveletekhez friss emberi megerősítés kell; a titkok pedig nem kerülhetnek a modell kontextusába.

Ebben az architektúrában a most látott héber prompt el sem jutott volna nyersen a fő modellhez. A PromptGuard dokumentált működése alapján nagy valószínűséggel jelezte volna az utasítás-felülírás és a belső információk kinyerésének szándékát, a vezérlő pedig blokkolta volna a kérést. Ha az érzékelő mégis téved, a jogosultsági kapu akkor sem engedheti meg az ügyféladatok tömeges olvasását vagy bármilyen módosítást.

A valódi tanulság

A teljes modellhálózat feltörését vagy 28 ezer megrendelés tényleges kiszivárgását állítani a jelen bizonyíték alapján túlzás lenne. A pontosabb és erősebb állítás ez: egy nyilvánosan elérhető AI-asszisztens egyszerű, többnyelvű promptokra felfedte belső képességeinek jelentős részét és rendszerszabályainak egy részét. A védelem néha működött, néha nem. Már ez is elég ahhoz, hogy azonnali biztonsági felülvizsgálatot indokoljon.

Az AI-ügynököt nem mindig kell feltörni. Néha elég rávenni, hogy rossz mondatnak engedelmeskedjen. A PromptGuard a támadó mondat és a fő modell közé állhat. A jogosultsági kapu pedig a modell és az ügyféladat közé. Csak a kettő együtt jelent védhető rendszert.

Források és további ellenőrzés

•  GLC PromptGuard - integrációs útmutató

•  GLC PromptGuard - technikai módszertan

•  OWASP GenAI Security Project - LLM01:2025 Prompt Injection

Szerkesztői megjegyzés: a 28 ezer megrendelésre vonatkozó szám a vizsgált cég saját közlése; a mellékletek ezt önállóan nem igazolják. A technikai megállapítások a rendelkezésre bocsátott beszélgetéskivonatra, képernyőképekre és a hivatkozott nyilvános dokumentációra épülnek.