Droša KI tērzēšanas botu funkciju izsaukšana: tiesības, apstiprinājums un atsaukšana

Tīmekļa vietnes tērzēšanas bots kļūst nozīmīgi citāds, tiklīdz tas ne tikai atbild, bet drīkst arī ierosināt darbības. Tikšanās laika vaicājums vēl ir viegli pārvaldāms. Savukārt pieraksta atcelšana, adreses maiņa vai naudas atmaksa maina reālo biznesa stāvokli. Valodas modelis drīkst ieteikt piemērotu rīka izsaukumu (Tool Call). Tomēr tam, vai darbība ir pieļaujama, ir jālemj atsevišķam, deterministiskam lietotnes slānim. Droši KI tērzēšanas bota rīku izsaukumi tādēļ top nevis no īpaši stingra sistēmas prompta, bet gan no ierobežotām funkcijām, servera puses tiesību pārbaudes, saprotama apstiprinājuma un kontrolēta izpildes ceļa.

Kāpēc labs valodas modelis neaizstāj autorizāciju

Modelis strādā ar varbūtībām. Tas var pārprast nodomu, papildināt parametru vai reaģēt uz manipulētu saturu. OWASP risku aprakstā par Excessive Agency ir minēti trīs tipiski cēloņi: pārāk liela funkcionalitāte, pārāk plašas tiesības un pārāk liela autonomija. Problēma tātad nav tikai ļaundabīga ievade. Arī divdomīgs pieprasījums vai ticami skanoša modeļa kļūda var sagatavot nevēlamu darbību.

Tādēļ svarīgākais arhitektūras noteikums skan šādi: modelis noformulē priekšlikumu, bet lietotne to autorizē un izpilda. Rīka izsaukums, piemēram, cancelAppointment, vispirms ir tikai strukturēts nodoms. Tikai politikas pārbaude (Policy Check) pārbauda lietotāju, klientu/organizāciju (tenant), objektu, atļauto darbību, pašreizējo stāvokli un nepieciešamo apstiprinājumu. Šī nošķiršana papildina aizsardzību pret Prompt Injection tīmekļa vietņu tērzēšanas botos; tā paliek nepieciešama arī tad, ja nekāds uzbrukums nav konstatēts.

Iedalīt katru rīku pēc ietekmes, nevis pēc nosaukuma

Komandām nevajadzētu visu tērzēšanas botu vispārīgi klasificēt kā "drošu" vai "kritisku". Izšķiroša ir katra atsevišķā rīka ietekme. Vienkārša riska matrica rada skaidrību:

• Nolasošs un mazāk jutīgs: darba laika vai publiski pieejamas produkta informācijas ieguve.
• Nolasošs un personas datus saturošs: pasūtījuma statusa vai klienta datu attēlošana; šim nolūkam jāpārbauda identitāte, klients/organizācija un saistība ar objektu.
• Rakstošs, bet viegli atceļams: iekšēja atzvanīšanas pieprasījuma izveide vai neistošas piezīmes pievienošana.
• Ar būtisku ietekmi vai grūti atceļams: rezervācijas atcelšana, kontaktdatu maiņa, satura publicēšana, ziņojumu sūtīšana vai maksājumu ierosināšana.

No šīs klases izriet tiesības, apstiprinājuma līmenis, limits un žurnālēšana. Vispārīga atļauja "tērzēšanas bots drīkst izmantot CRM" ir pārāk neprecīza. Labāk ir definēt konkrētu spēju sarakstu ar noteiktiem parametriem un atļautajām stāvokļa pārejām.

Least Privilege sākas ar funkciju apjoma plānošanu

OWASP Authorization Cheat Sheet iesaka vismazāko privilēģiju principu (Least Privilege) un liegumu pēc noklusējuma (Deny by Default). Rīku izsaukumiem tas nozīmē: tērzēšanas bots saņem tikai to funkciju un datu daļu, kas ir nepieciešama konkrētajam solim.

Mazi rīki universālu saskarņu vietā

Rīku getOrderStatus(orderId) ir vieglāk aizsargāt nekā atvērtu piekļuvi datubāzei. Rīks requestCallback(topic, timeWindow) ir labāk kontrolējams nekā vispārīga funkcija jebkādu ziņojumu sūtīšanai. Brīvas SQL, Shell, URL vai e-pasta funkcijas nevajadzīgi palielina iespējamo ietekmi. Arī vairs nevajadzīgiem testa rīkiem vajadzētu pazust no produkcijas kataloga.

Izpildīt autorizētā lietotāja kontekstā

Aizmugursistēma (backend) nedrīkst paļauties tikai uz to, ka modelis nodos pareizo klienta ID. Tai ir jāizvelk pašreizējais lietotājs un klients/organizācija no uzticamās sesijas un katram objektam no jauna jāpārbauda, vai pastāv piekļuve. Praktiskā atšķirība starp publisku tērzēšanu un aizsargātu zonu ir sīki paskaidrota rakstā par identitāti un datu piekļuvi klientu portālā. Vispārējs servisa konts ar pilnu piekļuvi lietotāja darbībām parasti ir nepareizs īsceļš.

Deterministiski validēt parametrus

Rīka parametriem ir nepieciešama stingra shēma: atļautie lauki, tipi, garumi, vērtību diapazoni un stāvokļu noteikumi. Pieraksta ID jāpieder lietotājam, datumam jābūt pieļaujamajā diapazonā un darbībai jāatbilst pašreizējam statusam. Nezināmi lauki tiek noraidīti. Lietotnei ir arī jānodrošina, ka pats rīka nosaukums nāk no fiksēta atļauto saraksta (allowlist), nevis tiek izpildīts no brīvi ģenerēta teksta.

Apstiprinājumam jārāda reālā darbība

Būtisku izmaiņu gadījumā ar jautājumu "Vai esat pārliecināts?" nepietiek. OWASP darījumu autorizācijas vadlīnijas apraksta principu "What You See Is What You Sign": lietotājiem jāspēj atpazīt un apstiprināt konkrētās darbības būtiskie dati. Tīmekļa vietnes tērzēšanas botam tas nozīmē, piemēram:

• "Atcelt pierakstu 18. augustā plkst. 14:30" tā vietā, lai teiktu "Apstiprināt izmaiņas"
• "Mainīt piegādes adresi pasūtījumam ...84 uz Rīgu" tā vietā, lai teiktu "Saglabāt datus"
• "Izveidot atzvanīšanas pieprasījumu par tēmu Rēķins" tā vietā, lai teiktu "Nosūtīt pieprasījumu"

Apstiprinājums servera pusē tiek piesaistīts tieši šim darbības melnrakstam. Ja mainās mērķis, summa, datums, saņēmējs vai citi būtiski parametri, tas zaudē spēku. Tam tiek piešķirts īss derīguma termiņš, un to nevar izmantot atkārtoti otrai darbībai. Īpaši kritiskiem procesiem papildus var būt nepieciešama atkārtota pieteikšanās vai cilvēka apstiprinājums. Modelis nedrīkst ne izlaist šo soli, ne aizstāt to ar mierinoši noformulētu atbildi.

Plānot idempotenci, limitus un atsaukšanas ceļus

Arī pareizi autorizēts rīka izsaukums tehniski var tikt saņemts divreiz: pārlūkprogramma atkārto pieprasījumu, noildze izraisa atkārtotu mēģinājumu (retry) vai lietotājs nosūta to pašu ziņu vēlreiz. Tādēļ rakstošajiem rīkiem vajadzētu izmantot servera puses idempotences ID. Vienam un tam pašam ID tā pati darbība tiek izpildīta visvairāk vienu reizi; atkārtots mēģinājums saņem jau zināmo rezultātu.

Papildus katram rīkam ir nepieciešami atbilstoši ierobežojumi: maksimālais izsaukumu skaits sesijā, īsas noildzes, ierobežoti atkārtotie mēģinājumi un pārtraukšana neparastu ķēžu gadījumā. Pirms izpildes aizmugursistēma vēlreiz pārbauda stāvokli. Tādējādi, piemēram, jau atcelta rezervācija netiek apstrādāta otrreiz. Kur iespējams, darbība vispirms jāizveido kā melnraksts vai pieteikts uzdevums. Neizbēgami tiešām izmaiņām ir skaidri jāzina, kā tās kompensēt, atsaukt vai nodot atbalsta komandai. Sagatavots pazeminātas funkcionalitātes režīms (Degraded Mode) un atsaukšanas plāns novērš nepieciešamību improvizēt incidentu gadījumā.

Žurnālēt, nevācot noslēpumus

Drošības žurnālam jāspēj atbildēt uz jautājumu: kas, kādu darbību, uz kāda pamata ir apstiprinājis un ar kādu rezultātu izpildījis. Lietderīgi dati ir pseidonimizēts lietotāja ID, rīks un versija, objekta atsauce, politikas versija, autorizācijas lēmums, apstiprinājuma ID, idempotences ID, laiks un rezultāts. Paroles, žetoni (tokens), pilnas tērzēšanas sarakstes un nevajadzīgi personas dati šajā žurnālā neietilpst.

OWASP AI Agent Security Cheat Sheet iesaka izmantot strukturētus lēmumu datus paaugstināta riska darbībām un nošķirt lēmuma pieņemšanu no izpildes. Tas atšķiras no pilnas tehniskās izsekošanas (tracing): drošības auditam svarīgs ir lakonisks, ticams apstiprinājuma ķēdes pierādījums. Glabāšanai un piekļuvei vajadzētu atbilst faktiskajām pārbaudes vajadzībām.

Izturīga arhitektūra piecos slāņos

1. Dialogs un priekšlikums: modelis atpazīst nodomu un izveido strukturētu darbības melnrakstu, bet tieši neko neizpilda.
2. Politikas lēmums: deterministiska komponente pārbauda rīku atļauto sarakstu, lietotāju, klientu/organizāciju, objektu, parametrus, riska klasi un limitus.
3. Apstiprinājums: saskarne attēlo būtiskos darbības datus. Apstiprinājums ir īslaicīgs un piesaistīts nemainītajam melnrakstam.
4. Izpilde: stingri ierobežots izpildītājs (executor) vēlreiz pārbauda autorizāciju tieši pirms izsaukuma un izmanto idempotences ID.
5. Pierādījums un reakcija: rezultāts, kļūdas un apstiprināšanas ķēde tiek žurnālēti, taupot datus; trauksmes, kompensācija un nodošana cilvēkam ir definētas.

NIST AI RMF Core iedala šādus uzdevumus kategorijās Govern, Map, Measure un Manage. Praktiski tas nozīmē: noteikt atbildības un riska robežas, izprast lietošanas kontekstu, testēt kontroles mehānismus un reaģēt uz novērotajām novirzēm.

Testēšanas matrica pirms palaišanas reālajā vidē

Ar pozitīvajiem testiem vien nepietiek. Rīkam vajadzētu droši nobloķēties arī nelabvēlīgos apstākļos. Atkārtojamā testēšanas matricā jāiekļauj vismaz šādi gadījumi:

• Nepieteicies vai neautorizēts lietotājs pieprasa darbību.
• Derīga sesija atsaucas uz cita klienta/organizācijas objektu.
• Būtiski parametri mainās pēc apstiprināšanas.
• Tas pats pieprasījums tiek atkārtots noildzes vai dubultklikšķa dēļ.
• Rīks atgriež manipulētas instrukcijas vai negaidītus papildu laukus.
• Izsaukums pārsniedz laika, daudzuma vai izmaksu limitus.
• Mērķa sistēma pārtrauc darbību starp pārbaudi un izpildi.
• Piekļuves tiesības tiek atsauktas tieši pirms izpildes.

Gaidāmas ir ne tikai veiksmīgas darbības, bet arī skaidri noraidījumi, nemainīti dati un izmantojami drošības notikumi. Pirms rakstīšanas piekļuve tiek aktivizēta reāliem lietotājiem, plūsmu var pārbaudīt ēnas režīmā (Shadow Mode) ar reālistiskiem pieprasījumiem, neizpildot ieteiktās darbības.

Kontrolsaraksts tīmekļa vietņu komandām

• Vai katrs rīks ir mazs, mērķtiecīgs un no fiksēta atļauto saraksta?
• Vai lietotājs, klients/organizācija, objekts un darbība tiek pārbaudīti servera pusē?
• Vai tiek piemērots liegums pēc noklusējuma un minimālās tehniskās tiesības?
• Vai lietotāji pirms kritiskām darbībām redz visus būtiskos datus?
• Vai apstiprinājums zaudē spēku izmaiņu gadījumā un pēc īsa brīža?
• Vai idempotences ID novērš dubultu izpildi?
• Vai pastāv limiti, noildze, pārtraukšana, kompensācija un nodošana cilvēkam?
• Vai žetonu, noslēpumu un nevajadzīgu personas datu nav žurnālos?
• Vai testēšanas matrica nosedz tiesību kļūdas, manipulācijas, atkārtotus mēģinājumus un atteices?

Secinājums: modelis iesaka, lietotne nolemj

Tīmekļa vietnes tērzēšanas botam, kas spēj rīkoties, nav jāsāk ar pilnu piekļuvi. Sāciet ar stingri ierobežotu, atceļamu darbību un izveidojiet apstiprināšanas ķēdi redzami ap to. Ja rīka apjoms, servera puses autorizācija, konkrēts apstiprinājums, idempotence un atsaukšanas ceļš tiek izstrādāti kopā, tērzēšana paliek noderīga, nepiešķirot modelim drošības sistēmas lomu. Nākamajam solim ir vērts noorganizēt darbnīcu kopā ar produkta, izstrādes, atbalsta un datu aizsardzības komandām: izvēlieties reālu darbību, novērtējiet tās risku un definējiet drošu noraidīšanas gadījumu pirms pirmās reālās apstiprināšanas.