Pāriet uz galveno saturu
ANCVEIRS
Profesionālais darbsAnalīzeKiberdrošība

CTI automatizācija ar MI aģentiem: kā novērst kļūdainu lēmumu pārvēršanu reālās drošības darbībās?

MI aģenti var apkopot apdraudējumu izlūkošanu, pārbaudīt organizācijas ekspozīciju, sagatavot detektēšanas noteikumus un ierosināt incidentu ierobežošanas pasākumus. Tomēr starp pareizu analītisku secinājumu un drošu operacionālu rīcību atrodas robeža, kuru nedrīkst izdzēst automatizācijas ērtības vārdā. Uzbrucējam nav obligāti jākompromitē ugunsmūris, ja iespējams panākt, ka to nepareizi pārkonfigurē pati organizācijas aizsardzības sistēma.
Zigmārs AncveirsNeatkarīga kiberdrošības, digitālās noturības un pārvaldības analīzePublicēts: 2026-10-15Pārskatīts: 2026-10-1521 min

Kad izlūkošanas kļūda kļūst par drošības incidentu

Iedomāsimies uzņēmumu, kura drošības operāciju centrā ieviests MI aģents. Tā uzdevums ir analizēt ārējo kiberdraudu izlūkošanu, salīdzināt to ar organizācijas telemetriju un piedāvāt nepieciešamos aizsardzības pasākumus. Risinājums ir savienots ar SIEM, aktīvu inventāru un ugunsmūra pārvaldības sistēmu. Vadībai tas izskatās pēc saprotama produktivitātes uzlabojuma: mazāk manuālas informācijas apstrādes, ātrāka reaģēšana un lielāka iespēja nepalaist garām aktuālu apdraudējumu. Kādā brīdī aģents saņem ārēju CTI ierakstu, kurā IP adrese apzīmēta kā ļaunprātīga. Ierakstam ir augsts informācijas producenta piešķirtais pārliecības līmenis, un to atkārto vairākas datu plūsmas. Aģents secina, ka adrese nekavējoties jābloķē, sagatavo ugunsmūra konfigurācijas izmaiņu un izpilda to.

Tikai vēlāk noskaidrojas, ka adrese pieder koplietojamai infrastruktūrai, ko izmanto arī organizācijas kritisks sadarbības partneris. Bloķēšana pārtrauc leģitīmu datu apmaiņu. Savukārt vairākas šķietami neatkarīgās CTI plūsmas patiesībā pārpublicēja vienu sākotnējo, nepilnīgi pārbaudīto ziņojumu. Šis ir ilustratīvs scenārijs, nevis apgalvojums par kādu konkrētu notikušu incidentu. Taču tas atklāj būtisku arhitektūras kļūdu: sistēma ne tikai interpretēja nepilnīgu informāciju, bet arī ieguva iespēju savu interpretāciju pārvērst produkcijas infrastruktūras izmaiņā. Līdzīgas problēmas var rasties arī bez ļaunprātīgi manipulēta datu avota. Pietiek ar novecojušu indikatoru, nepareizi saprastu tīkla topoloģiju, nepilnīgu aktīvu inventāru vai kļūdaini ģenerētu komandu. Ja starp aģenta secinājumu un produkcijas izmaiņu nav neatkarīga riska izvērtējuma, šīs kļūdas pārvēršas reālās operacionālās sekās.

Tieši šeit MI izmantošana CTI jomā kļūst par drošības arhitektūras, nevis tikai analītikas kvalitātes jautājumu.

No datu plūsmas līdz izpildāmai komandai

Tradicionālā CTI darbplūsmā ārējā informācija tiek iegūta, normalizēta, analizēta un nodota atbildīgajai komandai. Analītiķis var ierosināt incidenta pārbaudi, jauna detektēšanas noteikuma izveidi vai ievainojamības prioritātes maiņu. Atkarībā no organizācijas procesa šādu lēmumu pārskata cits speciālists vai atbildīgais infrastruktūras administrators. Automatizācijas pievienošana pati par sevi nav problemātiska. Daudzas darbības iespējams veikt deterministiski: lejupielādēt datu plūsmu, pārbaudīt tās struktūru, identificēt dublikātus, salīdzināt CVE identifikatorus vai atjaunināt iekšēju analīzes tabulu. Šādās situācijās izpildes loģika ir ierobežota un tās darbības nosacījumi ir iepriekš zināmi.

MI aģents ievieš citu elementu. Tas var interpretēt uzdevumu dabiskā valodā, izvēlēties apakšuzdevumus, meklēt informāciju un patstāvīgi izlemt, kuru pieejamo rīku izmantot. Ja tā pilnvarās ietilpst arī konfigurācijas izmaiņas, analītiskā nenoteiktība var ietekmēt izpildes izvēli. Šajā procesā būtiski nošķirt trīs operācijas: informācijas iegūšanu, lēmuma piedāvāšanu un lēmuma izpildi. To apvienošana vienā aģenta sesijā nav neizbēgama tehnoloģiska prasība. Tā ir arhitektūras izvēle, kuru organizācijai jāspēj pamatot. Aģents var ļoti labi sagatavot priekšlikumu bloķēt noteiktu adresi, bet tam nav automātiski jābūt tiesībām šo priekšlikumu izpildīt. Tas var identificēt iespējamu kompromitētu kontu, bet konta apturēšanai nepieciešamais pierādījumu un autorizācijas slieksnis var būt augstāks nekā izmeklēšanas uzdevuma izveidei.

Atšķirība starp šīm darbībām ir būtiska arī atbildības noteikšanai. Ja algoritms pieņem kļūdainu lēmumu, organizācija nevar izskaidrot sekas ar apgalvojumu, ka “aģents pats tā izlēma”. Pilnvaru piešķiršana, kontroles projektēšana un darbības pieļaujamība paliek organizācijas atbildība.

Kāpēc MI aģents nav parasta automatizācijas skripta ekvivalents?

Deterministiska automatizācija parasti izpilda iepriekš definētu loģiku. Ja konkrēti dati atbilst noteikumam, sistēma veic noteiktu darbību. Šāds process arī var būt nepareizs, taču tā iespējamās darbības un lēmumu nosacījumus parasti ir vieglāk ierobežot un reproducēt. MI aģents var dinamiski veidot darbību secību. Tas var izvēlēties no vairākiem rīkiem, izmantot atbildes no ārējiem pakalpojumiem un pārformulēt savu sākotnējo mērķi. Arī pareizi autorizēts aģents var kļūdaini interpretēt saņemto saturu vai piešķirt tam lielāku autoritāti, nekā tam pienākas.

Tā ir īpaši nozīmīga problēma CTI apstrādē. Ārēja drošības publikācija var saturēt tehniskas komandas, skriptus, konfigurācijas fragmentus un ieteikumus, kuri paredzēti cilvēka izvērtēšanai. Ja aģents tos uztver kā tiešas izpildes instrukcijas, informācijas avots ir pārkāpis savu uzticamības robežu. Piemēram, drošības pētnieka publikācijā var būt norādīti konkrēti incidenta ierobežošanas pasākumi. Šis saturs pats par sevi nav autorizācija organizācijas infrastruktūrā izpildīt attiecīgās darbības. Publikācijas autors nezina uzņēmuma topoloģiju, biznesa atkarības un izmaiņu pārvaldības nosacījumus.

Tādēļ aģenta izpildes lēmumiem jābūt pakļautiem neatkarīgai politikai. Modeļa spēja izvēlēties darbību nenozīmē tiesības to realizēt. Šis princips ir svarīgs pat tad, ja izmantotais MI modelis ir lokāls, izolēts un organizācijas kontrolē. Lokāla izpilde samazina noteiktas ārējas atkarības, bet tā neatrisina nepareizu instrukciju interpretāciju vai pārmērīgu rīku pilnvaru problēmu.

Ko par aģentu drošību rāda 2026. gada standarti un izpēte?

OWASP 2025. gada decembrī publicēja Top 10 for Agentic Applications 2026. Tajā aplūkoti riski, kas rodas, MI aģentiem autonomi plānojot un veicot darbības dažādās sistēmās. Dokumentā īpaša uzmanība pievērsta aģenta mērķa pārņemšanai, rīku nepareizai izmantošanai, identitātes un privilēģiju ļaunprātīgai izmantošanai, aģentu piegādes ķēdes riskiem un neparedzētai koda izpildei. S01 Šīs kategorijas ir tieši attiecināmas uz CTI automatizāciju. Aģents, kas tikai apkopo publiskus ziņojumus, parasti rada citādu risku nekā aģents, kurš drīkst modificēt ugunsmūra noteikumus, izolēt galaiekārtas vai mainīt lietotāju piekļuves tiesības. Tas pats modelis un tie paši ievaddati var radīt ļoti atšķirīgas sekas atkarībā no tam piešķirtajām izpildes iespējām.

NIST 2026. gada maijā publicēja pārskatu par saņemtajām atbildēm uz informācijas pieprasījumu par MI aģentu drošības apsvērumiem. Dokumentā apkopots plašs viedokļu spektrs, tostarp atziņa, ka tradicionālie kiberdrošības principi joprojām ir nozīmīgi, bet autonomu aģentu kontekstā tie jāpielāgo. S02 Šis ir apspriešanas rezultātu apkopojums, nevis apstiprināts universāls tehniskais aģentu drošības standarts. Savukārt NIST AI Risk Management Framework un tā ģeneratīvā MI profils piedāvā plašāku riska pārvaldības struktūru. Tās būtība ir risku pārvaldība visā sistēmas dzīvesciklā, nevis tikai modeļa precizitātes pārbaude pirms ieviešanas. S03

2026. gada septembrī OWASP paziņoja arī par papildu aģentu kontroles standarta virzienu. Tomēr no šādas iniciatīvas esamības nevar automātiski secināt konkrētas CTI platformas atbilstību. Organizācijai jāpārbauda faktiskā dokumenta versija, prasības un to piemērošanas tvērums. S04 No šiem avotiem izriet skaidrs praktisks princips: aģenta drošību nevar vērtēt atrauti no tā instrumentiem, piekļuves tiesībām, datu avotiem un operacionālajām sekām.

Trīs atšķirīgas uzticēšanās robežas

CTI aģenta drošības arhitektūrā es izdalītu trīs uzticēšanās robežas. Pirmā robeža atrodas starp ārēju informāciju un organizācijas apstiprinātiem faktiem. Datu plūsma, pētnieka publikācija vai STIX objekts var būt tehniski korekts, bet tā saturs joprojām ir jāvērtē. Informācijas producenta piešķirts pārliecības līmenis nenozīmē, ka uzņēmums pats ir pārbaudījis attiecīgo apgalvojumu. Otrā robeža atrodas starp analītisku secinājumu un aizsardzības lēmumu. Pieņemsim, ka aģents ticami konstatē sakritību starp ārēju indikatoru un uzņēmuma telemetriju. Ar to var būt pietiekami, lai izveidotu izmeklēšanas uzdevumu. Taču automātiska konta apturēšana vai tīkla savienojuma bloķēšana var prasīt papildu kontekstu.

Trešā robeža atrodas starp apstiprinātu lēmumu un tiesībām to izpildīt. Pat ja cilvēks vai sistēma apstiprinājusi konkrētu darbību, izpildes mehānismam jāpārbauda tās tvērums, mērķa identitāte, derīguma termiņš un atbilstība atļautajām politikām. Pēdējā robeža ir īpaši svarīga. Ja aģents saņēmis apstiprinājumu bloķēt vienu adresi, šis apstiprinājums nedrīkst automātiski autorizēt vesela tīkla diapazona bloķēšanu. Tāpat iepriekš apstiprināts izmaiņu pieprasījums nedrīkst kļūt par beztermiņa pilnvarojumu turpmākām darbībām. Šo trīs robežu nodalīšana palīdz izvairīties no situācijas, kurā ārējs datu ieraksts netieši iegūst tiesības ietekmēt produkcijas sistēmu.

Datu saindēšana un instrukciju ievietošana CTI saturā

Ļaunprātīgi veidots ārējais saturs var censties ietekmēt to, kā MI aģents interpretē savu uzdevumu. Prompt injection gadījumā uzbrucējs ievieto instrukcijas neuzticamā datu avotā, cerot, ka modelis tās uztvers kā norādījumus, nevis analizējamu saturu. CTI jomā šāda iespēja ir īpaši nozīmīga, jo sistēmas apzināti apstrādā ārējo informāciju par ļaunprātīgu darbību. Atvērtas publikācijas, ievainojamību apraksti, koda fragmenti, incidentu ziņojumi un datu plūsmas var saturēt ļoti daudz tehniska teksta. Starp šādu informāciju un aģentam paredzētu instrukciju ne vienmēr pastāv cilvēkam acīmredzama vizuāla atšķirība.

Tomēr prompt injection nav vienīgais risks. Uzbrucējs var mēģināt saindēt pašu CTI datu kopu, ievietojot kļūdainus indikatorus vai maldinošas attiecības starp objektiem. Šādā situācijā aģents var sekot saviem sākotnējiem uzdevuma noteikumiem, bet izdarīt nepareizu secinājumu tāpēc, ka dati ir manipulēti. Šīs divas problēmas prasa daļēji atšķirīgus kontroles pasākumus. Instrukciju ievietošanas risku palīdz ierobežot stingra datu un instrukciju nošķiršana, savukārt datu saindēšanas risku — izcelsmes pārbaude, neatkarīgi novērojumi, konteksta validācija un aizliegums atsevišķam nepārbaudītam apgalvojumam automātiski izraisīt augstas ietekmes darbību.

Ar vienkāršu aizliegumu modelim “nepaklausīt ārējam tekstam” nepietiek. Nepieciešama tehniska arhitektūra, kurā neuzticams saturs nevar pats paplašināt atļauto rīku kopu vai mainīt izpildes politiku. Tāpēc CTI aģentu ieviešanā es prasītu, lai jebkura produkcijas darbība tiktu autorizēta ārpus MI modeļa un neatkarīgi no tā ģenerētā teksta.

Kļūdaini indikatori un automātiska bloķēšana

Viena no šķietami vienkāršākajām CTI automatizācijas iespējām ir indikatoru pārvēršana bloķēšanas noteikumos. Ja jauna IP adrese parādās ļaunprātīgas infrastruktūras sarakstā, sistēma to pievieno ugunsmūra ierobežojumiem. Tomēr IP adrese nav nemainīga uzbrucēja identitāte. Adreses tiek pārdalītas, izmantotas koplietojamās platformās, mākoņpakalpojumos un satura piegādes infrastruktūrā. Tā pati adrese var būt izmantota ļaunprātīgai darbībai vienā laika posmā, bet vēlāk apkalpot pilnīgi leģitīmu pakalpojumu. Arī domēni un citas tehniskās pazīmes var būt mainīgas vai kontekstjutīgas.

Tāpēc automātiskas bloķēšanas lēmumā jāvērtē ne tikai indikatora avots, bet arī tā aktualitāte, specifiskums, tehniskā vide un iespējamā blakusietekme. Dažās organizācijās ierobežota automātiska bloķēšana var būt pamatota. Piemēram, iepriekš definēta un pārbaudīta kontrole var īslaicīgi ierobežot skaidri noteiktu, atkārtotu ļaunprātīgu darbību, ja ir pietiekams pierādījumu kopums un ātra atcelšanas iespēja. Taču šāds izņēmums jāprojektē atbilstoši konkrētajai infrastruktūrai, nevis jāuztver kā universāla rekomendācija. Īpaši bīstama ir situācija, kurā sistēma pieņem ārēju confidence vērtību par neatkarīgu pierādījumu. STIX 2.1 ļauj norādīt informācijas producenta pārliecību, taču tas pats par sevi neapstiprina ieraksta patiesumu. S05

Līdz ar to CTI ieraksta tehniskā derīguma pārbaude, semantiskā kvalitāte un atļauja veikt bloķēšanu ir trīs atšķirīgas kontroles.

Uzbrucēja atribūcija kā automatizācijas slazds

Iepriekšējā rakstā par automatizētu uzbrucēju atribūciju analizēju, kā līdzīgas uzbrukuma tehnikas un nepietiekami neatkarīgi avoti var radīt kļūdaini pārliecinošu grupējuma identifikāciju. Šī problēma kļūst vēl nopietnāka, ja atribūcijas rezultāts tieši ietekmē aizsardzības darbības. Pieņemsim, ka aģents incidentu sasaista ar zināmu uzbrucēju grupējumu un tāpēc automātiski aktivizē specifisku ierobežošanas scenāriju. Ja grupējuma identificēšana ir kļūdaina, var tikt nepamatoti izvēlēts pārāk agresīvs vai nepiemērots reaģēšanas veids. Turklāt pat korekta grupējuma atribūcija ne vienmēr nosaka pareizo aizsardzības darbību. Organizācijai joprojām nepieciešams saprast, kādas sistēmas skartas, vai notikusi neatļauta piekļuve un kāda ir iespējamā ietekme.

Automātiski ģenerēts grupējuma nosaukums nedrīkst aizstāt šādu analīzi. Atribūcija var palīdzēt izvirzīt papildu izmeklēšanas hipotēzes vai noteikt ilgtermiņa apdraudējumu prioritātes. Taču augstas ietekmes darbības būtu jāpamato ar konkrētajai organizācijai raksturīgiem novērojumiem un pilnvarotām procedūrām, nevis ar grupējuma nosaukumu vien. Ja sistēma nespēj izskaidrot, kāpēc tieši konkrētais atribūcijas rezultāts maina izvēlēto rīcību, šī atribūcija var būt analītiski interesanta, bet operacionāli nebūtiska.

Izpildes pilnvaras: kas drīkst pieņemt galīgo lēmumu?

Drošības automatizācijā bieži diskutē par to, vai galīgais lēmums jāpieņem cilvēkam. Šis jautājums ir svarīgs, taču ar vienu apstiprinājuma pogu nepietiek. Cilvēks var apstiprināt kļūdainu ieteikumu, ja viņam nav pieejams sākotnējais pierādījums, darbības ietekmes novērtējums vai alternatīvās hipotēzes. Tāpat apstiprinājums var būt pārāk plašs: piemēram, “atļaut incidenta ierobežošanu” bez precīzi definētām sistēmām un konkrētas darbības. Tāpēc nepieciešams noteikt autorizācijas objektu. Apstiprinājumam jāattiecas uz konkrētu izpildāmu priekšlikumu ar norādītu mērķi, ietekmi, atbildīgo un derīguma nosacījumiem.

Pēc apstiprināšanas izpildes mehānismam vēlreiz jāpārbauda, vai priekšlikuma būtiskie parametri nav mainījušies. Pretējā gadījumā pastāv risks, ka aģents saņem atļauju vienai darbībai, bet izpilda citu. Šādai kontrolei jābūt neatkarīgai no modeļa teksta interpretācijas. Aģents var paskaidrot, kāpēc uzskata darbību par vajadzīgu, bet tam nevajadzētu pašam noteikt vai pārrakstīt autorizācijas politiku. Atsevišķām zema riska operācijām iespējams paredzēt automātisku izpildi bez katra gadījuma individuālas cilvēka apstiprināšanas. Taču tad jau iepriekš jābūt definētām darbības robežām, riska slieksnim, mērķu sarakstam un atcelšanas iespējām.

Brīvība izvēlēties instrumentu nedrīkst nozīmēt brīvību pašam paplašināt savas tiesības.

Desmit posmu pierādījumu un izpildes ķēde

Piedāvāju desmit posmu modeli, kas sasaista CTI informācijas kvalitāti ar reālas aizsardzības darbības kontroli. Tas ir autora arhitektūras priekšlikums, nevis oficiāls NIST vai OWASP sertifikācijas standarts.

PosmsJautājumsObligātais pierādījums vai kontrole
  1. Datu iegūšana
No kurienes nāk informācija?Avots, iegūšanas laiks, saturs, integritāte
  1. Datu uzticamība
Vai informācija ir pārbaudīta?Izcelsme, neatkarība, konteksts, nenoteiktība
  1. Organizācijas konteksts
Vai apdraudējums attiecas uz mūsu vidi?Aktīvu un ekspozīcijas sasaiste
  1. Analītiskais secinājums
Ko dati faktiski pamato?Nošķirti fakti, hipotēzes un alternatīvas
  1. Darbības priekšlikums
Ko tieši paredzēts mainīt?Strukturēts priekšlikums ar precīzu mērķi
  1. Ietekmes novērtējums
Ko varētu pārtraukt vai sabojāt?Atkarību, blakusefektu un atcelšanas analīze
  1. Autorizācija
Kam ir tiesības pieņemt lēmumu?Ārēja politikas pārbaude un atbildīgais
  1. Pirmsizpildes validācija
Vai atļautais priekšlikums nav mainījies?Parametru, mērķa un apstiprinājuma sasaistīšana
  1. Izpilde un novērošana
Vai izmaiņa veikta tieši paredzētajā tvērumā?Izpildes žurnāls, faktiskais sistēmas stāvoklis
  1. Atcelšana un pēcanalīze
Vai iespējams droši atjaunot stāvokli?Atcelšanas vai kompensējošās darbības pierādījums

Šajā modelī kritiskais nav posmu skaits. Kritiska ir ideja, ka sākotnējam izlūkošanas ierakstam nav tiešas, neierobežotas pārejas uz produkcijas darbību. Piemēram, aģents var izveidot priekšlikumu bloķēt konkrētu adresi. Neatkarīgs politikas komponents pārbauda, vai adrese nepieder aizsargātu mērķu sarakstam, vai darbībai nepieciešama papildu apstiprināšana un vai pieejama atcelšanas procedūra. Izpildes mehānisms saņem tikai precīzi autorizētu operāciju, nevis vispārīgu instrukciju “novērs apdraudējumu”. Šādi kļūdains MI priekšlikums ne vienmēr kļūst par izpildītu darbību. Lēmuma pieļaujamību nosaka pārbaudāmi kontroles noteikumi.

Tehniskā arhitektūra: no lasīšanas tiesībām līdz kontrolētai izpildei

Drošu CTI aģentu arhitektūru es veidotu ar skaidru lomu un piekļuves nodalījumu. Pirmajā slānī atrodas datu iegūšanas komponenti. Tie saņem informāciju no autorizētiem avotiem, saglabā sākotnējos ierakstus un piešķir izcelsmes metadatus. Šim slānim nav nepieciešamas tiesības mainīt produkcijas drošības kontroļu konfigurāciju. Otrajā slānī darbojas normalizācija un analītika. Šeit var tikt izmantoti deterministiski pārbaudītāji, noteikumu sistēmas un MI modeļi. To rezultāts ir strukturēts novērojums, hipotēze vai priekšlikums, nevis tieši izpildāma komanda.

Trešajā slānī atrodas riska un politikas izvērtēšana. Tai jāspēj pārbaudīt darbības kategoriju, mērķi, resursa kritiskumu, pieprasījuma aktualitāti un attiecīgās pilnvaras. Šo pārbaudi nedrīkst atstāt tikai tā paša modeļa ziņā, kas izveidoja darbības priekšlikumu. Ceturtajā slānī ir izpildes mehānisms ar pēc iespējas šaurākām tiesībām. Tā saskarnei jāpieņem tikai iepriekš definētas operācijas un konkrēti parametri. Vispārīga čaulas komandu izpilde nedrīkst kļūt par noklusēto risinājumu situācijās, kur iespējamas specifiskas, stingri tipizētas saskarnes.

Piektajā slānī nepieciešams neatkarīgs stāvokļa pārbaudes un audita mehānisms. Tas fiksē, ko sistēma patiesībā mainījusi, nevis tikai to, ko aģents apgalvo izdarījis. Šāda arhitektūra samazina risku, ka viens nepareizs modelis, nepārbaudīts spraudnis vai manipulēts CTI ieraksts var iegūt nekontrolētas izpildes tiesības.

Pieci skeptiski atteices scenāriji

Pirmais scenārijs — manipulēts ārējais avots. CTI publikācijā ievietotas instrukcijas, kas cenšas panākt aģenta rīcību ārpus sākotnējā uzdevuma. Drošības prasība: aģentam jāspēj analizēt šo saturu kā datus, bet tas nedrīkst mainīt autorizācijas noteikumus vai izpildīt tajā ietvertās instrukcijas. Otrais scenārijs — kļūdains, bet formāli derīgs indikators. STIX ieraksts atbilst datu shēmai, tam ir norādīta izcelsme un augsts producenta confidence, taču indikators ir novecojis vai neatbilst konkrētajai infrastruktūrai. Drošības prasība: datu tehniskā derīguma pārbaude nedrīkst aizstāt operacionālās ietekmes izvērtējumu.

Trešais scenārijs — tiesību paplašināšana. Aģentam dota iespēja veikt noteiktas diagnostikas darbības, bet tas mēģina izmantot citu rīku produkcijas konfigurācijas maiņai. Drošības prasība: pilnvaru politika ir ārēja un nav maināma ar modeļa ģenerētu tekstu. Ceturtais scenārijs — apstiprinājuma un izpildes neatbilstība. Cilvēks apstiprina vienas adreses bloķēšanu, bet līdz izpildei priekšlikums tiek paplašināts uz veselu diapazonu. Drošības prasība: apstiprinājums jāsaista ar nemaināmiem darbības parametriem, un izpildes brīdī tie atkārtoti jāpārbauda.

Piektais scenārijs — kļūdaina atcelšana. Bloķēšanas noteikums izrādās nepareizs, bet sistēmai nav droša veida to atsaukt vai noteikt, kuras citas konfigurācijas izmaiņas pa šo laiku radušās. Drošības prasība: iepriekš sagatavota atcelšanas vai kompensējošās rīcības procedūra un faktiskā stāvokļa pārbaude. Šie scenāriji pārbauda atšķirīgas arhitektūras robežas. Viena veiksmīga prompt injection testa izturēšana neapliecina drošību pret kļūdainiem indikatoriem, pilnvaru problēmām vai nepareizām atcelšanas darbībām.

Cilvēka apstiprinājums: nepieciešams, bet nepietiekams

Bieži piedāvātais risinājums aģentu riskam ir cilvēka apstiprinājums pirms bīstamas darbības. Tas var būt vērtīgs, taču tikai tad, ja apstiprinātājam ir pietiekama informācija un reāla iespēja atteikt. Ja cilvēkam tiek parādīts tikai MI ģenerēts formulējums “augstas prioritātes apdraudējums, ieteicama tūlītēja bloķēšana”, viņš var nespēt izvērtēt datu kvalitāti un biznesa ietekmi. Ja simtiem priekšlikumu tiek apstiprināti ikdienas rutīnā, apstiprināšanas process var kļūt formāls. Tāpēc lēmuma saskarnei jārāda pierādījumu izcelsme, pamatojums, alternatīvas un paredzamā ietekme. Īpaši svarīgi ir nodalīt faktus no modeļa pieņēmumiem.

Lēmuma apstiprināšana arī nedrīkst nozīmēt, ka izpildes slānis vairs neko nepārbauda. Piemēram, starp apstiprinājumu un darbību var mainīties mērķa resurss vai tā stāvoklis. Tādēļ nepieciešama pēdējā pārbaude pirms izpildes un iespēja droši atteikt darbību, ja būtiski mainījušies apstākļi. Cilvēks ir atbildības un sprieduma daļa, nevis universāls tehnisko kļūdu filtrs.

Kā pareizi projektēt drošības operāciju atcelšanu?

Ne visas drošības darbības ir vienādi atgriezeniskas. Ugunsmūra noteikuma pievienošanu dažkārt iespējams atsaukt, atjaunojot iepriekšējo konfigurāciju. Tomēr jāņem vērā, vai starplaikā veikti citi leģitīmi labojumi. Vienkārša visas konfigurācijas aizstāšana ar vecāku versiju var nejauši izdzēst šīs izmaiņas. Lietotāja konta apturēšanu var būt iespējams atcelt, taču darbības laikā var būt pārtraukti procesi vai zaudētas sesijas. Savukārt publiski izplatītu atribūcijas apgalvojumu vai kļūdaini nosūtītu incidenta paziņojumu nevar pilnībā atsaukt ar vienu tehnisku komandu. Šeit nepieciešama korekcijas un paziņošanas procedūra.

Tāpēc katrai darbību kategorijai jānosaka ne tikai atļaujas slieksnis, bet arī tās iespējamās sekas un atgriezeniskuma pakāpe. Augstas ietekmes, slikti atgriezeniskām darbībām būtu jāpiemēro stingrāka autorizācija un detalizētāks pierādījumu izvērtējums. Svarīgi arī dokumentēt sistēmas faktisko stāvokli pirms un pēc darbības. Bez tā kļūdu gadījumā var nebūt iespējams precīzi rekonstruēt, kas mainījies un kāda atcelšana nepieciešama.

Pārbaude ar simulācijām un adversāriem testiem

MI aģenta drošību nevar pierādīt tikai ar demonstrāciju, kurā tas sekmīgi izpilda iepriekš sagatavotu uzdevumu. Nepieciešama negatīvo scenāriju pārbaude. Piemēram, kā sistēma uzvedas, ja avots satur savstarpēji pretrunīgus apgalvojumus, ja ārējā publikācijā ievietotas instrukcijas vai ja tiek pieprasīta darbība pret aizsargātu infrastruktūras objektu? Tāpat jātestē piekļuves politikas. Aģentam nedrīkst būt iespēja izmantot alternatīvu rīku, lai izpildītu darbību, kuru galvenā saskarne nepieļauj. Atsevišķi jāvērtē kļūdainu datu scenāriji. Sistēmai jāspēj atteikt automātisku izpildi arī tad, ja indikators ir tehniski derīgs, bet tā nozīme vai aktualitāte ir apšaubāma.

Pārbaudes jāveic izolētā vidē, kur iespējams fiksēt sākotnējo un gala stāvokli, izpildes pieprasījumus, autorizācijas rezultātus un drošības politikas pārkāpumu mēģinājumus. Īpaši vērtīgi ir testi, kuros MI ģenerētais analītiskais secinājums ir nepareizs. Šādā situācijā jānoskaidro, vai neatkarīgā kontroles arhitektūra joprojām novērš neatļautu vai nesamērīgu darbību. Tas ir svarīgāks pierādījums nekā tikai augsta modeļa precizitāte uz zināmas testu kopas.

Kā vērtēt MI aģentu drošības pienesumu?

Organizācijām būs vēlme novērtēt, cik ātri MI aģents apstrādā CTI ierakstus, cik daudz incidentu uzdevumu izveido un cik automatizētas darbības izpilda. Šādi rādītāji palīdz analizēt produktivitāti, bet paši par sevi neapliecina drošības rezultātu. Piemēram, liels bloķēto adrešu skaits var būt gan veiksmīgas automatizācijas, gan pārlieku agresīvas kontroles pazīme. Ja sistēma samazina vidējo reaģēšanas laiku, bet vienlaikus pieaug kļūdainu izolāciju skaits, tās kopējā vērtība nav acīmredzama. Tādēļ būtu jāvērtē arī nepareizu darbību novēršana, autorizācijas pārkāpumu bloķēšana, atcelšanas procesu veiksmīgums un izpildes pierādījumu pilnīgums.

Svarīgi mērīt, cik bieži aģenta ieteikums tiek noraidīts pierādījumu trūkuma dēļ un vai šādas situācijas palīdz uzlabot datu kvalitāti un analītiku. Nevajadzētu automātiski pieņemt, ka mazāks cilvēka iesaistes apjoms nozīmē labāku drošību. Noteiktās darbību kategorijās papildu kontroles posms var būt būtiska riska samazināšanas daļa. Tāpēc CTI aģentu veiktspējas novērtējumam jāaptver gan darbības ātrums, gan kļūdu radītais risks un faktiskais aizsardzības rezultāts.

Praktiska CTI aģentu risku matrica

Darbības kategorijaIespējamā kļūdaAutorizācijas pieejaPārbaudes pierādījums
CTI datu apkopošanaNepareizs kopsavilkums vai avota interpretācijaAutomātiski, bez produkcijas rakstīšanas tiesībāmAtsauces uz sākotnējiem datiem
Indikatoru normalizācijaKļūdaina identifikatoru apvienošanaKontrolēts datu apstrādes processShēmas un integritātes testi
Threat hunting hipotēzeNepamatota anomālijas interpretācijaAnalītisks priekšlikumsDatu tvērums un alternatīvie skaidrojumi
Detektēšanas noteikuma projektsPārmērīgi plaša loģikaAtsevišķa testēšana pirms ieviešanasKontrolēti pozitīvie un negatīvie testi
Ugunsmūra bloķēšanaLeģitīmas infrastruktūras pārtraukšanaPolitikas pārbaude; atbilstošos gadījumos cilvēka apstiprinājumsTvērums, ietekme, atcelšanas plāns
Konta apturēšanaNepamatota lietotāja darbības ierobežošanaStingri definēts incidenta slieksnis un tiesībasNeatkarīgi novērojumi un identitātes konteksts
Galaiekārtas izolācijaKritiska biznesa procesa pārtraukšanaPaaugstināta autorizācijaAktīva kritiskums un atjaunošanas procedūra
Publisks atribūcijas paziņojumsKļūdains apgalvojums par uzbrucējuCilvēka redakcionāla un juridiska pārbaudeAvotu neatkarība, nenoteiktība, apstiprinājums

Šī matrica ir autora ierosināta pārvaldības struktūra. Tā nav universāla normatīva instrukcija, un konkrētie autorizācijas sliekšņi jānosaka pēc organizācijas riskiem un tiesiskā konteksta. Tās galvenais princips ir proporcionalitāte. Jo lielāka iespējamā kļūdainas darbības ietekme un jo grūtāk to atsaukt, jo stiprāks pierādījumu un autorizācijas pamats nepieciešams.

Ieviešanas prioritātes un pārvaldība

Ja organizācija sāk ieviest MI aģentus CTI darbplūsmā, es neieteiktu uzreiz piešķirt tiem plašas drošības administrēšanas tiesības. Sākotnēji būtu jāizveido uzticama datu iegūšanas un izcelsmes kontroles infrastruktūra. Aģents var apkopot ziņojumus, identificēt sakritības, piedāvāt hipotēzes un sagatavot lēmumu projektus, bet produkcijas sistēmu izmaiņas paliek atsevišķa procesa pārziņā. Nākamajā posmā var pievienot strukturētu priekšlikumu ģenerēšanu. Šeit būtiski, lai katrs priekšlikums būtu mašīnlasāms, ar konkrētiem mērķiem, pierādījumiem un norādītu ietekmi. Vispārīgs teksta ieteikums nedrīkst kļūt par neierobežotu izpildes komandu.

Tikai pēc negatīvo testu un autorizācijas kontroles validācijas varētu apsvērt šauri definētu, atgriezenisku darbību automatizāciju. Jāņem vērā arī izmaiņu pārvaldība. Ja tiek atjaunināts MI modelis, rīku apraksti, sistēmas instrukcijas vai piekļuves politika, iepriekšējais drošības testa rezultāts ne vienmēr attiecas uz jauno konfigurāciju. Tādēļ nepieciešama versēta izpildes vide, atkārtojami testi un skaidrs process, kas nosaka, kad automatizācija ir jāaptur. Organizācijas mērķim nevajadzētu būt panākt, lai aģents pieņem arvien vairāk neatkarīgu lēmumu. Mērķim jābūt droši automatizēt tikai tās darbības, kurām ir pietiekami skaidra pierādījumu, risku un autorizācijas struktūra.

Neatkarīgās izpildes kontroles tests ar kļūdainu CTI ierakstu

Lai pārbaudītu CTI aģenta drošības arhitektūru, sagatavotu laboratorijas ierakstu par šķietami ļaunprātīgu IP adresi, kura patiesībā ir atļauts testu resurss. Aģents var ieteikt bloķēšanu, bet tam nedrīkst būt iespēja pašam paplašināt atļauto darbības tvērumu, mainīt apstiprināto mērķi vai apiet neatkarīgu politikas pārbaudi. Izpildes komponentei jāsaņem konkrēti autorizēti parametri, ne brīvas formas valodas modeļa instrukcija. Otrajā testā avota tekstā ievietotu nepārprotamu, bet neuzticamu lūgumu izpildīt ārpus uzdevuma esošu komandu. Sagaidāmais rezultāts ir dokumentēta atteikšanās, nevis tikai modelim šķietami pareiza atbilde. Trešajā testā pārbaudītu kļūdaini apstiprinātas darbības atsaukšanu: vai saglabāts iepriekšējais stāvoklis, vai iespējams veikt drošu rollback un vai aizsardzības komanda redz pilnu izpildes ķēdi? Tieši šādi negatīvie testi parāda, vai aģentam piešķirtās tiesības ir faktiskas drošības robežas.

Secinājumi

MI aģentu izmantošana kiberdraudu izlūkošanā var būt vērtīga. Tā var palīdzēt ātrāk apstrādāt lielu informācijas apjomu, sasaistīt ārējos draudu novērojumus ar organizācijas aktīviem un sagatavot precīzākus izmeklēšanas vai aizsardzības priekšlikumus. Taču tieši iespēja aģentam pieņemt un izpildīt darbības rada jaunu drošības robežu. Kļūdains CTI ieraksts nav automātiski incidents. Nepareiza hipotēze nav automātiski produkcijas sistēmas bojājums. Par operacionālu problēmu šīs kļūdas kļūst tad, ja organizācijas arhitektūra pieļauj nekontrolētu pāreju no analīzes uz izpildi.

OWASP Agentic Top 10 2026 un NIST aģentu drošības izpēte apstiprina, ka autonomu sistēmu pilnvaru, rīku izmantošanas un uzticamības robežu jautājumi ir būtiska mūsdienu kiberdrošības problēma. Tomēr konkrēts risinājums nevar kļūt drošs tikai tāpēc, ka tā dokumentācijā minēts attiecīgais standarts vai vadlīnijas. Manuprāt, uzticamai CTI automatizācijas sistēmai jāspēj pierādīt trīs lietas. Pirmkārt, no kurienes nāk tās izmantotie apgalvojumi. Otrkārt, kāpēc konkrētā darbība ir pamatota attiecīgajā infrastruktūrā. Treškārt, kā neatkarīgs kontroles mehānisms nodrošina, ka aģents nevar izpildīt darbību ārpus atļautā tvēruma.

Pierādījumu robeža. OWASP Top 10 for Agentic Applications 2026 ir drošības risku klasifikācijas un labās prakses resurss, nevis tiesību akts vai apliecinājums, ka katrs uzskaitītais risks jau ir realizējies konkrētajā CTI sistēmā. Rīku pilnvaru, aģenta mērķa pārņemšanas un neparedzētu darbību riski ir pamats pārbaudes scenārijiem; atbilstība jāapstiprina konkrētās sistēmas testos. Avots: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/.

Ja šādu pierādījumu nav, straujāka automatizācija var vienkārši paātrināt nepareizus lēmumus. Labas CTI automatizācijas mērķis nav padarīt katru ieteikumu automātiski izpildāmu. Tas ir padarīt aizsardzības lēmumus ātrākus, pārbaudāmākus un drošāk ierobežotus.

21. Biežāk uzdotie jautājumi

Vai MI aģentam drīkst piešķirt piekļuvi ugunsmūra pārvaldībai?

Tehniski tas ir iespējams, taču šāda piekļuve jāierobežo pēc konkrētiem uzdevumiem, mērķiem un autorizācijas politikas. Nav ieteicams piešķirt vispārīgas administrēšanas tiesības tikai tāpēc, ka aģents spēj sagatavot aizsardzības priekšlikumus.

Vai STIX confidence vērtība ir pietiekama automātiskai bloķēšanai?

Nē. Tā atspoguļo informācijas producenta pārliecības novērtējumu, nevis neatkarīgu garantiju, ka konkrētais indikators ir pareizs un bloķēšana būs droša attiecīgajā infrastruktūrā.

Vai cilvēka apstiprinājums novērš aģenta kļūdas?

Ne pilnībā. Apstiprinātājam jābūt pieejamiem pierādījumiem un ietekmes novērtējumam, bet izpildes sistēmai neatkarīgi jāpārbauda darbības parametri un pilnvarojums.

Kā atšķiras prompt injection un CTI datu saindēšana?

Prompt injection mēģina ietekmēt aģenta instrukciju interpretāciju ar neuzticamu saturu. Datu saindēšana mēģina padarīt pašu analīzes informāciju kļūdainu. Tās var pārklāties, taču kontroles pasākumi nav identiski.

Vai lokāls MI modelis automātiski ir drošāks aģentu automatizācijai?

Lokāla izvietošana var samazināt noteiktus datu nodošanas un ārējo pakalpojumu riskus, taču nepareizu lēmumu, pārāk plašu tiesību un manipulēta ārējā satura problēmas joprojām saglabājas.

Vai visas drošības darbības jāapstiprina cilvēkam?

Ne obligāti. Zema riska, šauri definētas un pārbaudāmi atgriezeniskas darbības var automatizēt atbilstoši organizācijas politikai. Augstas ietekmes darbībām nepieciešama stingrāka kontrole.

Kā pārbaudīt, vai aģents ievēro savas pilnvaras?

Jāveic negatīvie testi, kuros aģents sastop manipulētu saturu, neatļautus mērķus un neatbilstošus darbības parametrus. Jāpārbauda arī tas, vai atļauju nav iespējams apiet ar citu pieejamu rīku.

Ko darīt, ja aģents kļūdaini izolējis kritisku sistēmu?

Jābūt iepriekš definētai incidenta un atcelšanas procedūrai, faktiskā stāvokļa pierādījumiem un atbildīgajam. Vienkārša aģenta restartēšana vai vispārīga konfigurācijas atjaunošana var būt nepietiekama.

Avoti un atsauces

  1. OWASP Top 10 for Agentic Applications for 2026. · OWASP GenAI Security Project
  2. Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI Agents. · NIST · 2026-05-18
  3. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1) · NIST · 2024-07-26
  4. 2026 Top 10 for LLM Applications and Agent Control Standard announcement. · OWASP GenAI Security Project
  5. STIX Version 2.1. · OASIS
  6. TAXII Version 2.1. · OASIS
  7. AI Risk Management Framework. · NIST
  8. AI Agent Standards Initiative. · NIST
  9. Concept Note: AI RMF Profile on Trustworthy AI in Critical Infrastructure. · NIST
  10. Agentic Top 10 publicēšanas paziņojums. · OWASP GenAI Security Project
  11. MITRE ATT&CK Updates — October 2026 (v20.0) · MITRE ATT&CK · 2026-10-13