DI pokalbių botų įrankių iškvietimų sauga: teisės, patvirtinimas ir atstatymo kelias

Svetainės pokalbių botas iš esmės pasikeičia, kai jis ne tik atsako, bet ir gali inicijuoti veiksmus. Susitikimo laiko užklausa dar yra paprasta. Tačiau susitikimo atšaukimas, adreso pakeitimas arba pinigų grąžinimas pakeičia tikrąją verslo būseną. Kalbos modelis gali pasiūlyti tinkamą įrankio iškvietimą. Tačiau ar veiksmas yra leistinas, turi nuspręsti atskiras, deterministinis taikomasis sluoksnis. Todėl saugūs DI pokalbių botų įrankių iškvietimai sukuriami ne itin griežta sistemos užklausa (system prompt), o ribotomis funkcijomis, teisių tikrinimu serverio pusėje, suprantamu patvirtinimu ir kontroliuojamu vykdymo keliu.

Kodėl geras kalbos modelis nepakeičia autorizacijos

Modelis veikia remdamasis tikimybėmis. Jis gali neteisingai suprasti ketinimą, papildyti parametrą arba sureaguoti į manipuliuojamą turinį. OWASP rizikos aprašyme apie Excessive Agency įvardijamos trys tipinės priežastys: per daug funkcionalumo, per plačios teisės ir per daug autonomijos. Taigi problema yra ne tik piktavališka įvestis. Net dviprasmiška užklausa arba tikėtinai skambanti modelio klaida gali paruošti nepageidaujamą veiksmą.

Todėl svarbiausia architektūros taisyklė skamba taip: modelis suformuluoja pasiūlymą, tačiau taikomoji programa autorizuoja ir įvykdo jį. Įrankio iškvietimas, pvz., cancelAppointment, iš pradžių yra tik struktūruotas ketinimas. Tik taisyklių patikra (policy check) patikrina vartotoją, nuomininką, objektą, leidžiamą veiksmą, dabartinę būseną ir būtiną patvirtinimą. Šis atskyrimas papildo apsaugą nuo Prompt Injection svetainių pokalbių botuose; jis išlieka būtinas net ir tada, kai jokia ataka nebuvo pastebėta.

Kiekvieną įrankį klasifikuokite pagal poveikį, o ne pagal pavadinimą

Komandos neturėtų viso pokalbių boto bendrai klasifikuoti kaip „saugaus“ arba „kritinio“. Lemiamas yra kiekvieno atskiro įrankio poveikis. Paprasta rizikos matrica suteikia aiškumo:

• Skaitymo ir mažo jautrumo: darbo laiko arba viešai prieinamos produkto informacijos gavimas.
• Skaitymo ir asmens duomenų: užsakymo būsenos arba kliento duomenų rodymas; tam reikia patikrinti tapatybę, nuomininką ir sąsają su objektu.
• Rašymo, bet lengvai atšaukiamas: vidinio pageidavimo perskambinti sukūrimas arba neįpareigojančios pastabos pridėjimas.
• Reikšmingų pasekmių arba sunkiai atšaukiamas: rezervacijos atšaukimas, kontaktinių duomenų keitimas, turinio publikavimas, pranešimų siuntimas arba mokėjimų iniciacija.

Iš šios klasės išplaukia teisės, patvirtinimo lygis, limitai ir registravimas. Bendras patvirtinimas „Pokalbių botas gali naudoti CRM“ yra per daug nekonkretus. Geriau turėti konkrečių gebėjimų sąrašą su apibrėžtais parametrais ir leidžiamais būsenų perėjimais.

Mažiausių privilegijų principas prasideda nuo funkcijų apibrėžimo

OWASP Authorization Cheat Sheet rekomenduoja mažiausių privilegijų (Least Privilege) ir numatytojo draudimo (Deny by Default) principus. Įrankių iškvietimams tai reiškia: pokalbių botas gauna tik tą funkciją ir duomenų iškarpą, kuri yra būtina atitinkamam žingsniui.

Maži įrankiai vietoje universalių sąsajų

Įrankį getOrderStatus(orderId) apsaugoti yra lengviau nei atvirą prieigą prie duomenų bazės. Įrankis requestCallback(topic, timeWindow) yra geriau kontroliuojamas nei bendra funkcija bet kokiems pranešimams siųsti. Laisvos SQL, Shell, URL arba el. pašto funkcijos nereikalingai padidina galimą poveikį. Nebenaudojami testavimo įrankiai taip pat turėtų būti pašalinti iš gamybinio katalogo.

Vykdyti prisijungusio vartotojo kontekste

Galinis serveris (backend) neturi pasitikėti vien tuo, kad modelis perduoda teisingą kliento ID. Jis turi išvesti dabartinį vartotoją ir nuomininką iš patikimos sesijos ir kiekvienam objektui iš naujo patikrinti, ar prieiga yra galima. Praktinis skirtumas tarp viešo pokalbio ir apsaugotos srities išsamiai paaiškintas straipsnyje apie tapatybę ir prieigą prie duomenų klientų portale. Bendra tarnybinė paskyra su pilna prieiga vartotojo inicijuojamiems veiksmams dažniausiai yra neteisingas sutrumpinimas.

Determiniškai tikrinti parametrus

Įrankių parametrams reikalinga griežta schema: leidžiami laukai, tipai, ilgiai, reikšmių rėžiai ir būsenų taisyklės. Susitikimo ID turi priklausyti vartotojui, data turi būti leidžiamame rėžyje, o veiksmas turi atitikti dabartinę būseną. Nežinomi laukai atmetami. Taikomoji programa taip pat turėtų užtikrinti, kad pats įrankio pavadinimas būtų iš fiksuoto leidžiamųjų sąrašo (allowlist), o ne vykdomas iš laisvai sugeneruoto teksto.

Patvirtinimas turi rodyti tikrąjį veiksmą

Esant reikšmingiems pakeitimams, klausimo „Ar tikrai?“ neužtenka. OWASP gairėse dėl transakcijų autorizavimo aprašomas principas „Ką matai, tą pasirašai“ (What You See Is What You Sign): vartotojai turi matyti ir galėti patvirtinti esminius konkretaus veiksmo duomenis. Svetainės pokalbių botui tai reiškia, pavyzdžiui:

• „Atšaukti susitikimą rugpjūčio 18 d. 14:30 val.“ vietoje „Patvirtinti pakeitimą“
• „Pakeisti užsakymo ...84 pristatymo adresą į Vieną“ vietoje „Išsaugoti duomenis“
• „Sukurti užklausą dėl perskambinimo tema „Sąskaita““ vietoje „Siųsti užklausą“

Patvirtinimas serverio pusėje pririšamas būtent prie šio veiksmo juodraščio. Jei pasikeičia tikslas, suma, terminas, gavėjas ar kiti esminiai parametrai, jis netenka galios. Jis gauna trumpą galiojimo laiką ir negali būti pakartotinai panaudotas antram veiksmui. Ypatingai kritiniams procesams papildomai gali prireikti pakartotinio prisijungimo arba žmogaus patvirtinimo. Modelis neturi nei praleisti šio etapo, nei pakeisti jo raminančiai suformuluotu atsakymu.

Suplanuokite idempotentiškumą, limitus ir atstatymo kelią

Net ir teisingai autorizuotas įrankio iškvietimas techniškai gali atvykti dvigubai: naršyklė pakartoja užklausą, dėl laiko limito (timeout) suveikia pakartojimas (retry) arba vartotojas vėl išsiunčia tą pačią žinutę. Todėl rašymo įrankiai turėtų naudoti serverio pusės idempotentiškumo ID. Tam pačiam ID tas pats veiksmas įvykdomas daugiausiai vieną kartą; pakartojimas gauna jau žinomą rezultatą.

Papildomai kiekvienam įrankiui reikia tinkamų ribų: maksimalių iškvietimų skaičiaus per sesiją, trumpų laiko limitų, ribotų pakartojimų ir nutraukimo esant neįprastoms grandinėms. Prieš vykdymą galinis serveris dar kartą patikrina būseną. Taip, pavyzdžiui, jau atšaukta rezervacija nebus tvarkoma antrą kartą. Kur įmanoma, veiksmas iš pradžių turėtų būti sukuriamas kaip juodraštis arba pažymėtas užsakymas. Neištengiamai tiesioginiams pakeitimams turi būti aišku, kaip jie bus kompensuojami, atšaukiami arba perduodami palaikymo komandai. Paruoštas veikimo apribojus funkcionalumą (degraded mode) ir atstatymo planas užkerta kelią improvizacijai sutrikimo atveju.

Registruokite įvykius nerinkdami paslapčių

Saugumo žurnalas (log) turėtų galėti atsakyti į klausimą, kas, kokiu pagrindu, kokį veiksmą patvirtino ir su kokiu rezultatu įvykdė. Naudinga turėti pseudonimizuotą vykdytojo ID, įrankį ir versiją, objekto nuorodą, taisyklių versiją, autorizavimo sprendimą, patvirtinimo ID, idempotentiškumo ID, laiko žymą ir rezultatą. Slaptažodžiai, žetonai (tokens), pilni pokalbių tekstai ir nereikalingi asmens duomenys į šį žurnalą neįeina.

OWASP AI Agent Security Cheat Sheet rekomenduoja struktūrizuotus sprendimų duomenis didelės rizikos veiksmams ir sprendimo bei vykdymo atskyrimą. Tai skiriasi nuo pilno techninio sekimo (tracing): saugumo patikrai svarbus trumpas, patikimas patvirtinimo grandinės įrodymas. Saugojimas ir prieiga turėtų atitikti faktinį patikros poreikį.

Tvirta penkių sluoksnių architektūra

1. Dialogas ir pasiūlymas: modelis atpažįsta ketinimą ir sukuria struktūrizuotą veiksmo juodraštį, tačiau nieko tiesiogiai nevykdo.
2. Sprendimas dėl taisyklių (policy): deterministinis komponentas patikrina įrankių leidžiamąjį sąrašą, vartotoją, nuomininką, objektą, parametrus, rizikos klasę ir limitus.
3. Patvirtinimas: sąsaja rodo esminius veiksmo duomenis. Patvirtinimas yra trumpalaikis ir pririštas prie nepakitusio juodraščio.
4. Vykdymas: griežtai apribotas vykdytojas (executor) iš naujo patikrina autorizaciją prieš pat iškvietimą ir naudoja idempotentiškumo ID.
5. Įrodymai ir reakcija: rezultatas, klaidos ir patvirtinimo grandinė registruojami taupant duomenis; apibrėžti įspėjimai, kompensavimas ir perdavimas žmogui.

NIST AI RMF Core tokias užduotis skirsto į Govern, Map, Measure ir Manage. Praktiškai tai reiškia: nustatyti atsakomybes ir rizikos ribas, suprasti naudojimo kontekstą, išbandyti kontrolės priemones ir reaguoti į pastebėtus nuokrypius.

Testavimo matrica prieš paleidimą

Vien teigiamų testų neužtenka. Įrankis turi saugiai atmesti užklausą ir nepalankiomis sąlygomis. Į kartojamą testavimo matricą turėtų įeiti bent šie atvejai:

• Neprisijungęs arba teisių neturintis vartotojas reikalauja atlikti veiksmą.
• Galiojanti sesija nurodo į kito nuomininko objektą.
• Esminiai parametrai pasikeičia po patvirtinimo.
• Identiška užklausa pakartojama dėl laiko limito viršijimo arba dvigubo spustelėjimo.
• Įrankis grąžina manipuliuojamas instrukcijas arba netikėtus papildomus laukus.
• Iškvietimas viršija laiko, kiekybinius arba išlaidų limitus.
• Tikslinė sistema suges tarp patikrinimo ir vykdymo.
• Teisė panaikinama prieš pat vykdymą.

Tikimasi ne tik sėkmingų veiksmų, bet ir aiškių atmetimų, nepakitusių duomenų ir panaudojamų saugumo įvykių. Prieš įjungiant rašymo prieigą tikriems vartotojams, procesą galima patikrinti šešėliniu režimu (shadow mode) su tikroviškomis užklausomis, nevykdant siūlomų veiksmų.

Kontrolinis sąrašas svetainės komandoms

• Ar kiekvienas įrankis yra mažas, skirtas konkrečiam tikslui ir iš fiksuoto leidžiamųjų sąrašo?
• Ar vartotojas, nuomininkas, objektas ir veiksmas tikrinami serverio pusėje?
• Ar taikomi numatytasis draudimas (Deny by Default) ir minimalios techninės teisės?
• Ar vartotojai mato visus esminius duomenis prieš kritinius veiksmus?
• Ar patvirtinimas netenka galios po pakeitimų ir praėjus trumpam laikui?
• Ar idempotentiškumo ID užkerta kelią dvigubam vykdymui?
• Ar yra limitai, laiko limitai, nutraukimas, kompensavimas ir perdavimas žmogui?
• Ar žurnaluose nelieka žetonų, paslapčių ir nereikalingų asmens duomenų?
• Ar testavimo matrica apima teisių klaidas, manipuliacijas, pakartojimus ir sutrikimus?

Išvada: modelis siūlo, taikomoji programa sprendžia

Svetainės pokalbių botas, galintis atlikti veiksmus, neturi startuoti su pilna prieiga. Pradėkite nuo griežtai apriboto, atšaukiamo veiksmo ir matomai sukurkite patvirtinimo grandinę aplink jį. Kai įrankių apibrėžimas, autorizavimas serverio pusėje, konkretus patvirtinimas, idempotentiškumas ir atstatymo kelias projektuojami kartu, pokalbis išlieka naudingas, nesuteikiant modeliui saugumo sistemos vaidmens. Kitam žingsniui verta surengti dirbtuves su produkto, vystymo, palaikymo ir duomenų apsaugos komandomis: pasirinkite tikrą veiksmą, įvertinkite jo riziką ir apibrėžkite saugų atmetimo atvejį prieš pirmąjį tiesioginį patvirtinimą.