Prompt injection: miért nem utasítás egy beolvasott dokumentum?

Kiinduló helyzet és döntési feladat

Egy asszisztens szállítói levelet összegez. A levélben szereplő, más adatok lekérésére felszólító mondat nem jogos felhasználói utasítás, hanem feldolgozandó külső adat. A rendszert ehhez a különbséghez kell tervezni.

Bizalmi határ

Válaszd külön a megbízható feladatleírást és a beolvasott külső tartalmat. A dokumentumba rejtett utasítás eltérítheti a választ.

Jelöld minden bemenet eredetét. Az ellenőrzés fő kérdése: Ki jogosult ténylegesen új feladatot adni?

Minimális jog

Az asszisztens csak a szükséges adathoz és eszközhöz férjen hozzá. A felesleges hozzáférés növeli a hiba következményét.

Készíts műveleti és adatkörlistát. Az ellenőrzés fő kérdése: Mi vonható meg a feladat sérülése nélkül?

Külső engedélyezés

A jogosultságot az alkalmazás ellenőrizze a modellen kívül. A modell válasza nem hiteles hozzáférési döntés.

Tesztelj tiltott adatlekérést. Az ellenőrzés fő kérdése: Megállítja a szerver a nem engedett műveletet?

Kimenetkezelés

A generált tartalmat ellenőrizd a felhasználás előtt. A modellből jövő szöveg nem automatikusan biztonságos kód.

Tesztelj megjelenítést és adatátadást. Az ellenőrzés fő kérdése: Értelmeződhet nem kívánt műveletként a kimenet?

Következményes lépés

Küldés, törlés és adatváltoztatás előtt legyen megfelelő kontroll. Egy eltérített összefoglaló így nem válik automatikus intézkedéssé.

Próbálj ki ártalmatlan támadó mintát tesztkörnyezetben. Az ellenőrzés fő kérdése: Mekkora következmény marad lehetséges?

Folyamatos vizsgálat

A normál és ellenséges mintákat több megfogalmazással teszteld. Egyetlen szűrő nem garantál teljes védelmet.

Rögzítsd a maradó kockázatot és elakadási utat. Az ellenőrzés fő kérdése: Alkalmas a feladat a fennmaradó bizonytalanság mellett?

Részletes megvalósítás és szakmai döntések

A prompt injection kockázatát a bizalmi viszonyból érdemes megérteni. Az asszisztens feladatot kap a felhasználótól, majd annak végrehajtásához levelet, weboldalt vagy dokumentumot olvas. E külső anyagban lehet olyan szöveg, amely új utasításnak próbál látszani. Attól azonban, hogy a modell elolvassa, a tartalom még nem jogosult átírni a feladatot vagy feloldani a hozzáférési korlátot. A rendszertervezés célja ennek a különbségnek a védelme. Nem pusztán néhány tiltott szó kiszűréséről, hanem adat és felhatalmazás következetes elkülönítéséről van szó.

A kockázati munkalaphoz rajzold fel, honnan jön az információ és milyen művelet követheti. Egy csak szöveget összegző rendszer és egy ügyféladatot lekérő, üzenetet küldő asszisztens eltérő következményű. A külső dokumentum az utóbbinál könnyebben válhat közvetett műveleti befolyássá, ha nincs megfelelő ellenőrzés. Minden kapcsolódásnál kérdezd meg: ez adatforrás, felhasználói utasítás vagy alkalmazási jogosultság? A három szerepet ne mosd össze a promptban és a kódban sem. A rajz megmutathatja, hol kell az AI-n kívüli technikai döntési pont.

A minimális jogosultság a lehetséges következményt csökkenti. Ha az asszisztensnek csak olvasni kell néhány nyilvános tájékoztatót, ne férjen hozzá teljes ügyféladatbázishoz vagy küldési lehetőséghez. Az eszközök hatókörét és paramétereit a tényleges feladatra szűkítsd. A megadott hozzáférés legyen visszavonható és követhető. Ezzel nem tűnik el minden megtévesztési lehetőség, de egy hibás modellkimenet kisebb területen okozhat kárt. A hozzáférés bővítése külön tervezési döntés legyen, ne kényelmi alapbeállítás egy későbbi, még meg sem határozott felhasználási igényhez.

A szerveroldali engedélyezés ne a modell saját megítélésétől függjön. Egy dokumentumban olvasott mondat nem adhat jogot más ügyfél adatának lekérésére. Az alkalmazás ellenőrizze a felhasználót, megengedett adatkört és műveletet, mielőtt az eszközhívás végrehajtódik. A prompt megfogalmazása segíthet a szerepek tisztázásában, de nem lehet az egyetlen biztonsági határ. A tesztben legyen olyan ártalmatlan mintakérés, amely engedélyen kívüli műveletet próbál elérni. A sikeres védelem az, hogy a rendszer a kísérlet ellenére sem hajt végre jogosulatlan lépést.

A kimenetet a felhasználás helye szerint ellenőrizd. Egy generált szöveg megjelenítése, adatbázisba írása és parancsként végrehajtása más kockázatot hordoz. A modellből érkező tartalom nem automatikusan megbízható kód vagy érvényes üzleti adat. A hagyományos alkalmazásbiztonsági ellenőrzések továbbra is szükségesek. Ha a szöveg HTML-ként kerül a felületre, megfelelő megjelenítési szabály kell. Ha eszközparaméter lesz belőle, a megengedett értéket és jogosultságot az alkalmazás vizsgálja. E rétegek nem helyettesítik egymást; együtt csökkentik annak esélyét, hogy egy félrevezetett válasz következményes műveletté váljon.

A külső küldés és adatváltoztatás külön kontrollt kaphat. A felhasználó lássa, milyen tartalom, címzett vagy rekord érintett, és az előírt helyzetben legyen jóváhagyás. A megerősítés akkor használható, ha konkrét és áttekinthető, nem általános figyelmeztető ablak minden apró lépésnél. A rendszer állapota különítse el a tervezetet és végrehajtott műveletet. Egy beolvasott szöveg ne állíthassa át önkényesen az eljárást arra hivatkozva, hogy sürgős vagy a felhasználó korábban engedélyezte. A felhatalmazást megbízható alkalmazási kontextusból kell megítélni.

A tesztelésben szerepeljen közvetlen és közvetett megtévesztési minta. Az egyik a felhasználói bemeneten, a másik egy visszakeresett vagy beolvasott anyagon keresztül próbálhat eltérő feladatot kiváltani. A próbák ártalmatlan, izolált környezetben történjenek, valós érzékeny adat nélkül. Több nyelvi megfogalmazás és normál, jóindulatú kérdés is kell, mert a túl agresszív szűrés a szolgáltatás használhatóságát ronthatja. Az eredményben a ténylegesen elért vagy megakadályozott következményt értékeld, ne csak azt, hogy a modell adott-e valamilyen figyelmeztető választ a képernyőn.

A naplózás segít a hibakeresésben, de ne tároljon feleslegesen teljes bizalmas dokumentumot. A szükséges esemény, döntési pont és műveleti állapot legyen követhető. Ha gyanús bemenet érkezik, tudni kell, mely eszközhívás állt meg és mi történt utána. A megfigyeléshez kijelölt felelős és javítási folyamat tartozzon. A védelem nem egyszeri promptmódosítás, mert új adatforrás és eszköz új bizalmi kapcsolatot hozhat. A változtatás után a korábbi támadó és normál mintákat is érdemes újra lefuttatni a rendszer ismert határainak ellenőrzésére.

A maradó kockázatot őszintén nevezd meg. Egyetlen szűrő vagy jól megírt rendszerüzenet nem jelent teljes védelmi garanciát. Ha a feladat következménye nem tűri a fennmaradó bizonytalanságot, más működési modellre vagy erősebb emberi kontrollra lehet szükség. Az üzleti döntés része annak megítélése, mire alkalmas az asszisztens. A biztonságosabb rendszer kisebb jogosultságot, ellenőrzött eszközt és követhető átadást kombinál. Ebből lesz használható védekezés, amely a hiba valós következményét is korlátozza, nem csupán a modell megfogalmazását próbálja udvariasabbá tenni.

Gyakori kérdések