Zabezpečenie volaní nástrojov AI chatbota: Práva, potvrdenie a návratový plán

Webový chatbot sa zásadne zmení vo chvíli, keď má okrem odpovedania povolené spúšťať aj konkrétne akcie. Overenie termínu je ešte celkom jednoduché. Zrušenie termínu, zmena adresy alebo vrátenie platby však už menia reálny stav podnikania. Jazykový model smie v tomto procese navrhnúť vhodný volací nástroj (Tool Call). O tom, či je daná akcia prípustná, však musí rozhodnúť oddelená, deterministická aplikačná vrstva. Bezpečné volania nástrojov AI chatbota preto nevznikajú obzvlášť prísnym systémovým promptom, ale obmedzením funkcií, serverovým overením práv, zrozumiteľným potvrdením a kontrolovaným spôsobom vykonania.

Prečo dobrý jazykový model nenahrádza autorizáciu

Model pracuje s pravdepodobnosťami. Môže nesprávne pochopiť zámer, doplniť nežiaducu hodnotu parametra alebo reagovať na manipulovaný obsah. Popis rizík OWASP k téme Excessive Agency uvádza tri typické príčiny: príliš veľa funkčnosti, príliš rozsiahle oprávnenia a príliš vysoká autonómia. Problémom teda nie je len škodlivý vstup. Aj viacznačná požiadavka alebo plausibilne znejúca chyba modelu môže pripraviť pôdu pre neželanú akciu.

Najdôležitejšie architektonické pravidlo preto znie: Model formuluje návrh, no aplikácia ho autorizuje a vykoná. Volanie nástroja ako cancelAppointment je spočiatku len štruktúrovaným zámerom. Až kontrola pravidiel (Policy Check) overí používateľa, klienta (tenant), objekt, povolenú akciu, aktuálny stav a potrebné potvrdenie. Toto oddelenie dopĺňa ochranu pred Prompt Injection pri webových chatbotoch; zostáva nevyhnutné aj vtedy, keď nebol zistený žiaden útok.

Zaraďte každý nástroj podľa účinku, nie podľa názvu

Tímy by nemali celý chatbot paušálne klasifikovať ako „bezpečný“ alebo „kritický“. Rozhodujúci je účinok každého jednotlivého nástroja. Jasno do toho vnesie jednoduchá riziková matica:

• Na čítanie a málo citlivé: Zistenie otváracích hodín alebo verejne dostupných informácií o produktoch.
• Na čítanie a osobné údaje: Zobrazenie stavu objednávky alebo údajov o zákazníkovi; tu je potrebné overiť identitu, klienta a väzbu na konkrétny objekt.
• Na zápis, ale ľahko reverzibilné: Vytvorenie internej požiadavky na spätné volanie alebo doplnenie nezáväznej poznámky.
• Závažné alebo ťažko reverzibilné: Zrušenie rezervácie, zmena kontaktných údajov, publikovanie obsahu, odosielanie správ alebo iniciovanie platieb.

Z tejto kategórie vyplývajú práva, úroveň potvrdenia, limity a protokolovanie. Paušálne schválenie typu „Chatbot môže používať CRM“ je príliš nekonkrétne. Lepší je zoznam konkrétnych schopností s definovanými parametrami a povolenými prechodmi medzi stavmi.

Least Privilege začína pri dimenzovaní funkcií

Dokument OWASP Authorization Cheat Sheet odporúča zásadu najnižších privilégii (Least Privilege) a odmietnutie ako východiskový stav (Deny by Default). Pri volaniach nástrojov to znamená: Chatbot dostane iba tú funkciu a ten výsek dát, ktoré sú nevyhnutné pre daný krok.

Malé nástroje namiesto univerzálnych rozhraní

Nástroj getOrderStatus(orderId) sa zabezpečuje oveľa ľahšie ako otvorený prístup do databázy. Nástroj requestCallback(topic, timeWindow) je kontrolovateľnejší než všeobecná funkcia na odosielanie ľubovoľných správ. Voľné SQL, shell, URL alebo e-mailové funkcie zbytočne zväčšujú možný dopad. Aj testovacie nástroje, ktoré sa už nepoužívajú, by mali z produkčného katalógu zmiznúť.

Vykonávanie v kontexte prihláseného používateľa

Backend sa nesmie spoliehať len na to, že model odovzdá správne ID zákazníka. Musí odvodiť aktuálneho používateľa a klienta z dôveryhodnej relácie (session) a pre každý objekt znova overiť, či existuje oprávnenie na prístup. Praktický rozdiel medzi verejným chatom a chránenou zónou je podrobne vysvetlený v článku o identite a prístupe k dátam v zákazníckom portáli. Všeobecný servisný účet s plným prístupom je pre akcie viazané na používateľa väčšinou nesprávna skratka.

Deterministická validácia parametrov

Parametre nástrojov vyžadujú prísnu schému: povolené polia, typy, dĺžky, rozsahy hodnôt a pravidlá stavu. ID termínu musí patríť používateľovi, dátum sa musí nachádzať v povolenom rozsahu a akcia musí zodpovedať aktuálnemu stavu. Neznáme polia sa zamietnu. Aplikácia by mala okrem toho zaistiť, že samotný názov nástroja pochádza z pevného zoznamu povolených položiek (Allowlist) a nevykonáva sa zo voľne vygenerovaného textu.

Potvrdenie musí zobrazovať reálnu akciu

Pri závažných zmenách otázka „Ste si istý?“ nestačí. Smernica OWASP pre autorizáciu transakcií opisuje princíp „What You See Is What You Sign“: používatelia by mali vidieť a potvrdiť kľúčové údaje konkrétnej akcie. Pre webový chatbot to napríklad znamená:

• „Zrušiť termín 18. augusta o 14:30“ namiesto „Potvrdiť zmenu“
• „Zmeniť doručovaciu adresu pre objednávku ...84 na Bratislava“ namiesto „Uložiť údaje“
• „Vytvoriť požiadavku na spätné volanie s témou Faktúra“ namiesto „Odoslať požiadavku“

Potvrdenie sa na strane servera viaže presne na tento návrh akcie. Ak sa zmení cieľ, suma, termín, príjemca alebo iné podstatné parametre, potvrdenie stráca platnosť. Získa krátku dobu platnosti a nemožno ho znova použiť pre druhú akciu. Pri obzvlášť kritických úkonoch môže byť navyše vyžadované opätovné prihlásenie alebo schválenie človekom. Model nesmie túto úroveň preskočiť ani nahradiť upokojujúco formulovanou odpoveďou.

Naplánujte idempotenciu, limity a návratový plán

Aj správne autorizované volanie nástroja môže technicky doraziť dvakrát: prehliadač zopakuje požiadavku, vypršanie časového limitu spustí opätovný pokus (Retry) alebo používateľ pošle rovnakú správu znova. Zápisové nástroje by preto mali používať serverové idempotenčné ID. Pre rovnaké ID sa rovnaká akcia vykoná najviac raz; opätovný pokus dostane už známy výsledok.

Každý nástroj navyše potrebuje vhodné hranice: maximálny počet volaní na reláciu, krátke časové limity (Timeouts), obmedzené opakovania a prerušenie pri neobvyklých reťazcoch akcií. Pred vykonaním overí backend stav ešte raz. Tým sa zabráni napríklad tomu, aby sa už zrušená rezervácia spracovávala druhýkrát. Kde je to možné, akcia sa najskôr vytvorí ako návrh alebo predbežne zaevidovaná objednávka. Pri nevyhnuteľných priamych zmenách musí byť jasné, ako sa kompenzujú, odvolajú alebo odovzdajú tímu podpory. Pripravený degradovaný režim (Degraded Mode) a návratový plán zabránia tomu, aby sa v prípade poruchy muselo improvizovať.

Protokolovanie bez zberu tajných údajov

Bezpečnostný protokol by mal vedieť odpovedať na to, kto akú akciu na akom základe schválil a s akým výsledkom vykonal. Zmysel majú pseudonymizované ID aktéra, nástroj a verzia, referencia na objekt, verzia pravidiel, rozhodnutie o autorizácii, ID potvrdenia, ID idempotencie, časová pečiatka a výsledok. Heslá, tokeny, kompletné histórie chatov a zbytočné osobné údaje do tohto protokolu nepatria.

OWASP AI Agent Security Cheat Sheet odporúča štruktúrované dáta o rozhodnutiach pre rizikové akcie a oddelenie rozhodnutia od vykonania. To je niečo iné ako kompletné technické trasovanie (Tracing): pre bezpečnostnú kontrolu je podstatný stručný, verifikovateľný dokazovací reťazec schválenia. Uchovávanie a prístup by sa mali riadiť skutočnou potrebou kontroly.

Robustná architektúra v piatich vrstvách

1. Dialóg a návrh: Model rozpozná zámer a vygeneruje štruktúrovaný návrh akcie, ale nič priamo nevykoná.
2. Rozhodnutie o pravidlách (Policy): Deterministický komponent skontroluje Allowlist nástrojov, používateľa, klienta, objekt, parametre, rizikovú triedu a limity.
3. Potvrdenie: Rozhranie zobrazí kľúčové údaje akcie. Schválenie má krátku životnosť a je viazané na nezmenený návrh.
4. Vykonanie: Úzko vymedzený Executor skontroluje autorizáciu tesne pred volaním znova a použije ID idempotencie.
5. Dôkaz a reakcia: Výsledok, chyby a schvaľovací reťazec sa úsporne protokolujú; alarmy, kompenzácia a odovzdanie človeku sú presne definované.

Rámec NIST AI RMF Core zaraďuje tieto úlohy do kategórií Govern, Map, Measure a Manage. V praxi to znamená: stanoviť zodpovednosti a rizikové hranice, pochopiť kontext používania, testovať kontrolné mechanizmy a reagovať na spozorované odchýlky.

Testovacia matica pred spustením

Sami o sebe pozitívne testy nestačia. Nástroj by mal bezpečne zlyhať aj za nepriaznivých podmienok. Do opakovateľnej testovacej matice patria minimálne tieto prípady:

• Neprihlásený alebo neoprávnený používateľ požaduje vykonanie akcie.
• Platná relácia odkazuje na objekt iného klienta.
• Podstatné parametre sa po potvrdení zmenia.
• Rovnaká požiadavka sa zopakuje z dôvodu vypršania časového limitu alebo dvojitého kliknutia.
• Nástroj vráti zmanipulované inštrukcie alebo neočakávané dodatočné polia.
• Volanie prekročí časové, množstevné alebo nákladové limity.
• Cieľový systém vypadne medzi kontrolou a vykonaním.
• Oprávnenie je odobraté tesne pred vykonaním.

Očakávajú sa nie len úspešné akcie, ale aj jasné zamietnutia, nezmenené dáta a využiteľné bezpečnostné udalosti. Skôr než sa aktivujú prístupy pre zápis reálnym používateľom, možno priebeh overiť v stieňovom režime (Shadow Mode) s realistickými požiadavkami, bez toho aby sa navrhované akcie skutočne vykonali.

Kontrolný zoznam pre webové tímy

• Je každý nástroj malý, jedná sa o špeciálny účel a pochádza z pevného Allowlistu?
• Overujú sa používateľ, klient, objekt a akcia na strane servera?
• Platí Deny by Default a minimálne technické oprávnenia?
• Vidia používatelia pred kritickými akciami všetky podstatné údaje?
• Stráca potvrdenie platnosť pri zmenách a po krátkom čase?
• Zabraňuje ID idempotencie dvojitému vykonaniu?
• Existujú limity, časový limit, prerušenie, kompenzácia a odovzdanie človeku (Human Handoff)?
• Zostávajú tokeny, tajné kľúče a zbytočné osobné údaje mimo logov?
• Pokrýva testovacia matica chyby práv, manipuláciu, opätovné pokusy a výpadky?

Záver: Model navrhuje, aplikácia rozhoduje

Webový chatbot schopný konania nemusí začínať s plným prístupom. Začnite s úzko obmedzenou, reverzibilnou akciou a viditeľne okolo nej vybudujte schvaľovací reťazec. Ak sa dimenzovanie nástrojov, serverová autorizácia, konkrétne potvrdenie, idempotencia a návratový plán navrhnú spoločne, chat zostane užitočný bez toho, aby model dostal rolu bezpečnostného systému. Pre ďalší krok sa oplatí workshop s produktom, vývojom, podporou a ochranou osobných údajov: vyberte reálnu akciu, zaraďte jej riziko a pred prvým ostrým schválením definujte bezpečný prípad zamietnutia.