Az AI-chatbotok tool-hívásainak védelme: Jogosultságok, megerősítés és visszaállítási út

Egy weboldali chatbot működése alapjaiban változik meg, amint nemcsak válaszol, hanem intézkedéseket is kezdeményezhet. Egy időpont lekérdezése még átlátható. Egy időpont lemondása, egy címváltoztatás vagy egy visszatérítés viszont már a valós üzleti állapotot módosítja. A nyelvi modell javasolhat ehhez egy megfelelő tool-hívást (eszközmeghívást). Azt azonban, hogy az akció megengedett-e, egy különálló, determinisztikus alkalmazási rétegnek kell eldöntenie. A biztonságos AI-chatbot tool-hívások ezért nem egy különösen szigorú system promptból születnek, hanem a korlátozott funkciókból, a szerveroldali jogosultság-ellenőrzésből, az érthető megerősítésből és a kontrollált végrehajtási útvonalból.

Miért nem helyettesíti a jó nyelvi modell az autorizációt?

A modell valószínűségekkel dolgozik. Félreérthet egy szándékot, kiegészíthet egy paramétert, vagy reagálhat manipulált tartalmakra. Az OWASP Excessive Agency kockázati leírása három jellemző okot nevez meg: a túl sok funkciót, a túl messzire nyúló jogosultságokat és a túl nagy autonómiát. A probléma tehát nem csupán egy rosszindulatú beviteli adat. Egy többértelmű kérés vagy egy meggyőzően hangzó modellhiba is előkészíthet egy nem kívánt akciót.

A legfontosabb architektúrára vonatkozó szabály ezért így szól: A modell megfogalmaz egy javaslatot, de az alkalmazás autorizálja és hajtja végre azt. Egy olyan tool-call, mint a cancelAppointment, először csak egy strukturált szándék. Csak egy szabályirendszer-ellenőrzés (policy check) vizsgálja a felhasználót, a bérlőt (tenant), az objektumot, a megengedett akciót, a jelenlegi állapotot és a szükséges megerősítést. Ez a szétválasztás kiegészíti a weboldali chatbotok prompt injection elleni védelmét; és akkor is szükséges marad, ha semmilyen támadást nem észleltek.

Minden tool besorolása a hatása, nem pedig a neve alapján

A csapatoknak nem szabad az egész chatbotot átalányban „biztonságosként” vagy „kritikusként” osztályozniuk. Az egyes toolok hatása a döntő. Egy egyszerű kockázati mátrix tisztaságot teremt:

• Olvasási és kevéssé érzékeny: Nyitvatartási idők vagy nyilvánosan elérhető termékinformációk lekérése.
• Olvasási és személyes adatokra vonatkozó: Megrendelési státusz vagy ügyféladatok megjelenítése; ehhez ellenőrizni kell az identitást, a bérlőt és az objektumra való hivatkozást.
• Írási, de jól visszacsinálható: Belső visszahívási kérés létrehozása vagy egy kötelezettség nélküli megjegyzés hozzáadása.
• Nagy következményekkel járó vagy nehezen visszacsinálható: Foglalás törlése, kapcsolati adatok módosítása, tartalmak közzététele, üzenetek küldése vagy kifizetések indítása.

Ebből az osztályból következnek a jogosultságok, a megerősítési szint, a limitek és a naplózás. Egy általános engedély, miszerint „A chatbot használhatja a CRM-et”, túl durva. Jobb egy konkrét képességekből álló lista, meghatározott paraméterekkel és megengedett állapotátmenetekkel.

A legkisebb jogosultság elve a funkciók szabásánál kezdődik

Az OWASP Authorization Cheat Sheet a legkisebb jogosultság (Least Privilege) és az alapértelmezett tiltás (Deny by Default) elvét javasolja. A tool-hívások szempontjából ez azt jelenti: A chatbot csak azt a funkciót és adatrészt kapja meg, amely az adott lépéshez feltétlenül szükséges.

Kis eszközök az univerzális interfészek helyett

Egy getOrderStatus(orderId) toolt könnyebb biztosítani, mint egy nyílt adatbázis-hozzáférést. Egy requestCallback(topic, timeWindow) tool jobban ellenőrizhető, mint egy tetszőleges üzenetek küldésére szolgáló általános funkció. A szabad SQL-, Shell-, URL- vagy e-mail funkciók feleslegesen növelik a lehetséges hatáskört. A már nem használt teszt-tooloknak is el kell tűnniük a produktív katalógusból.

Végrehajtás a bejelentkezett felhasználó kontextusában

A backend nem bízhat meg pusztán abban, hogy a modell a helyes ügyfél-ID-t adja át. A megbízható munkamenetből kell levezetnie a jelenlegi felhasználót és bérlőt, és minden objektumra újra ellenőriznie kell, hogy létezik-e hozzáférés. A nyilvános chat és a védett terület közötti gyakorlati különbséget az ügyfélportálon belüli identitásról és adathozzáférésről szóló cikk részletesen elmagyarázza. Egy teljes hozzáféréssel rendelkező általános szervizfiók a felhasználóra vonatkozó akciók esetében legtöbbször rossz rövidítés.

Paraméterek determinisztikus validálása

A tool-paramétereknek szűk sémára van szükségük: engedélyezett mezők, típusok, hosszúságok, értéktartományok és állapotszabályok. Egy időpont-ID-nak a felhasználóhoz kell tartoznia, egy dátumnak az engedélyezett tartományba kell esnie, egy akciónak pedig passzolnia kell a jelenlegi státuszhoz. az ismeretlen mezőket vissza kell utasítani. Az alkalmazásnak ezenkívül biztosítania kell, hogy magának a toolnak a neve is egy fix engedélyezési listáról (allowlist) származzon, és ne szabadon generált szövegből kerüljön végrehajtásra.

A megerősítésnek a valódi akciót kell mutatnia

Kritikus módosítások esetén a „Biztos benne?” kérdés nem elegendő. Az OWASP tranzakció-autorizációs útmutatója leírja a „What You See Is What You Sign” (azt írod alá, amit látsz) elvet: A felhasználóknak képesnek kell lenniük a konkrét akció lényeges adatainak felismerésére és megerősítésére. Egy weboldali chatbot esetében ez például a következőket jelenti:

• „Augusztus 18-án 14:30-kor lévő időpont lemondása” a „Módosítás megerősítése” helyett
• „Szállítási cím módosítása a ...84 rendelésnél Bécsre” az „Adatok mentése” helyett
• „Visszahívási kérés létrehozása Számlázás témában” az „Igény elküldése” helyett

A megerősítés szerveroldalon pontosan ehhez az akciótervezethez kötődik. Ha a cél, az összeg, az időpont, a címzett vagy más lényeges paraméter megváltozik, a megerősítés érvényét veszti. Rövid érvényességi időt kap, és nem használható fel egy második akcióhoz. Különösen kritikus folyamatoknál emellett szükség lehet egy újbóli bejelentkezésre vagy egy ember általi jóváhagyásra. A modell ezt a szintet nem ugorhatja át, és nem helyettesítheti egy megnyugtatóan megfogalmazott válasszal sem.

Idempotencia, limitek és visszaállítási út tervezése

Még egy helyesen autorizált tool-hívás is beérkezhet technikailag kétszer: A böngésző megismétel egy kérést, egy időtúllépés (timeout) újrapróbálkozást (retry) vált ki, vagy a felhasználó elküldi ugyanazt az üzenetet még egyszer. Az írási tooloknak ezért szerveroldali idempotencia-ID-t kell használniuk. Ugyanarra az ID-ra ugyanaz az akció legfeljebb egyszer hajtódik végre; az újrapróbálkozás a már ismert eredményt kapja vissza.

Ezenkívül minden toolnak megfelelő határokra van szüksége: maximális hívások munkamenetenként, rövid időtúllépések, korlátozott újrapróbálkozások és a folyamat megszakítása szokatlan láncolatok esetén. A végrehajtás előtt a backend még egyszer ellenőrzi az állapotot. Így például egy már törölt foglalást nem dolgoz fel másodszor is. Ahol lehetséges, az akciót először tervezetként vagy előjegyzett megbízásként kell létrehozni. A elkerülhetetlenül közvetlen módosításoknál világosnak kell lennie, hogyan kompenzálják, vonják vissza azokat, vagy adják át egy ügyfélszolgálati csapatnak. Egy előkészített Degraded Mode és visszaállítási terv megakadályozza, hogy üzemzavar esetén rögtönözni kelljen.

Naplózás titkok gyűjtése nélkül

Egy biztonsági naplónak képesnek kell lennie válaszolni arra, hogy ki, milyen akciót, milyen alapon engedélyezett, és milyen eredménnyel hajtott végre. Célszerű adat az anonimizált/pszeudonimizált szereplő-ID, a tool és verziója, az objektum-referencia, a policy-verzió, az autorizációs döntés, a megerősítés-ID, az idempotencia-ID, az időpont és az eredmény. A jelszavak, tokenek, teljes chat-előzmények és a felesleges személyes adatok nem tartoznak ebbe a naplóba.

Az OWASP AI Agent Security Cheat Sheet strukturált döntési adatokat javasol a nagy kockázatú akciókhoz, valamint a döntés és a végrehajtás szétválasztását. Ez más, mint a teljes technikai nyomon követés (tracing): A biztonsági ellenőrzés szempontjából egy tömör, megbízható igazolás számít az engedélyezési láncról. A megőrzésnek és a hozzáférésnek a tényleges ellenőrzési igényhez kell igazodnia.

Robusztus architektúra öt rétegben

1. Párbeszéd és javaslat: A modell felismeri a szándékot és létrehoz egy strukturált akciótervezetet, de közvetlenül nem hajt végre semmit.
2. Policy-döntés: Egy determinisztikus komponens ellenőrzi a tool-engedélyezési listát, a felhasználót, a bérlőt, az objektumot, a paramétereket, a kockázati osztályt és a limiteket.
3. Megerősítés: A felület megmutatja a lényeges akcióadatokat. A jóváhagyás rövid életű, és a változatlan tervezethez kötődik.
4. Végrehajtás: Egy szűken korlátozott executor közvetlenül a hívás előtt újra ellenőrzi az autorizációt, és idempotencia-ID-t használ.
5. Igazolás és reakció: Az eredmény, a hibák és az engedélyezési lánc adatminimizált módon naplózásra kerülnek; a riasztás, a kompenzáció és az emberi átadás (human handoff) meg vannak határozva.

A NIST AI RMF Core az ilyen feladatokat a Govern, Map, Measure és Manage kategóriákba sorolja. A gyakorlatban ez a következőket jelenti: Felelősségek és kockázati határok kijelölése, a használati kontextus megértése, a kontrollok tesztelése és a megfigyelt eltérésekre való reagálás.

Tesztmátrix az élesítés előtt

A pozitív tesztek önmagukban nem elegendőek. Egy toolnak kedvezőtlen feltételek mellett is biztonságosan kell elbuknia. Legalább a következő eseteknek kell szerepelniük egy megismételhető tesztmátrixban:

• Egy nem bejelentkezett vagy jogosulatlan felhasználó kéri az akciót.
• Egy érvényes munkamenet egy másik bérlő objektumára hivatkozik.
• A lényeges paraméterek megváltoznak a megerősítés után.
• Ugyanazt a kérést időtúllépés vagy dupla kattintás miatt megismétlik.
• Egy tool manipulált utasításokat vagy váratlan extra mezőket ad vissza.
• Egy hívás túllépi az idő-, mennyiségi vagy költségkorlátokat.
• A célrendszer kiesik az ellenőrzés és a végrehajtás között.
• Egy jogosultságot közvetlenül a végrehajtás előtt vonnak meg.

Az elvárás nemcsak a sikeres akciók, hanem a világos elutasítások, a változatlanul maradó adatok és a felhasználható biztonsági események. Mielőtt az írási hozzáféréseket élesítenék a valódi felhasználók számára, a folyamat tesztelhető Shadow Mode-ban valósághű kérésekkel anélkül, hogy a javasolt akciókat végrehajtanák.

Ellenőrzőlista a weboldal-üzemeltető csapatoknak

• Minden tool kicsi, célspecifikus és egy fix engedélyezési listáról származik?
• A felhasználót, a bérlőt, az objektumot és az akciót szerveroldalon ellenőrzik?
• Érvényesül az alapértelmezett tiltás (Deny by Default) és a minimális technikai jogosultságok elve?
• Látják a felhasználók a kritikus akciók előtt az összes lényeges adatot?
• Módosítások esetén és rövid idő után érvényét veszti a megerősítés?
• Megakadályozza egy idempotencia-ID a dupla végrehajtást?
• Léteznek limitek, timeout, megszakítás, kompenzáció és emberi átadás (human handoff)?
• Kimaradnak a tokenek, a titkok és a felesleges személyes adatok a logokból?
• Lefedi a tesztmátrix a jogosultsági hibákat, a manipulációt, az újrapróbálkozásokat és a kieséseket?

Összegzés: A modell javasol, az alkalmazás dönt

Egy cselekvőképes weboldali chatbotnak nem kell teljes hozzáféréssel indulnia. Kezdje egy szűk korlátok közé szorított, visszacsinálható akcióval, és építse köré láthatóan az engedélyezési láncot. Ha a toolok méretezését, a szerveroldali autorizációt, a konkrét megerősítést, az idempotenciát és a visszaállítási utat együtt tervezik meg, a chat segítőkész marad anélkül, hogy a modellre ruháznák a biztonsági rendszer szerepét. A következő lépéshez érdemes egy workshopot tartani a termék-, fejlesztési, ügyfélszolgálati és adatvédelmi csapattal: Válasszanak ki egy valós akciót, sorolják be annak kockázatát, és határozzák meg az első éles engedélyezés előtt a biztonságos elutasítási esetet.