Sigurno oblikovanje poziva alata AI chatbota: prava, potvrda i put oporavka

Chatbot na web-stranici postaje temeljito drukčiji čim mu se omogući ne samo odgovaranje, već i pokretanje radnji. Upit o slobodnom terminu još je prilično jednostavan. Međutim, otkazivanje termina, promjena adrese ili povrat novca mijenjaju stvarno poslovno stanje. Jezični model pritom smije predložiti odgovarajući poziv alata. No je li akcija dopuštena, mora odlučiti odvojeni, deterministički aplikacijski sloj. Sigurni pozivi alata AI chatbota stoga ne nastaju putem osobito stroge sistemske upute (system prompt), već putem ograničenih funkcija, poslužiteljske provjere prava, razumljive potvrde i kontroliranog puta izvršavanja.

Zašto dobar jezični model ne zamjenjuje autorizaciju

Model radi na temelju vjerojatnosti. Može pogrešno razumjeti namjeru, dodati parametar ili reagirati na manipulirani sadržaj. OWASP-ov opis rizika za Excessive Agency navodi tri tipična uzroka: previše funkcionalnosti, predaleko sežuća ovlaštenja i previše autonomije. Problem dakle nije samo zlonamjeran unos. Čak i dvosmislen upit ili uvjerljivo zvučeća pogreška modela može pripremiti neželjenu akciju.

Najvažnije arhitektonsko pravilo stoga glasi: Model formulira prijedlog, ali aplikacija ga autorizira i izvršava. Poziv alata kao što je cancelAppointment u početku je samo strukturirana namjera. Tek provjera pravila (policy check) provjerava korisnika, zakupca, objekt, dopuštenu akciju, trenutno stanje i potrebnu potvrdu. Ova podjela nadopunjuje zaštitu od Prompt Injection napada kod chatbotova na web-stranicama; ona ostaje nužna i u slučajevima kada napad nije prepoznat.

Razvrstavanje svakog alata prema učinku, a ne prema nazivu

Timovi ne bi trebali paušalno klasificirati cijeli chatbot kao „siguran“ ili „kritičan“. Presudan je učinkovitost i utjecaj svakog pojedinog alata. Jednostavna matrica rizika donosi jasnoću:

• Čitanje i niska osjetljivost: dohvaćanje radnog vremena ili javno dostupnih informacija o proizvodima.
• Čitanje i osobni podaci: prikaz statusa narudžbe ili podataka o kupcu; za to treba provjeriti identitet, zakupca i povezanost s objektom.
• Pisanje, ali lako reverzibilno: stvaranje internog zahtjeva za povratni poziv ili dodavanje neobvezujuće bilješke.
• Znatne posljedice ili teško reverzibilno: otkazivanje rezervacije, promjena kontakt podataka, objavljivanje sadržaja, slanje poruka ili pokretanje plaćanja.

Iz te klase proizlaze prava, razina potvrde, ograničenja i zapisivanje (logging). Paušalno odobrenje „Chatbot smije koristiti CRM“ previše je grubo. Bolji pristup je popis konkretnih mogućnosti s definiranim parametrima i dopuštenim prijelazima stanja.

Least Privilege počinje pri oblikovanju funkcija

OWASP Authorization Cheat Sheet preporučuje načelo najmanjih privilegija (Least Privilege) i Deny by Default (zadržavanje pristupa po zadanim postavkama). Za pozive alata to znači: Chatbot dobiva samo onu funkciju i dio podataka koji su nužni za dotični korak.

Mali alati umjesto univerzalnih sučelja

Alat getOrderStatus(orderId) lakše je osigurati nego otvoreni pristup bazi podataka. Alat requestCallback(topic, timeWindow) lakše je kontrolirati nego opću funkciju za slanje proizvoljnih poruka. Slobodne SQL, shell, URL ili e-mail funkcije nepotrebno povećavaju mogući utjecaj. Testni alati koji više nisu potrebni također bi trebali nestati iz produkcijskog kataloga.

Izvršavanje u kontekstu prijavljenog korisnika

Backend se ne smije oslanjati samo na to da će model proslijediti točan ID kupca. On mora izvesti trenutnog korisnika i zakupca iz pouzdane sesije te za svaki objekt iznova provjeriti postoji li pravo pristupa. Praktična razlika između javnog chata i zaštićenog područja detaljno je objašnjena u članku o identitetu i pristupu podacima u korisničkom portalu. Opći servisni račun s punim pristupom obično je pogrešna prečica za akcije povezane s korisnikom.

Deterministička validacija parametara

Parametri alata trebaju usku shemu: dopuštena polja, tipove, duljine, raspone vrijednosti i pravila stanja. ID termina mora pripadati korisniku, datum mora biti u dopuštenom rasponu, a akcija mora odgovarati trenutnom statusu. Nepoznata polja se odbijaju. Aplikacija bi također trebala osigurati da sam naziv alata dolazi s fiksne liste dopuštenih alata (allowlist), a ne da se izvršava iz slobodno generiranog teksta.

Potvrda mora prikazivati stvarnu akciju

Kod promjena s velikim posljedicama pitanje „Jeste li sigurni?“ nije dovoljno. OWASP smjernica za autorizaciju transakcija opisuje načelo „What You See Is What You Sign“: korisnici moraju moći prepoznati i potvrditi ključne podatke konkretne akcije. Za chatbot na web-stranici to, na primjer, znači:

• „Otkazati termin 18. kolovoza u 14:30 h“ umjesto „Potvrditi promjenu“
• „Promijeniti adresu dostave za narudžbu ...84 na Beč“ umjesto „Spremi podatke“
• „Izraditi zahtjev za povratni poziv s temom Račun“ umjesto „Pošalji zahtjev“

Potvrda se na poslužitelju veže točno za taj nacrt akcije. Ako se promijene cilj, iznos, termin, primatelj ili drugi bitni parametri, ona prestaje vrijediti. Dobiva kratko trajanje valjanosti i ne može se ponovno upotrijebiti za drugu akciju. Za osobito kritične postupke dodatno može biti potrebna ponovna prijava ili ljudsko odobrenje. Model ne smije preskočiti ovu razinu niti je zamijeniti umirujuće formuliranim odgovorom.

Planiranje idempotencije, ograničenja i puta oporavka

Čak i ispravno autoriziran poziv alata tehnički može stići dvaput: preglednik ponavlja zahtjev, isteklost vremena (timeout) pokreće ponovni pokušaj ili korisnik ponovno šalje istu poruku. Alati koji vrše zapise stoga bi trebali koristiti poslužiteljski idempotencijski ID. Za isti ID executes se ista akcija najviše jednom; ponovljeni pokušaj dobiva već poznati rezultat.

Dodatno, svaki alat treba odgovarajuća ograničenja: maksimalni broj poziva po sesiji, kratke timeout-e, ograničene ponovne pokušaje i prekid u slučaju neuobičajenih lanaca. Prije izvršavanja backend još jednom provjerava stanje. Tako se, primjerice, već otkazana rezervacija neće obrađivati drugi put. Gdje god je moguće, akciju prvo treba stvoriti kao nacrt ili zabilježeni nalog. Za neizbježno izravne promjene mora biti jasno kako se one kompenziraju, opozivaju ili prosljeđuju timu za podršku. Pripremljeni degradirani način rada i plan oporavka (rollback) sprječavaju potrebu za improvizacijom u slučaju smetnje.

Zapisivanje (logging) bez prikupljanja tajnih podataka

Sigurnosni zapisnik (log) trebao bi moći odgovoriti na pitanje tko je, na temelju čega, odobrio koju akciju i s kojim rezultatom ju je izvršio. Korisni podaci uključuju pseudonimizirani ID aktera, alat i verziju, referencu objekta, verziju pravila (policy), odluku o autorizaciji, ID potvrde, idempotencijski ID, vremensku oznaku i rezultat. Lozinke, tokeni, potpuni povijesni zapisi razgovora i nepotrebni osobni podaci ne pripadaju ovom zapisniku.

OWASP AI Agent Security Cheat Sheet preporučuje strukturirane podatke o odlučivanju za visokorizične akcije te odvajanje odluke od izvršenja. To je drukčije od potpunog tehničkog praćenja (tracing): Za sigurnosnu provjeru važan je sažet i pouzdan dokaz lanca odobrenja. Pohrana i pristup trebali bi se orijentirati prema stvarnoj potrebi provjere.

Robusna arhitektura u pet slojeva

1. Dijalog i prijedlog: Model prepoznaje namjeru i stvara strukturirani nacrt akcije, ali ništa ne izvršava izravno.
2. Odluka o pravilu (Policy decision): Deterministička komponenta provjerava listu dopuštenih alata (allowlist), korisnika, zakupca, objekt, parametre, klasu rizika i ograničenja.
3. Potvrda: Sučelje prikazuje ključne podatke akcije. Odobrenje je kratkotrajno i vezano uz nepromijenjeni nacrt.
4. Izvršenje: Uska komponenta za izvršavanje (executor) ponovno provjerava autorizaciju neposredno prije poziva i koristi idempotencijski ID.
5. Dokaz i reakcija: Rezultat, pogreške i lanac odobrenja zapisuju se uz štednju podataka; alarmiranje, kompenzacija i preusmjeravanje na čovijeka (human handoff) su definirani.

NIST AI RMF Core svrstava takve zadatke u kategorije Govern, Map, Measure i Manage. U praksi to znači: definirati odgovornosti i granice rizika, razumjeti kontekst korištenja, testirati kontrole i reagirati na uočena odstupanja.

Matrica testiranja prije puštanja u rad (Go-live)

Samo pozitivni testovi nisu dovoljni. Alat mora sigurno zakazati i u nepovoljnim uvjetima. U ponovljivu matricu testiranja moraju ući barem ovi slučajevi:

• Neprijavljeni ili neovlašteni korisnik zatraži akciju.
• Valjana sesija upućuje na objekt drugog zakupca.
• Bitni parametri promijene se nakon potvrde.
• Identitičan zahtjev ponovi se zbog isteka vremena ili dvostrukog klika.
• Alat vrati manipulirane upute ili neočekivana dodatna polja.
• Poziv prekorači vremenska, količinska ili financijska ograničenja.
• Ciljni sustav ispadne iz rada između provjere i izvršenja.
• Ovlaštenje se oduzme neposredno prije izvršenja.

Očekuju se ne samo uspješne akcije, već i jasna odbijanja, nepromijenjeni podaci i iskoristivi sigurnosni događaji. Prije aktiviranja pristupa s mogućnošću pisanja za stvarne korisnike, tijek se može testirati u Shadow Modeu s realističnim upitima bez stvarni izvršenja predloženih akcija.

Kontrolni popis za timove koji održavaju web-stranicu

• Je li svaki alat mali, namjenski i s fiksne liste dopuštenih alata (allowlist)?
• Provjeravaju li se korisnik, zakupac, objekt i akcija na poslužiteljskoj strani?
• Vrijede li Deny by Default i minimalna tehnička ovlaštenja?
• Vide li korisnici sve bitne podatke prije kritičnih akcija?
• Gubi li potvrda valjanost kod promjena i nakon kratkog vremena?
• Sprječava li idempotencijski ID dvostruko izvršenje?
• Postoje li ograničenja, timeout, prekid, kompenzacija i ljudska predaja (Human Handoff)?
• Ostaju li tokeni, tajne i nepotrebni osobni podaci izvan zapisnika (logova)?
• Pokriva li matrica testiranja pogreške u pravima, manipulacije, ponovljene pokušaje i ispad sustava?

Zaključak: Model predlaže, aplikacija odlučuje

Chatbot na web-stranici sposoban za poduzimanje akcija ne mora započeti s punim pristupom. Započnite s usko ograničenom, reverzibilnom akcijom i izgradite vidljivi lanac odobrenja oko nje. Kada se dizajn alata, poslužiteljska autorizacija, konkretna potvrda, idempotencija i put oporavka dizajniraju zajedno, chat ostaje koristan bez davanja modelu uloge sigurnosnog sustava. Za sljedeći korak isplati se radionica s proizvodnim timom, razvojem, podrškom i zaštitom podataka: odaberite stvarnu akciju, procijenite njezin rizik i prije prvog odobrenja u produkciji definirajte siguran slučaj odbijanja.