KI-Chatboti tool-kutsete turvamine: õigused, kinnitus ja tagasivõtmistee

Veebilehe chatbot muutub põhimõtteliselt, kui ta ei vasta ainult küsimustele, vaid saab ka toiminguid käivitada. Aja broneeringu päring on veel lihtne. Aja tühistamine, aadressi muutmine või tagasimakse muudavad aga tegelikku äriolekut. Keelemudel võib seejuures pakkuda välja sobiva tool-kutse (funktsioonikutse). Kas toiming on aga lubatud, peab otsustama eraldiseisev, deterministlik rakenduskiht. Turvalised KI-Chatbot-tool-kutsed ei teki seepärast mitte eriti rangest süsteemi prompt'ist, vaid piiratud funktsioonidest, serveripoolsest õiguste kontrollist, arusaadavast kinnitusest ja kontrollitud täitmisteest.

Miks hea keelemudel ei asenda autoriseerimist

Mudel töötab tõenäosustega. See võib taotlust valesti mõista, parameetrit täiendada või reageerida manipuleeritud sisule. OWASP-i riskikirjeldus teemal Excessive Agency nimetab kolme tüüpilist põhjust: liiga palju funktsionaalsust, liiga laialdased õigused ja liiga palju autonoomiat. Probleem pole seega ainult pahatahtlikus sisendis. Ka kahemõtteline päring või usutavana kõlav mudeliviga võib ette valmistada soovimatu toimingu.

Kõige olulisem arhitektuurireegel kõlab seega: mudel sõnastab ettepaneku, kuid rakendus autoriseerib ja viib selle täide. Tool-kutse nagu cancelAppointment on esialgu vaid struktureeritud kavatsus. Alles reeglistiku kontroll (Policy-Check) kontrollib kasutajat, rentnikku (tenant), objekti, lubatud toimingut, hetkeolekut ja vajalikku kinnitust. See eraldatus täiendab kaitset prompt injection'i eest veebilehe chatbot'ides; see jääb vajalikuks ka siis, kui ühtegi rünnakut ei tuvastatud.

Iga tööriista liigitamine mõju, mitte nime järgi

Tiimid ei tohiks klassifitseerida kogu chatboti üldiselt "turvaliseks" või "kriitiliseks". Määrav on iga üksiku tööriista (tool) mõju. Lihtne riskimaatriks loob selguse:

• Lugemine ja vähetundlik: lahtiolekuaegade või avalikult kättesaadava tooteinfo pärimine.
• Lugemine ja isikuandmed: tellimuse oleku või kliendiandmete kuvamine; selleks tuleb kontrollida isikusamasust, rentnikku ja objektiseost.
• Kirjutatav, kuid hästi tagasipööratav: sisemise tagasihelistamise soovi loomine või mittekohustava märkuse lisamine.
• Mõjukas või raskesti tagasipööratav: broneeringu tühistamine, kontaktandmete muutmine, sisu avaldamine, teadete saatmine või maksete algatamine.

Sellest klassist tulenevad õigused, kinnituse tase, piirangud ja logimine. Üldine luba "Chatbot võib kasutada CRM-i" on liiga jäme. Parem on nimekiri konkreetsetest võimekusest koos määratletud parameetrite ja lubatud olekuüleminekutega.

Least Privilege algab funktsioonide piiritlemisest

OWASP Authorization Cheat Sheet soovitab Least Privilege (vähimate õiguste) ja Deny by Default (vaikekeelamise) põhimõtet. Tool-kutsete puhul tähendab see: chatbot saab ainult selle funktsiooni ja andmeväljavõtte, mis on konkreetse sammu jaoks vajalikud.

Väikesed tööriistad universaalsete liidest asemel

Tööriista getOrderStatus(orderId) on lihtsam turvata kui avatud andmebaasipääsu. Tööriist requestCallback(topic, timeWindow) on paremini kontrollitav kui üldine funktsioon mis tahes teadete saatmiseks. Vabad SQL-, Shell-, URL- või e-posti funktsioonid suurendavad võimalikku mõju tarbetult. Ka testtööriistad, mida enam ei vajata, peaksid tootekatoloogist kaduma.

Käivitamine sisselogitud kasutaja kontekstis

Tagarakendus (backend) ei tohi usaldada ainult seda, et mudel edastab õige kliendi ID. See peab tuvastama praeguse kasutaja ja rentniku usaldusväärsest sessioonist ning kontrollima iga objekti puhul uuesti, kas juurdepääs on olemas. Praktilist erinevust avaliku vestluse ja kaitstud ala vahel selgitatakse üksikasjalikult artiklis isikusamasuse ja andmepääsu kohta kliendiportaalis. Üldine teenusekonto (service account) täieliku juurdepääsuga on kasutajapõhiste toimingute jaoks tavaliselt vale otsetee.

Parameetrite deterministlik valideerimine

Tool-parameetrid vajavad kitsast skeemi: lubatud väljad, tüübid, pikkused, väärtusvahemikud ja olekureeglid. Broneeringu ID peab kuuluma kasutajale, kuupäev peab olema lubatud vahemikus ja toiming peab sobima praeguse olekuga. Tundmatud väljad lükatakse tagasi. Rakendus peaks lisaks tagama, me tool-nimi ise pärineks fikseeritud lubatud nimekirjast (allowlist), mitte vabalt loodud tekstist.

Kinnitus peab näitama tegelikku toimingut

Mõjukate muudatuste puhul ei piisa küsimusest "Kas olete kindel?". OWASP-i tehingute autoriseerimise juhend kirjeldab põhimõtet "What You See Is What You Sign": kasutajad peavad saama konkreetsest toimingust aru ja kinnitama olulisi andmeid. Veebilehe chatboti puhul tähendab see näiteks:

• "Tühista broneering 18. augustil kell 14:30" asemel "Kinnita muudatus"
• "Muuda tellimuse ...84 tarneaadress Viiniks" asemel "Salvesta andmed"
• "Loo tagasihelistamise päring teemal Arve" asemel "Saada päring"

Kinnitus seotakse serveripoolselt täpselt selle toimingu kavandiga. Kui sihtkoht, summa, aeg, saaja või muud olulised parameetrid muutuvad, kaotab see kehtivuse. See saab lühikese kehtivusaja ja seda ei saa teise toimingu jaoks uuesti kasutada. Eriti kriitiliste toimingute puhul võib lisaks olla vajalik uuesti sisselogimine või inimesepoolne heakskiit. Mudel ei tohi seda sammu vahele jätta ega asendada seda rahustavalt sõnastatud vastusega.

Idempotentsuse, piirangute ja tagasivõtmistee planeerimine

Ka korrektselt autoriseeritud tool-kutse võib tehniliselt saabuda topelt: veebilehitseja kordab päringut, aegumine (timeout) käivitab korduskatse (retry) või kasutaja saadab sama teate uuesti. Kirjutavad tööriistad peaksid seepärast kasutama serveripoolset idempotentsuse ID-d. Sama ID puhul käivitatakse sama toiming maksimaalselt üks kord; korduskatse saab juba teadaoleva tulemuse.

Lisaks vajab iga tööriist sobivaid piiranguid: maksimaalne kutsete arv sessiooni kohta, lühikesed aegumised, piiratud korduskatsed ja katkestamine ebatavaliste ahelate korral. Enne täitmist kontrollib tagarakendus olekut uuesti. Nii ei töödelda näiteks juba tühistatud broneeringut teist korda. Kus võimalik, tuleks toiming luua esialgu kavandina või ettenähtud tellimusena. Vältimatult otseste muudatuste puhul peab olema selge, kuidas neid hüvitada, tühistada või klienditoe tiimile üle anda. Ettevalmistatud piiratud töörežiim (degraded mode) ja tagasivõtmisplaan hoiavad ära vajaduse tõrgete korral improviseerida.

Logimine ilma saladusi kogumata

Turvalogimise eesmärk on suuta vastata küsimusele, kes millise toimingu millisel alusel vabastas ja millise tulemusega täitis. Mõistlikud andmed on pseudonümiseeritud teostaja ID, tool ja versioon, objekti viide, reeglistiku versioon, autoriseerimisotsus, kinnituse ID, idempotentsuse ID, kellaaeg ja tulemus. Paroolid, token'id, täielikud vestluslood ja tarbetud isikuandmed sellesse logisse ei kuulu.

OWASP AI Agent Security Cheat Sheet soovitab riskantsete toimingute puhul struktureeritud otsustusandmeid ning otsuse ja täitmise eraldamist. See on midagi muud kui täielik tehniline jälitus (tracing): turvakontrolli jaoks on oluline lühike ja usaldusväärne tõend kinnitusahela kohta. Säilitamine ja juurdepääs peaksid põhinema tegelikul kontrollivajadusel.

Tugev arhitektuur viies kihis

1. Dialoog ja ettepanek: mudel tuvastab kavatsuse ja loob struktureeritud toimingu kavandi, kuid ei täida midagi otse.
2. Otsus reeglistiku üle: deterministlik komponent kontrollib tool'ide lubatud nimekirja (allowlist), kasutajat, rentnikku, objekti, parameetreid, riskiklassi ja piiranguid.
3. Kinnitus: kasutajaliides näitab olulisi toimingu andmeid. Vabastus on lühiajaline ja seotud muutmata kavandiga.
4. Täitmine: rangelt piiratud täitja (executor) kontrollib autoriseerimist vahetult enne kutset uuesti ja kasutab idempotentsuse ID-d.
5. Tõendamine ja reageerimine: tulemus, vead ja kinnitusahel logitakse andmesäästlikult; häireteavitus, hüvitamine ja inimesele üleandmine on määratletud.

NIST AI RMF Core paigutab sellised ülesanded kategooriatesse Govern, Map, Measure ja Manage. Praktikas tähendab see: vastutuse ja riskipiiride määramist, kasutuskonteksti mõistmist, kontrollide testimist ja täheldatud kõrvalekalletele reageerimist.

Testimismaatriks enne avalikustamist

Pelgalt positiivsetest testidest ei piisa. Tööriist peab ka ebasoodsates tingimustes turvaliselt katkestama. Korduvasse testimismaatriksisse peaksid kuuluma vähemalt järgmised juhtumid:

• Sisselogimata või õigusteta kasutaja taotleb toimingut.
• Kehtiv sessioon viitab teise rentniku objektile.
• Olulised parameetrid muutuvad pärast kinnitamist.
• Identne päring kordub aegumise või topeltklõpsu tõttu.
• Tööriist tagastab manipuleeritud juhiseid või ootamatuid lisavälju.
• Kutse ületab aja-, koguse- või kulupiiranguid.
• Sihtsüsteem ütleb üles kontrolli ja täitmise vahel.
• Autoriseering võetakse vahetult enne täitmist ära.

Oodata ei tuleks mitte ainult edukaid toiminguid, vaid ka selgeid tagasilükkamisi, muutmata andmeid ja kasutatavaid turvasündmusi. Enne kui kirjutamisoigused päriskasutajatele aktiveeritakse, saab protsessi kontrollida varjurežiimis (Shadow Mode) realistlike päringutega, ilma pakutud toiminguid täide viimata.

Kontrollnimekiri veebitiimidele

• Kas iga tööriist on väike, eesmärgipärane ja pärineb fikseeritud lubatud nimekirjast?
• Kas kasutajat, rentnikku, objekti ja toimingut kontrollitakse serveripoolselt?
• Kas kehtivad Deny by Default ja minimaalsed tehnilised õigused?
• Kas kasutajad näevad enne kriitilisi toiminguid kõiki olulisi andmeid?
• Kas kinnitus aegub muudatuste korral ja lühikese aja möödudes?
• Kas idempotentsuse ID hoiab ära topelttäitmise?
• Kas on olemas piirangud, aegumine, katkestamine, hüvitamine ja üleminek inimesele (Human Handoff)?
• Kas token'id, saladused ja tarbetud isikuandmed jäävad logidest välja?
• Kas testimismaatriks katab õiguste vead, manipulatsioonid, korduskatsed ja katkestused?

Kokkuvõte: Mudel pakub välja, rakendus otsustab

Tegutsemisvõimeline veebilehe chatbot ei pea alustama täieliku juurdepääsuga. Alustage kitsalt piiratud, tagasipööratava toiminguga ja ehitage kinnitusahel selle ümber nähtavalt. Kui tööriistade piiritlemine, serveripoolne autoriseerimine, konkreetne kinnitus, idempotentsus ja tagasivõtmistee projekteeritakse koos, jääb vestlus kasulikuks, ilma et mudelile antaks turvasüsteemi rolli. Järgmiseks sammuks tasub teha töötuba toote-, arendus-, klienditoe- ja andmekaitsetiimiga: valige tegelik toiming, hinnake selle riski ja määratlege enne esimest reaalset vabastamist turvaline tagasilükkamisjuhtum.