MI aģentu drošība: kas notiek, kad programmatūra sāk patstāvīgi pieņemt lēmumus?

Par MI aģentu parasti sauc sistēmu, kas saņem mērķi, apstrādā pieejamo kontekstu, izvēlas turpmākās darbības un var izmantot rīkus vai citus pakalpojumus, lai sasniegtu rezultātu. Daži aģenti faktiski darbojas kā vienkārša darbplūsma ar valodas modeli vienā posmā; citi plāno vairāku soļu uzdevumus, dinamiski izvēlas API izsaukumus un pielāgo nākamo soli iepriekšējās darbības rezultātam. Šos gadījumus nevajag sajaukt. Noderīga, bet stingri determinēta automatizācija nav pēkšņi kļuvusi nedroša tikai tāpēc, ka tajā ir MI komponents. Risks ievērojami mainās tad, ja ārējam modelim tiek uzticēta brīvība izvēlēties ne tikai atbildes formulējumu, bet arī darbības mērķi, secību, parametrus vai saņēmēju.

No drošības viedokļa nav būtiski, vai aģents “domā” cilvēkam līdzīgi. Ir būtiski, vai izpildsistēma uztver tā ģenerēto rezultātu kā pietiekamu pamatu darbībai. Valodas modeļa teksts var būt priekšlikums, tomēr tam nevajadzētu kļūt par autorizācijas lēmumu. Ja aģents nolemj, ka jāmaina piekļuves politika, sistēmai neatkarīgi jāpārbauda, vai šāda darbība vispār ietilpst iepriekš apstiprinātajā uzdevumā, vai attiecīgajai identitātei ir tiesības mainīt konkrēto resursu un vai nepieciešama cilvēka piekrišana. Labs nodoms, veiksmīga iepriekšējo uzdevumu vēsture un pārliecinošs skaidrojums šīs pārbaudes neaizstāj.

Šeit jānošķir trīs jēdzieni. Autonomija raksturo, cik daudz turpmāko darbību sistēma var izvēlēties pati. Pilnvaras nosaka, kuras darbības tā drīkst izpildīt. Atbildība nosaka, kurš organizācijā ir apstiprinājis šīs pilnvaras, uzrauga risku un atbild par procesa pārvaldību. Autonomijas palielināšana nav pamatojums pilnvaru automātiskai paplašināšanai. Šis princips sakrīt ar NIST identitātes un autorizācijas iniciatīvas pamatproblēmu un ar Microsoft publicēto mazāko nepieciešamo tiesību pieeju aģentiem S01 S04.

Iedomāsimies uzņēmuma iekšējo aģentu, kuram dots uzdevums: sagatavot pārskatu par kavētiem klientu rēķiniem. Lai tas darbotos, tam nepieciešama piekļuve konkrētiem rēķinu ierakstiem un iespēja sagatavot kopsavilkumu. Projektā tomēr izrādās, ka integrācijai piešķirta plaša ERP servisa konta atslēga, ar kuru iespējams arī labot saņēmēja rekvizītus, eksportēt visu klientu datubāzi un veikt maksājumu sagatavošanu. Sākotnējais uzdevums izskatās nekaitīgs, bet pieejamās tehniskās iespējas jau veido būtiski lielāku ietekmes zonu. Ja modelis kļūdaini interpretē ierakstu, saņem ļaunprātīgu norādi no ārēja dokumenta vai nepareizi izvēlas rīku, sekas nosaka nevis tā uzdevuma formulējums, bet faktiskais autorizācijas apjoms.

Šis ir ilustratīvs scenārijs, nevis apraksts par konkrēta uzņēmuma incidentu. Tajā apzināti izdalītas četras robežas: starp sākotnējo lietotāja pieprasījumu un aģenta plānu; starp aģenta plānu un rīka izsaukumu; starp rīka identitāti un datu sistēmu; starp sagaidāmo rezultātu un faktiskajām blaknēm. Katrai robežai vajadzīga sava kontrole. Ja visas četras reducē uz vienu tekstu “aģentam nedrīkst izpaust datus”, drošības modelis ir balstīts uz instrukcijas ievērošanu, nevis uz pārbaudāmu piespiedu ierobežojumu. OWASP aģentisko risku taksonomija šo atšķirību palīdz strukturēt, bet pati taksonomija nav tehniska kontrole S02.

Arī veiksmīgs autorizācijas mehānisms vienā rīkā nenozīmē, ka ir droša visa darbplūsma. Lasīšanas tiesības vienā servisā, iespēja izsūtīt e-pastu otrā un piekļuve ārējam HTTP pieprasījumam trešajā var kopā radīt neatļautu datu izneses ceļu. Tāpēc jāpārbauda ne tikai atsevišķas lomas, bet arī kombinētā spēja: ko aģents var izdarīt, savienojot vairākus šķietami nevainīgus izsaukumus. Microsoft drošības vadlīnijās šis risks ir aprakstīts kā pārmērīgu kopējo privilēģiju un pārāk plašas rīku piekļuves problēma S04.

Aģents bieži vien darbojas ar lietotāja vārdā deleģētu piekļuvi vai atsevišķu servisa identitāti. Abiem modeļiem ir vieta, bet katrā atšķiras atbildības un audita nosacījumi. Lietotāja vārdā veiktā darbībā autorizācijai jāsaglabā konkrētā lietotāja tiesību robežas; atsevišķai aģenta identitātei jābūt skaidri reģistrētai, ar noteiktu īpašnieku, uzdevumu un pilnvaru dzīves ciklu. Kopīga API atslēga, ko izmanto vairāki aģenti un automatizācijas, apgrūtina izsekojamību un drošu atslēgšanu. NIST 2026. gada materiāli aģentu identificēšanu, autentificēšanu, autorizāciju un auditēšanu izvirza kā atsevišķus risināmus jautājumus S01 S03.

Piekļuvei jābūt pakārtotai resursam, darbībai un uzdevumam. Piemēram, ja aģentam jāizlasa pieci konkrēta projekta dokumenti, piekļuve visai dokumentu krātuvei nav saprātīgs noklusējums. Ja aģents analizē datus, tas nenozīmē, ka viņam vajadzīgas to dzēšanas vai publiskošanas tiesības. Ja sistēmai pieejama darba atmiņa vai meklēšanas indekss, piekļuves pārbaudēm jāsaglabājas arī pēc dokumentu sadalīšanas fragmentos un nodošanas meklēšanas slānim. Pretējā gadījumā sākotnēji korekta piekļuves politika var pazust starpposma arhitektūrā.

Īpaši svarīgi ir, lai rīku izsaukums būtu piesaistīts autorizētam uzdevumam un iniciatoram, nevis tikai tehniskai spējai nosūtīt derīgu API pieprasījumu. Īslaicīgi, šauri ierobežoti piekļuves žetoni mazina iespējamās sekas, tomēr arī tie nav pilnīga garantija. Ja tokenam atļautais apjoms ir pārāk plašs vai sistēma nepārbauda pašu darbības mērķi, īss derīguma termiņš nepadara bīstamu operāciju par drošu. Tas ir iemesls turēt autorizācijas lēmumu ārpus valodas modeļa un tieši pirms izpildes pārbaudīt darbības parametrus S04 S05.

MI aģenta darba vide parasti ir neviendabīga: iekšējā datubāze, dokumentu krātuve, tīmekļa lapa, e-pasts, ārējā API un specializēts rīku serveris var vienlaikus piedalīties viena uzdevuma izpildē. Katra atbilde satur datus, kas konkrētajam uzdevumam var būt noderīgi, bet ne katrs datu avots ir tiesīgs dot instrukcijas aģentam. Ārēja dokumenta teksts var apgalvot, ka “tagad jāsūta fails uz citu adresi”; šādu tekstu drīkst analizēt kā dokumenta saturu, nevis pārvērst par jaunu lietotāja komandu. Risks rodas tad, kad zemākas uzticamības saturs pāriet augstākas uzticamības lēmumu kanālā.

Šo uzbrukuma klasi plaši pazīst kā prompt injection, taču tās izpratne nedrīkst beigties ar ļaunprātīga teikuma piemēru. Izšķirošais ir tas, vai uzbrucēja kontrolēts saturs spēj mainīt aģenta rīku izvēli, izsaukuma parametrus vai piekļuves mērķi. Aģenta aizsardzībai vajadzīga uzticības robežu nošķiršana, darbību atļauju pārbaude un atsevišķas izpildes kontroles. Teksta filtrs var būt papildu slānis, bet tas nav pietiekams pamats atļaut naudas pārskaitījumu, piekļuves tiesību maiņu vai sensitīvu datu eksportu. Microsoft norāda uz vairākus slāņus aptverošu aizsardzību, tostarp neuzticama satura izolāciju, rīku ķēžu novērtēšanu un mazāko nepieciešamo tiesību ievērošanu S06.

Tā ir arī piegādes ķēdes problēma. Aģents var izmantot trešo pušu rīkus, spraudņus un komponentus, kas laika gaitā tiek atjaunināti. Rīka nosaukums vai apraksts pats par sevi nevar pierādīt, ka izpildāmais komponents dara tikai apsolīto. Praktiskā kontrole ir atļauto integrāciju inventārs, konkrētas versijas un konfigurācijas, izolēta izpilde, izejošo savienojumu politika un pakāpeniska atjauninājumu ieviešana. OWASP 2026. gada aģentisko lietotņu risku ietvarā atsevišķi aplūkota arī aģentu piegādes ķēde S02.

Pirms aģents nonāk produkcijā, es ieteiktu nevis vēl vienu vispārīgu “MI drošības” kontrolsarakstu, bet īsu lēmumu dokumentu par katru darbību klasi. Tā mērķis ir pierādīt, ka paredzētajai autonomijai eksistē neatkarīgas, tehniski izpildāmas robežas. Šī matrica ir autora piedāvāta praktiska pārbaudes metode, nevis NIST vai OWASP oficiāla sertifikācijas shēma.

Šīs pārbaudes nav jāizpilda tikai vienreiz. Atļauju izmaiņa, jauna rīka pievienošana, cita modeļa versija vai agrāk neizmantots datu avots var mainīt drošības profilu pat tad, ja aģenta redzamais nosaukums un sākotnējais lietotāja pieprasījums paliek nemainīgs. Ja drošības komanda nespēj uzrādīt konkrētas konfigurācijas un testu pierādījumus, apgalvojums “aģents strādā droši” ir pārāk plašs. Pareizāk ir pateikt, kuru darbību kopu esam pārbaudījuši, ar kādām piekļuves tiesībām un kuri scenāriji palikuši ārpus pārbaudes.

“Human in the loop” bieži tiek pasniegts kā universāls risinājums autonomijas riskam. Taču cilvēka līdzdalība nav drošības garantija pati par sevi. Ja apstiprinātājs redz tikai aģenta formulētu kopsavilkumu “veikt nepieciešamās izmaiņas”, bet neredz konkrētu saņēmēju, summu, failu, piekļuves izmaiņu vai API parametru, viņš nevar jēgpilni izvērtēt sekas. Tāpat neder apstiprinājums, pēc kura aģents drīkst mainīt jau apstiprināto darbību. Kontrolei jāattiecas uz precīzu operāciju un tās nemainīgajiem būtiskajiem parametriem, nevis uz abstraktu nodomu.

Ne katram dokumenta lasījumam vajadzīgs manuāls apstiprinājums. Tas radītu slodzi un varētu padarīt drošības procesu formālu. Saprātīgāks modelis ir riskā balstīti noteikumi: mazietekmīgām, atgriezeniskām darbībām — iepriekš noteikts politikas ietvars un uzraudzība; būtiskām izmaiņām vai datu nodošanai ārpus uzticamās vides — atsevišķa autorizācija; neatgriezeniskām vai finansiāli nozīmīgām darbībām — precīzs, nepārprotams apstiprinājums un papildu darījuma kontroles. Microsoft vadlīnijas tieši iesaka pastiprinātu apstiprināšanu augstas ietekmes darbībām, tostarp dzēšanai, pirkumiem, izvietošanai un tiesību maiņai S05.

Svarīga ir arī atteikuma pārbaude. Vai aģents patiešām apstājas pēc noraidīta pieprasījuma? Vai tas nevar sasniegt to pašu efektu caur alternatīvu rīku? Vai pārtrauktas darbplūsmas laikā jau veiktie starpposma ieraksti tiek korekti apstrādāti? Ja sistēma ir neatgriezeniski mainījusi stāvokli pirms apstiprinājuma saņemšanas, apstiprinājuma logs ir tikai lietotāja saskarnes elements, nevis drošības barjera.

Tradicionālajā lietojumprogrammu drošībā API pieprasījumu un datubāzes izmaiņu žurnāli jau ir pazīstami. Aģentam ar to nepietiek, ja nav iespējams sasaistīt darbības vienā uzdevuma ķēdē. Nepieciešams rekonstruējams ieraksts: kurš iniciēja uzdevumu, kāds bija apstiprinātais mērķis, kurš aģents un kura konfigurācijas versija strādāja, kurus rīkus tas izsauca, kādus būtiskos parametrus nosūtīja, ko autorizācijas slānis atļāva vai noraidīja un kurš apstiprināja augstas ietekmes darbību. Pierādījumu integritātei jābūt aizsargātai no pašas aģenta identitātes. Aģentam, kurš var izdzēst arī savus audita žurnālus, nav neatkarīgas auditējamības.

Vienlaikus nevajag pieņemt, ka pilns uzvedības atkārtojums vienmēr būs iespējams. Modeļa atbildes var atšķirties starp izsaukumiem; ārējās sistēmas un dati pa to laiku var mainīties. Tādēļ praktiskais mērķis ir nevis solīt absolūtu deterministisku atkārtojamību, bet saglabāt pietiekamus faktisko izsaukumu, lēmumu un rezultātu pierādījumus. Nedrīkst aizmirst arī pretēju risku: pārmērīgi detalizēti žurnāli paši var saturēt noslēpumus, personas datus un sensitīvus dokumentus. Pieeja tiem, glabāšanas ilgums un rediģēšanas vai maskēšanas noteikumi ir daļa no sistēmas drošības, nevis otršķirīgs administratīvs jautājums.

Praktisks tests ir pavisam vienkāršs: pēc vienas aģenta darbības paņemiet tās korelācijas identifikatoru un mēģiniet bez izstrādātāja mutiska skaidrojuma atrast sākotnējo pieprasījumu, pilnvarojumu, izsaukto rīku, autorizācijas lēmumu un izmaiņu galamērķa sistēmā. Ja kāds no šiem posmiem nav atrodams, rodas konkrēta izsekojamības nepilnība. NIST aģentu identitātes iniciatīva un Microsoft drošības materiāli uzsver identificēšanu, autorizāciju un auditēšanu kā savstarpēji saistītus uzdevumus S01 S04.

Pirmais solis nav visaptverošs aģentu aizliegums. Organizācijai vispirms jāsaprot, kuri procesi patiešām iegūst vērtību no patstāvīgas darbību izvēles un kuros pietiek ar determinētu darbplūsmu. Ja vajadzīgs tikai klasificēt pieprasījumus un sagatavot priekšlikumus, nav pamata piešķirt plašu rakstīšanas piekļuvi. Ja nepieciešama automatizēta darbība, sākotnēji to var ierobežot vienā skaidri noteiktā vidē ar nelielu atļauto resursu kopu, stingru ārējo savienojumu politiku un novērojamu uzdevuma budžetu. Kontroles vienkāršība šeit ir priekšrocība: vieglāk pierādīt desmit konkrētu aizliegumu efektivitāti nekā pārvaldīt simtiem neskaidru izņēmumu.

Otrais solis ir negatīvie testi — ne tikai pārliecināšanās, ka aģents izpilda paredzēto uzdevumu, bet pārbaude, ka tas nevar izpildīt aizliegto. Mēģiniet panākt piekļuvi cita lietotāja dokumentam, izsaukt neapstiprinātu rīku, mainīt augstas ietekmes operācijas saņēmēju pēc apstiprinājuma, turpināt pēc atteikuma vai pārvērst ārēja dokumenta tekstu par komandu. Šie testi jāveic kontrolētā vidē un ar skaidri noteiktu tvērumu. To mērķis nav demonstrēt modeļa vājumu kā tādu, bet pārbaudīt, vai arhitektūras aizsardzība darbojas arī tad, kad modelis kļūdās vai ir manipulēts. OWASP aģentisko lietotņu ietvars un drošības testēšanas materiāli ir lietderīgs apdraudējumu atlases sākumpunkts S02 S07.

Trešais solis ir reāla apturēšanas spēja. Aģenta procesa apstādināšana vēl nenozīmē, ka tā izsniegtās pilnvaras ir atsauktas: var palikt aktīvi tokeni, izpildes rindas, deleģēti uzdevumi un ārējos servisos ieplānotas darbības. Pārbaudiet atslēgšanu no gala līdz galam. Ja process tiek apturēts, bet jau izsniegtā piekļuve turpina darboties, organizācija nav sasniegusi praktisku kontroli pār autonomiju. Šī problēma īpaši izceļas sistēmās, kurās viens aģents vada vairākus rīkus vai deleģē uzdevumus tālāk S04.

Visstingrākais risinājums — jebkuru aģenta izvēli apstiprināt manuāli — nav piemērots katrai situācijai. Tas var iznīcināt automatizācijas praktisko vērtību, radīt apstiprinājumu nogurumu un novirzīt darbiniekus uz mazāk pārvaldītām alternatīvām. Pretējā galējība ir piešķirt aģentam plašu pastāvīgu piekļuvi un paļauties uz instrukcijām, ka tas ar tiesībām rīkosies saprātīgi. Abas pieejas ignorē darba faktiskās īpašības. Drošības projektēšanai vajadzīgi atšķirīgi autonomijas līmeņi, ko nosaka nevis reklāmas solījumi, bet kļūdas iespējamā ietekme, atgriezeniskums, datu jutīgums un iespēja pamanīt neatļautu darbību pirms seku iestāšanās.

Var būt pilnīgi pieņemami uzticēt aģentam prioritizēt iekšējus, nepubliskotus uzdevumu melnrakstus, ja tas nevar mainīt piekļuves tiesības vai izsūtīt informāciju. Savukārt produkcijas konfigurācijas maiņai, sensitīvu datu eksportam vai maksājuma iniciēšanai ar identisku autonomijas līmeni nepietiks. Šī nav pretruna: abos gadījumos izmantotais modelis var būt viens un tas pats, bet pieļaujamais darbības risks atšķiras. Tāpēc organizācijai jāapstiprina aģentu lietojuma scenāriji, nevis jāizsniedz abstrakta atļauja “izmantot MI aģentus”.

To labi parāda arī 2026. gada publiskās diskusijas raksturs. NIST vēl veido demonstrācijas un prasību pieredzes bāzi, OWASP piedāvā aktuālu draudu klasifikāciju, bet tehnoloģiju piegādātāji publicē konkrētu identitātes, politiku un uzraudzības realizāciju piemērus. No šiem avotiem nevar secināt, ka jebkura organizācija jau ir pilnībā atrisinājusi aģentu drošības problēmu vai ka viena platforma nodrošina universālu aizsardzību. Var secināt ko praktiskāku: vispirms jāierobežo reālās pilnvaras un darbību ceļi, pēc tam jāpārbauda, vai šie ierobežojumi darbojas arī neparedzētos scenārijos S01 S02 S05.

MI aģentu ieviešanas galvenais pārbaudījums nav tas, vai demonstrācijā tie spēj patstāvīgi pabeigt iespaidīgu uzdevumu. Tas ir jautājums, vai organizācija spēj precīzi pateikt, ko aģents nedrīkst darīt, tehniski neļaut tam šīs robežas pārkāpt un pēc notikuma pierādīt, kādas darbības patiesībā tika veiktas. Autonomija dod ātrumu un elastību, bet šo ieguvumu nedrīkst finansēt ar nekontrolējamām pilnvarām.

Praksē labs sākuma kritērijs ir stingrs: pirms nākamā rīka pievienošanas aģentam jāspēj uzrādīt iepriekšējā rīka tiesību tvērumu, noraidīto darbību testus, pilnvaru atsaukšanas darbspēju un pilnu izpildes ķēdes izsekojamību. Ja šādu pierādījumu nav, problēma nav tikai tajā, ka MI vēl nav pietiekami uzticams. Problēma ir tajā, ka organizācija vēl nav izveidojusi drošu sistēmu, kurā šim MI rīkoties.