Zavarovanje klicev orodij AI chatbotov: pravice, potrditev in pot povratka

Spletni chatbot postane temeljito drugačen, ko ne le odgovarja, temveč lahko sproži tudi dejanja. Poizvedba o terminu je še obvladljiva. odpoved termina, sprememba naslova ali vračilo denarja pa spremenijo dejansko poslovno stanje. Jezikovni model lahko pri tem predlaga ustrezen klic orodja. Ali je dejanje dopustno, pa mora odločiti ločena, deterministična aplikacijska plast. Varni klici orodij AI chatbotov zato ne nastanejo z izjemno strogim sistemskim pozivom (system prompt), temveč z omejenimi funkcijami, preverjanjem pravic na strani strežnika, razumljivo potrditvijo in nadzorovano potjo izvajanja.

Zakaj dober jezikovni model ne nadomesti avtorizacije

Model deluje na podlagi verjetnosti. Lahko napačno razume namen, dopolni parameter ali se odzove na manipulirano vsebino. Opis tveganja OWASP glede Excessive Agency navaja tri tipične vzroke: preveč funkcionalnosti, predaleč segajoča dovoljenja in preveč avtonomije. Težava torej ni le zlonameren vnos. Tudi dvoumna zahteva ali verjetno zveneča napaka modela lahko pripravi neželeno dejanje.

Najpomembnejše arhitekturno pravilo se glasi: model oblikuje predlog, aplikacija pa ga avtorizira in izvede. Klic orodja, kot je cancelAppointment, je sprva le strukturiran namen. Šele preverjanje pravilnika (policy check) preveri uporabnika, najemnika (tenant), objekt, dovoljeno dejanje, trenutno stanje in potrebno potrditev. Ta ločitev dopolnjuje zaščito pred prikrito vstavitvijo poziva (prompt injection) pri spletnih chatbotih; ostaja potrebna tudi, če napad ni bil zaznan.

Razvrstite vsako orodje glede na učinek namesto glede na ime

Ekipe ne bi smele celotnega chatbota pavšalno razvrstiti kot »varen« ali »kritičen«. Odločilen je učinek vsakega posameznega orodja. Preprosta matrika tveganja prinaša jasnost:

• Bralno in manj občutljivo: pridobivanje odpiralnih časov ali javno dostopnih informacij o izdelkih.
• Bralno in osebno: prikaz stanja naročila ali podatkov o stranki; za to je treba preveriti identiteto, najemnika in povezavo z objektom.
• Pisanje, a enostavno reverzibilno: ustvarjanje interne zahteve za povratni klic ali dodajanje neobvezujoče opombe.
• Daljnosežno ali težko reverzibilno: odpoved rezervacije, sprememba kontaktnih podatkov, objava vsebine, pošiljanje sporočil ali sprožitev plačil.

Iz tega razreda izvirajo pravice, stopnja potrditve, omejitve in beleženje (logging). Pavšalna odobritev »chatbot lahko uporablja CRM« je prejgroba. Boljši je seznam konkretnih zmožnosti z opredeljenimi parametri in dovoljenimi prehodi stanj.

Najmanjše pravice (Least Privilege) se začnejo pri oblikovanju funkcij

Priročnik OWASP Authorization Cheat Sheet priporoča najmanjše pravice in zavrnitev po privzetem (Deny by Default). Za klice orodij to pomeni: chatbot prejme le tisto funkcijo in izsek podatkov, ki sta potrebna za posamezen korak.

Mala orodja namesto univerzalnih vmesnikov

Orodje getOrderStatus(orderId) je lažje zavarovati kot odprt dostop do podatkovne baze. Orodje requestCallback(topic, timeWindow) je bolj nadzorljivo kot splošna funkcija za pošiljanje poljubnih sporočil. Proste funkcije SQL, Shell, URL ali e-pošte po nepotrebnem povečujejo možen učinek. Tudi testna orodja, ki niso več potrebna, morajo izginiti iz produkcijskega kataloga.

Izvajanje v kontekstu prijavljenega uporabnika

Ozadje (backend) se ne sme zanašati le na to, da bo model posredoval pravo ID številko stranke. Trenutnega uporabnika in najemnika mora izpeljati iz zaupanja vredne seje ter za vsak objekt znova preveriti, ali obstaja dostop. Praktična razlika med javnim klepetom in zaščitenim območjem je podrobno razložena v prispevku o identiteti in dostopu do podatkov v uporabniškem portalu. Splošni storitveni račun s polnim dostopom je za dejanja, vezana na uporabnika, običajno napačna bližnjica.

Deterministično preverjanje parametrov

Parametri orodja potrebujejo strogo shemo: dovoljena polja, tipe, dolžine, razpone vrednosti in pravila stanj. ID termina mora pripadati uporabniku, datum mora biti v dovoljenem razponu, dejanje pa mora ustrezati trenutnemu statusu. Neznana polja se zavrnejo. Aplikacija mora poleg tega zagotoviti, da samo ime orodja prihaja iz fiksnega seznama dovoljenih (allowlist) in se ne izvaja iz prosto ustvarjenega besedila.

Potrditev mora prikazati dejansko dejanje

Pri daljnosežnih spremembah vprašanje »Ali ste prepričani?« ne zadošča. Smernica OWASP o avtorizaciji transakcij opisuje načelo »What You See Is What You Sign« (Kar vidiš, to podpišeš): uporabniki morajo imeti možnost prepoznati in potrditi bistvene podatke konkretnega dejanja. Za chatbot na spletnem mestu to na primer pomeni:

• »Odpovej termin 18. avgusta ob 14:30« namesto »Potrdi spremembo«
• »Spremeni naslov za dostavo za naročilo …84 na Dunaj« namesto »Shrani podatke«
• »Ustvari zahtevo za povratni klic s temo Račun« namesto »Pošlji zahtevo«

Potrditev se na strani strežnika veže natanko na ta osnutek dejanja. Če se spremenijo cilj, znesek, datum, prejemnik ali drugi bistveni parametri, potrditev zapade. Prejme kratek čas veljavnosti in je ni mogoče znova uporabiti za drugo dejanje. Za izjemno kritične postopke je lahko dodatno potrebna ponovna prijava ali ročna odobritev s strani človeka. Model te stopnje ne sme niti preskočiti niti nadomestiti s pomirjujoče formuliranim odgovorom.

Načrtovanje idempotence, omejitev in poti povratka

Tudi pravilno avtoriziran klic orodja se lahko tehnično pojavi dvakrat: brskalnik ponovi zahtevo, potek časa (timeout) sproži ponovni poskus (retry) ali pa uporabnik znova pošlje isto sporočilo. Orodja za pisanje bi morala zato uporabljati strežniško ID številko idempotence. Za isto ID številko se isto dejanje izvede največ enkrat; ponovni poskus prejme že znani rezultat.

Poleg tega vsako orodje potrebuje ustrezne omejitve: največje število klicev na sejo, kratke čase preteka, omejene ponovne poskuse in prekinitev ob neobičajnih verigah. Pred izvedbo ozadje znova preveri stanje. Tako se na primer že odpovedana rezervacija ne obdela drugič. Kjer je mogoče, je treba dejanje najprej ustvariti kot osnutek ali zabeleženo naročilo. Za neizogibne neposredne spremembe mora biti jasno, kako se nadomestijo, prekličejo ali predajo ekipi za podporo. Pripravljen omejeni način delovanja (degraded mode) in načrt povratka preprečujeta improvizacijo v primeru motenj.

Beleženje brez zbiranja skrivnosti

Varnostni dnevnik mora odgovarjati na vprašanja, kdo je katero dejanje odobril na kakšni podlagi in s kakšnim rezultatom ga je izvedel. Smiselni podatki so psevdonimiziran ID akterja, orodje in različica, referenca objekta, različica pravilnika, odločitev o avtorizaciji, ID potrditve, ID idempotence, čas in rezultat. Gesla, žetoni, celotne zgodovine klepetov in nepotrebne osebne vsebine ne spadajo v ta dnevnik.

Priročnik OWASP AI Agent Security Cheat Sheet priporoča strukturirane podatke o odločitvah za tvegana dejanja ter ločitev odločanja in izvajanja. To je nekaj drugega kot popolno tehnično sledenje (tracing): za varnostni pregled šteje kratek, zanesljiv dokaz verige odobritve. Hramba in dostop morata biti prilagojena dejanskim potrebam preverjanja.

Robustna arhitektura v petih slojih

1. Dialog in predlog: Model prepozna namen in ustvari strukturiran osnutek dejanja, vendar ničesar ne izvede neposredno.
2. Odločitev o pravilniku: Deterministična komponenta preveri seznam dovoljenih orodij, uporabnika, najemnika, objekt, parametre, razred tveganja in omejitve.
3. Potrditev: Vmesnik prikazuje bistvene podatke o dejanju. Odobritev je kratkotrajna in vezana na nespremenjen osnutek.
4. Izvedba: Strogo omejen izvajalec (executor) neposredno pred klicem znova preveri avtorizacijo in uporabi ID idempotence.
5. Dokaz in odziv: Rezultat, napake in veriga odobritve se zabeležijo z minimalno porabo podatkov; opozarjanje, kompenzacija in ročni prevzem so opredeljeni.

Okvir NIST AI RMF Core razvršča takšne naloge v kategorije Govern, Map, Measure in Manage. Praktično to pomeni: določitev odgovornosti in meja tveganja, razumevanje konteksta uporabe, testiranje nadzorov in odzivanje na opažena odstopanja.

Matrika testiranja pred zagonom

Samo pozitivni testi ne zadoščajo. Orodje mora varno odpovedati tudi v neugodnih pogojih. V ponovljivo matriko testiranja spadajo vsaj ti primeri:

• Neprijavljen ali nepooblaščen uporabnik zahteva dejanje.
• Veljavna seja se nanaša na objekt drugega najemnika.
• Bistveni parametri se spremenijo po potrditvi.
• Enaka zahteva se ponovi zaradi preteka časa ali dvojnega klika.
• Orodje vrne manipulirana navodila ali nepričakovana dodatna polja.
• Klic preseže časovne, količinske ali stroškovne omejitve.
• Ciljni sistem odpove med preverjanjem in izvedbo.
• Dovoljenje je odvzeto tik pred izvedbo.

Pričakujejo se ne le uspešna dejanja, temveč jasne zavrnitve, nespremenjeni podatki in uporabni varnostni dogodki. Preden se omogoči dostop za pisanje za dejanske uporabnike, je mogoče potek preveriti v senčnem načinu (Shadow Mode) z realističnimi zahtevami, ne da bi se predlagana dejanja dejansko izvedla.

Kontrolni seznam za ekipe spletnih mest

• Je vsako orodje majhno, namensko in iz fiksnega seznama dovoljenih?
• Ali se uporabnik, najemnik, objekt in dejanje preverjajo na strani strežnika?
• Veljata zavrnitev po privzetem (Deny by Default) in minimalna tehnična dovoljenja?
• Ali uporabniki pred kritičnimi dejanji vidijo vse bistvene podatke?
• Ali potrditev zapade ob spremembah in po kratkem času?
• Ali ID idempotence preprečuje dvojno izvedbo?
• Ali obstajajo omejitve, pretek časa, prekinitev, kompenzacija in ročni prevzem (Human Handoff)?
• Ali žetoni, skrivnosti in nepotrebni osebni podatki ostajajo zunaj dnevnikov?
• Ali matrika testiranja pokriva napake pravic, manipulacijo, ponovne poskuse in odpovedi?

Zaključek: model predlaga, aplikacija odloča

Spletni chatbot, ki je zmožen ukrepanja, ni treba da začne s polnim dostopom. Začnite s strogo omejenim, reverzibilnim dejanjem in okoli njega vidno zgradite verigo odobritve. Če so zasnova orodja, avtorizacija na strani strežnika, konkretna potrditev, idempotenca in pot povratka zasnovani skupaj, klepet ostane koristen, ne da bi modelu dali vlogo varnostnega sistema. Za naslednji korak se splača organizirati delavnico z izdelčno ekipo, razvojem, podporo in varstvom podatkov: izberite realno dejanje, razvrstite njegovo tveganje in pred prvo odobritvijo v živo opredelite varen primer zavrnitve.