Zabezpečení volání nástrojů AI chatbota: Oprávnění, potvrzení a plán návratu

Webový chatbot se zásadně změní, jakmile má kromě odpovídání možnost spouštět i akce. Dotaz na termín je ještě přehledný. Zrušení termínu, změna adresy nebo vrácení platby však mění reálný stav podnikání. Jazykový model přitom smí navrhnout odpovídající volání nástroje. O tom, zda je akce přípustná, však musí rozhodnout oddělená, deterministická aplikační vrstva. Bezpečná volání nástrojů AI chatbota proto nevznikají díky zvláště přísnému system promptu, ale díky omezeným funkcím, serverové kontrole oprávnění, srozumitelnému potvrzení a kontrolované cestě provádění.

Proč dobrý jazykový model nenahradí autorizaci

Model pracuje s pravděpodobnostmi. Může špatně pochopit záměr, doplnit parametr nebo zareagovat na manipulovaný obsah. Popis rizik OWASP k tématice Excessive Agency uvádí tři typické příčiny: příliš mnoho funkčnosti, příliš rozsáhlá oprávnění a příliš mnoho autonomie. Problémem tedy není jen škodlivý vstup. I mnohoznačný dotaz nebo uvěřitelně znějící chyba modelu může připravit nežádoucí akci.

Nejdůležitější pravidlo architektury proto zní: Model formuluje návrh, ale aplikace ho autorizuje a provádí. Volání nástroje jako cancelAppointment je zpočátku pouze strukturovaným záměrem. Teprve kontroly pravidel (policy checks) prověří uživatele, tenanta, objekt, povolenou akci, aktuální stav a potřebné potvrzení. Toto oddělení doplňuje ochranu před Prompt Injection u webových chatbotů; zůstává nezbytné i v případě, že nebyl rozpoznán žádný útok.

Zařazení každého nástroje podle dopadu místo podle názvu

Týmy by neměly celého chatbota paušálně klasifikovat jako „bezpečného“ nebo „kritického“. Rozhodující je dopad každého jednotlivého nástroje. Jednoduchá matice rizik vnesete jasno:

• Čtení s nízkou citlivostí: Zjištění otevírací doby nebo veřejně dostupných informací o produktech.
• Čtení s osobními údaji: Zobrazení stavu objednávky nebo zákaznických dat; k tomu je třeba ověřit identitu, tenanta a vazbu na objekt.
• Zápis, ale snadno vratný: Vytvoření interního požadavku na zpětné volání nebo doplnění nezávazné poznámky.
• Dopisující s velkými následky nebo těžko vratný: Zrušení rezervace, změna kontaktních údajů, publikování obsahu, odesílání zpráv nebo zahájení plateb.

Z této třídy vyplývají práva, úroveň potvrzení, limity a protokolování. Paušální schválení „Chatbot smí používat CRM“ je příliš hrubé. Lepší je seznam konkrétních schopností s definovanými parametry a povolenými přechody stavů.

Least Privilege začíná u návrhu funkcí

Příručka OWASP Authorization Cheat Sheet doporučuje zásady Least Privilege a Deny by Default. Pro volání nástrojů to znamená: Chatbot dostane pouze tu funkci a výřez dat, které jsou nezbytné pro daný krok.

Malé nástroje místo univerzálních rozhraní

Nástroj getOrderStatus(orderId) se zabezpečuje snáze než otevřený přístup k databázi. Nástroj requestCallback(topic, timeWindow) je kontrolovatelnější než obecná funkce pro odesílání libovolných zpráv. Volné funkce pro SQL, shell, URL nebo e-mail zbytečně zvětšují možný dopad. Ze produkčního katalogu by měly zmizet i již nepotřebné testovací nástroje.

Provádění v kontextu přihlášeného uživatele

Backend nesmí spoléhat pouze na to, že model předá správné ID zákazníka. Musí odvodit aktuálního uživatele a tenanta z důvěryhodné relace a pro každý objekt znovu ověřit, zda k němu existuje přístup. Praktický rozdíl mezi veřejným chatem a chráněnou oblastí je podrobně vysvětlen v článku o identitě a přístupu k datům v zákaznickém portálu. Obecný servisní účet s plným přístupem je pro akce vázané na uživatele většinou špatnou zkratkou.

Deterministická validace parametrů

Parametry nástrojů potřebují přísné schéma: povolená pole, typy, délky, rozsahy hodnot a stavová pravidla. ID termínu musí patřit uživateli, datum musí ležet v povoleném rozmezí a akce musí odpovídat aktuálnímu stavu. Neznámá pole jsou odmítnuta. Aplikace by měla navíc zajistit, že samotný název nástroje pochází ze stálého allowlistu a neprovádí se z volně vygenerovaného textu.

Potvrzení musí zobrazovat skutečnou akci

U změn s velkými následky nestačí otázka „Jste si jisti?“. Metodika OWASP pro autorizaci transakcí popisuje princip „What You See Is What You Sign“: Uživatelé by měli mít možnost rozpoznat a potvrdit klíčová data konkrétní akce. Pro webového chatbota to znamená například:

• „Zrušit termín 18. srpna ve 14:30“ místo „Potvrdit změnu“
• „Změnit doručovací adresu pro objednávku ...84 na Vídeň“ místo „Uložit data“
• „Vytvořit požadavek na zpětné volání s tématem Fakturace“ místo „Odeslat požadavek“

Potvrzení se na straně serveru váže přesně na tento návrh akce. Pokud se změní cíl, částka, termín, příjemce nebo jiné podstatné parametry, potvrzení pozbývá platnosti. Získává krátkou dobu platnosti a nelze jej znovu použít pro druhou akci. Pro zvláště kritické postupy může být navíc vyžadováno nové přihlášení nebo schválení člověkem. Model nesmí tento krok přeskočit ani nahradit uklidňující formulovanou odpovědí.

Zapojení idempotence, limitů a postupů pro návrat

I správně autorizované volání nástroje může z technických důvodů dorazit dvakrát: prohlížeč zopakuje požadavek, vypršení časového limitu (timeout) vyvolá opakovaný pokus (retry) nebo uživatel pošle stejnou zprávu znovu. Zápisové nástroje by proto měly používat serverové ID idempotence. Pro stejné ID se stejná akce provede nejvýše jednou; opakovaný pokus obdrží již známý výsledek.

Každý nástroj navíc potřebuje odpovídající limity: maximální počet volání na relaci, krátké timeouty, omezené opakované pokusy a přerušení při neobvyklých řetězcích. Před provedením backend znovu zkontroluje stav. Tak se například již zrušená rezervace nezpracuje podruhé. Kde je to možné, měla by být akce nejprve vytvořena jako návrh nebo předběžná objednávka. Pro nevyhnutelně přímé změny musí být jasné, jak je kompenzovat, odvolat nebo předat týmu podpory. Připravený degradovaný režim a plán návratu (rollback) zabrání improvizaci v případě poruchy.

Protokolování bez sběru tajných údajů

Bezpečnostní protokol by měl být schopen odpovědět na otázku, kdo, na jakém základě a s jakým výsledkem schválil a provedel jakou akci. Smysluplné údaje zahrnují pseudonymizované ID aktéra, nástroj a verzi, referenci na objekt, verzi pravidel (policy), rozhodnutí o autorizaci, ID potvrzení, ID idempotence, časové razítko a výsledek. Hesla, tokeny, úplná historie chatu a zbytečné osobní údaje do tohoto protokolu nepatří.

Příručka OWASP AI Agent Security Cheat Sheet doporučuje strukturovaná data o rozhodnutích pro rizikové akce a oddělení rozhodnutí od provádění. To je něco jiného než úplné technické trasování: pro bezpečnostní audit je podstatný stručný a spolehlivý doklad o řetězci schválení. Ukládání a přístup by se měly řídit skutečnou potřebou kontroly.

Robustní architektura v pěti vrstvách

1. Dialog a návrh: Model rozpozná záměr a vygeneruje strukturovaný návrh akce, ale nic přímo neprovádí.
2. Rozhodnutí podle pravidel (Policy): Deterministická komponenta zkontroluje allowlist nástrojů, uživatele, tenanta, objekt, parametry, třídu rizika a limity.
3. Potvrzení: Rozhraní zobrazí klíčová data akce. Schválení má krátkou životnost a je vázáno na nezměněný návrh.
4. Provedení: Úzce vymezený executor zkontroluje autorizaci těsně před voláním znovu a použije ID idempotence.
5. Důkaz a reakce: Výsledek, chyby a řetězec schválení se protokolují s ohledem na datovou úspornost; varování, kompenzace a předání člověku jsou definovány.

Rámec NIST AI RMF Core řadí tyto úkoly do kategorií Govern, Map, Measure a Manage. V praxi to znamená: stanovit odpovědnosti a hranice rizik, pochopit kontext použití, testovat ovládací prvky a reagovat na pozorované odchylky.

Testovací matice před spuštěním (Go-live)

Pouhé pozitivní testy nestačí. Nástroj by měl bezpečně selhat i za nepříznivých podmínek. Do opakovatelné testovací matice patří minimálně tyto případy:

• Akci požaduje nepřihlášený nebo neoprávněný uživatel.
• Platná relace odkazuje na objekt jiného tenanta.
• Podstatné parametry se po potvrzení změní.
• Identický požadavek se opakuje kvůli timeoutu nebo dvojkliknutí.
• Nástroj vrátí manipulované instrukce nebo nečekaná dodatečná pole.
• Volání překročí časové, množstevní nebo nákladové limity.
• Cílový systém vypadne mezi kontrolou a provedením.
• Oprávnění je odebráno těsně před provedením.

Očekávají se nejen úspěšné akce, ale také jasná odmítnutí, nezměněná data a využitelné bezpečnostní události. Než se aktivuje přístup pro zápis pro reálné uživatele, lze průběh otestovat v stínovém režimu (Shadow Mode) s realistickými dotazy bez provádění navrhovaných akcí.

Kontrolní seznam pro webové týmy

• Je každý nástroj malý, účelově vymezený a pochází z pevného allowlistu?
• Ověřují se uživatel, tenant, objekt a akce na straně serveru?
• Platí Deny by Default a minimální technická oprávnění?
• Vidí uživatelé před kritickými akcemi všechna podstatná data?
• Pozbývá potvrzení platnosti při změnách a po krátkém čase?
• Brání ID idempotence dvojímu provedení?
• Existují limity, timeout, přerušení, kompenzace a předání člověku (Human Handoff)?
• Zůstávají tokeny, tajné údaje a zbytečné osobní údaje mimo logy?
• Pokrývá testovací matice chyby oprávnění, manipulaci, opakované pokusy a výpadky?

Závěr: Model navrhuje, aplikace rozhoduje

Akceschopný webový chatbot nemusí začínat s plným přístupem. Začněte s úzce vymezenou, vratnou akcí a vybudujte kolem ní viditelný řetězec schválení. Pokud jsou návrh nástroje, serverová autorizace, konkrétní potvrzení, idempotence a postup pro návrat navrženy společně, zůstane chat užitečný, aniž by se modelu dávala role bezpečnostního systému. Pro další krok se vyplatí workshop s produktovým týmem, vývojem, podporou a ochranou osobních údajů: vyberte reálnou akci, zařaďte její riziko a před prvním živým schválením definujte bezpečný případ odmítnutí.