Netiesioginė promptų injekcija: vien filtro DI agentui nepakanka

DI agentą, kuris skaito išorinius duomenis ir gali atlikti veiksmus, saugokite keliose vietose: atskirkite gautą turinį nuo nurodymų, suteikite tik užduočiai būtinas teises, tikrinkite įrankių iškvietimus ir reikalaukite patvirtinimo prieš jautrų veiksmą. OWASP DI agentų saugumo gairėse greta promptų injekcijos įvardijamas piktnaudžiavimas įrankiais, duomenų nutekinimas, atminties užnuodijimas ir perteklinė autonomija.

Teksto filtras gali aptikti žinomą įtartiną formuluotę, tačiau sprendimą vykdyti veiksmą turi priimti sistemos dalis, kuri tikrina naudotojo teises ir gali sustabdyti įrankį. Todėl verta iš anksto įvertinti, kas nutiktų agentui perskaičius užpuoliko pakeistą laišką, dokumentą arba įrankio atsakymą.

Atsekite kelią nuo išorinio turinio iki veiksmo

Netiesioginės injekcijos pradžia yra šaltinis, kurį agentas naudoja užduočiai atlikti, nors jo turinio nekontroliuoja užduotį pateikęs naudotojas. NIST atakų taksonomija šį kelią sieja su užpuoliko valdoma išorine informacija, patenkančia į modelio kontekstą; galimos pasekmės apima pasiekiamumo, duomenų vientisumo ir privatumo pažeidimus.

Įsivaizduokite sąlyginį procesą: agentas turi apibendrinti gautą laišką ir, naudodamas paieškos įrankį, patikrinti jame minimą informaciją. Laiške įterptas nurodymas gali liepti perskaityti kitą, privatų šaltinį ir išsiųsti jo turinį išoriniam gavėjui. Laiškas yra užduoties duomenys; pavojus atsiranda tada, kai jo tekstas ima lemti agento tikslą arba įrankio parametrus.

Prieš diegdami agentą, nubraižykite jo faktinę veiksmų seką: iš kur gaunamas turinys, kur jis pridedamas prie modelio konteksto, kokius įrankius modelis gali pasiūlyti ir kas juos vykdo. Kiekviename perėjime įrašykite patikrinamą sąlygą. Pavyzdžiui, ar iš laiško paimtas adresas gali tapti siuntimo gavėju be atskiro leidimo?

Išsaugokite ribą tarp duomenų ir nurodymų

Išorinį laišką, dokumentą ir įrankio atsakymą agentui perduokite kaip aiškiai pažymėtus duomenis, kartu išlaikydami jų kilmę. Agentui skirti sistemos nurodymai turi apibrėžti užduotį ir neleisti iš šių šaltinių perimti naujų elgesio taisyklių. Vien žymėjimas ribos neužtikrina, todėl vykdymo etape vis tiek reikalinga atskira patikra.

OWASP promptų injekcijų prevencijos gairės rekomenduoja atskirti nepatikimą turinį, tikrinti siūlomų įrankio veiksmų argumentus už modelio ribų ir išvestį vertinti pagal jos naudojimo vietą. Registruokite šaltinio tipą ir dokumento tapatybę, kad būtų galima susieti siūlomą veiksmą su jį paveikusiu turiniu.

Jei procesui reikia tik kelių dokumento laukų, išskirkite juos pagal apibrėžtą struktūrą ir patikrinkite jų tipą bei leistinas reikšmes. Tai sumažina nereikalingo teksto kiekį agento kontekste, tačiau ir išskirtuose laukuose esantis turinys lieka nepatikimas. Iš laiško gautas gavėjo adresas netampa leidžiamu siuntimo adresu vien todėl, kad atitinka el. pašto formato taisyklę.

Įrankiui suteikite tik užduočiai reikalingas teises

Veiksmų ribojimą įgyvendinkite įrankio vykdymo sluoksnyje, o ne vien agento aprašyme. Apibendrinimui skirtam procesui gali pakakti skaitymo prieigos; jeigu siuntimo ar redagavimo funkcija nenumatyta, jos agentui neprijunkite. Atskirai ribokite, kuriuos aplankus, paskyras, įrašus ar gavėjus įrankis gali pasiekti.

Leidžiamų veiksmų sąrašą sudarykite pagal darbo eigą: įrankio pavadinimas, operacija, pasiekiamas išteklius ir galimi parametrai. Prieš vykdymą serveris turi patikrinti ir šį sąrašą, ir dabartinio naudotojo teises. Nežinomas įrankis, nenumatytas kelias ar gavėjas turi būti atmestas net tada, kai agentas savo pasirinkimą aiškina įtikinamai.

Taip pat atskirkite skaitymo ir rašymo kredencialus. Jei tas pats agentas gali skaityti privačius duomenis ir laisvai siųsti užklausas išoriniams adresams, viena injekcija gali sujungti abu gebėjimus. Ribokite ir perduodamų duomenų apimtį: įrankiui pateikite tai, ko reikia konkrečiam veiksmui, o ne visą ankstesnį pokalbį ar surinktą dokumentų rinkinį.

Jautrų veiksmą sustabdykite iki patvirtinimo

Prieš išsiųsdamas laišką, pakeisdamas įrašą, ištrindamas duomenis ar atlikdamas kitą didelio poveikio veiksmą, agentas turi pateikti konkretų siūlymą patvirtinti. Patvirtinimo lange žmogui parodykite operaciją, tikslinį išteklių, gavėją ir perduodamų duomenų apimtį. Bendras klausimas „ar tęsti?“ neleidžia įvertinti, ką iš tikrųjų ketinama atlikti.

Patvirtinimą tikrinkite ten pat, kur vykdomas įrankis: jis turi galioti konkrečiam naudotojui, veiksmui ir jo parametrams. Jei po peržiūros pasikeičia gavėjas arba pridedami duomenys, reikia naujo patvirtinimo. Vien modelio sugeneruota frazė, kad leidimas gautas, nėra leidimas.

Ši riba ypač svarbi, kai rizikingi parametrai ateina iš išorinio turinio. Patvirtinimo procese aiškiai pažymėkite jų kilmę, kad žmogus galėtų pastebėti, jog siuntimo adresas ar prašomas failas paimtas iš gauto laiško, o ne iš pradinės naudotojo užduoties.

Patikrinkite išvestį ir stebėkite sprendimus

Kontrolė nesibaigia ties įrankio iškvietimu. Prieš perduodami agento atsakymą naudotojui ar kitai sistemai, patikrinkite jo struktūrą, leidžiamus laukus ir tai, ar jame neatsidūrė privatūs duomenys. Jei išvestis tampa HTML turiniu, duomenų bazės užklausa ar kito įrankio įvestimi, pritaikykite būtent tai paskirties vietai reikalingą tikrinimą.

Žurnale fiksuokite išorinio šaltinio tapatybę, siūlytą įrankio veiksmą, autorizavimo sprendimą, patvirtinimą ir vykdymo rezultatą. Slaptažodžių, prieigos raktų ir perteklinių asmens duomenų į žurnalą neįrašykite. Stebėkite neįprastus gavėjus ir pasikartojančius atmestus veiksmus: tai leidžia tirti bandymą net jei galutinis agento atsakymas atrodo įprastas.

Patikrinkite visą grandinę bandymais

Bandymų metu įdėkite nekenksmingą atakos tekstą į tą kanalą, iš kurio agentas iš tikrųjų skaito: laiško turinį, paieškos rezultatą, dokumentą arba įrankio atsakymą. Naudokite bandomuosius duomenis ir įrankius, kurie leidžia matyti siūlomą bei atmestą veiksmą. Tą patį tekstą pateikus kaip tiesioginę naudotojo užklausą būtų tikrinama kita pasitikėjimo riba.

Kiekvienam bandymui iš anksto nurodykite laukiamą rezultatą: agentas atlieka teisėtą užduotį, negauna papildomų teisių, neišsiunčia bandomojo slapto žymens ir negali apeiti patvirtinimo. Po modelio, sistemos nurodymų, įrankių ar prieigos teisių pakeitimo šiuos bandymus pakartokite. Sprendžiamasis įrodymas yra vykdymo įrašas, rodantis, kad neleistinas veiksmas sustabdytas prieš jį atliekant.

Taip pat skaitykite:

• Ar jūsų DI sistema didelės rizikos? Vien Annex III sąrašo nepakanka
• ShinyHunters grįžo prie PeopleSoft: vien WAF taisyklių nepakanka
• Nutekintas „GitHub“ prieigos raktas: ištrinti jį iš kodo nepakanka