Rocket EVA ievieš bremzi MI aģentiem — darbību var apturēt pirms izpildes

Rocket Software 2026. gada 23. septembrī Voltemā, Masačūsetsā, paziņojumā par Rocket EVA paplašināšanu iepazīstināja ar Rocket PlanGuard — drošības slāni, kas ievieto politikas pārbaudes punktu starp MI aģenta spriešanu un darbības izpildi lieldatorā. Tas paredz iespēju iecerēto darbību izvērtēt, pirms tai piešķir piekļuvi sistēmai. Rocket min EVA pilotprojektus finanšu pakalpojumu, valsts pārvaldes, apdrošināšanas, mazumtirdzniecības un telekomunikāciju nozarē, taču paziņojumā nav atsevišķi norādīts, ka PlanGuard jau darbotos visos šajos pilotprojektos.

Par 2026. gada 23. septembrī izziņoto paplašinājumu SiliconANGLE publikācija Rocket EVA 2.0 ar PlanGuard raksturo kā gaidāmu versiju un izklāsta paredzētos lēmumus: darbību atļaut, noraidīt vai nodot papildu apstiprināšanai. Ja darbība tiek atļauta, aprakstītā arhitektūra tai piešķir konkrētajam uzdevumam ierobežotu pagaidu izpildes identitāti, kuru pēc darba pabeigšanas atsauc. Rocket struktūrvienības vadītājs Phil Buckellew šo pieeju pamatoja ar vārdiem: “decisions can no longer rely solely on permissions granted during account provisioning”.

Kur aģenta iecere kļūst par izpildāmu darbību

PlanGuard galvenā robeža atrodas brīdī, kad aģents no secinājuma pāriet pie rīka izsaukšanas. EVA var savākt darbības datus, sasaistīt pazīmes un piedāvāt risinājumu, piemēram, pēc CICS rindas vai pakešdarba kļūmes analīzes. Ieteikums pats par sevi nedod tiesības veikt izmaiņu: paredzētajam izpildes ceļam vajadzīgs politikas lēmums par konkrēto darbību.

1. Cilvēks ierosina uzdevumu, un aģents izvēlas rīku un sagatavo darbību atbilstoši savāktajam kontekstam.
2. Pirms rīka izsaukšanas politikas pārbaude izvērtē pieprasītāju, sesiju, izvēlēto rīku, darbības apstākļus un organizācijas noteikumus.
3. Lēmums darbību atļauj, noraida vai novirza cilvēka apstiprināšanai. Noraidījumam jāaptur izpildes mēģinājums; apstiprināšanas gadījumā izpildei jāgaida attiecīgais lēmums.
4. Atļautai darbībai tiek izmantotas tās uzdevumam paredzētās tiesības. Audita ieraksts sasaista pieprasījumu, lēmumu, izmantoto identitāti un rezultātu.

Šī secība parāda, kādu kontroli produkts sola, bet tās iedarbība ir atkarīga no reālajiem noteikumiem un no tā, vai visi attiecīgā rīka izsaukumi iet caur pārbaudes punktu. Piemēram, pārāk plaša atļauja var padarīt lēmumu formālu pat tad, ja tas tiek pieņemts pirms katras darbības. Savukārt piekļuve tam pašam rīkam pa citu ceļu apietu iecerēto robežu.

Identitāte un audita pēda nosaka kontroles tvērumu

Ar vispārēju aģenta kontu nevar skaidri parādīt, kāpēc konkrētā darbība bija atļauta. Pagaidu identitātes jēga ir piesaistīt pilnvaras apstiprinātajam uzdevumam un atsaukt tās pēc izpildes. PlanGuard aprakstītajai pieejai jāsadarbojas ar esošajiem lieldatora drošības pārvaldniekiem, tostarp RACF, ACF2 un Top Secret: politikas lēmums iegūst nozīmi tikai tad, ja faktiskā piekļuves kontrole to ievēro.

Audita pēdai savukārt jāļauj atšķirt cilvēka sākotnējo pieprasījumu no aģenta piedāvātās darbības un no darbības, kas patiešām izpildīta. Ierakstā jābūt redzamam piemērotajam noteikumam, apstiprinājuma nepieciešamībai, izpildes identitātei un rezultātam. Tas ir būtiski arī noraidītam mēģinājumam: bez tā nevar atjaunot, kuru darbību kontrole apturēja un kāpēc.

Lapaas Voice analīze pircējiem iesaka savā vidē pārbaudīt pilnvaru ierobežošanu un atsaukšanu, kā arī audita ierakstu pilnīgumu un eksportu. Šāds izmēģinājums palīdz atšķirt aprakstītu kontroles iespēju no konkrētā konfigurācijā ieviestas aizsardzības. Īpaši jāredz, vai pēc apstiprinājuma aģents var izpildīt tikai to darbību, par kuru lēmums tika pieņemts.

Kas jāpierāda pirms ieviešanas

PlanGuard demonstrācijā izšķirošs ir darbības faktiskais iznākums, nevis tikai aģenta atbilde par to. Viens un tas pats izmēģinājuma uzdevums ar atšķirīgiem politikas nosacījumiem var parādīt, vai atļauja, noraidījums un cilvēka apstiprinājums maina rīka izsaukšanu. Pārbaudei jāizmanto tāds piekļuves modelis un tādi rīki, kādus organizācija paredz savā lieldatora vidē.

• Politikas piemērošana. Vai ir redzams, kuri pieprasījuma un vides apstākļi noteica lēmumu? Vai noraidīta darbība paliek neizpildīta arī tad, ja aģents mēģina to ierosināt atkārtoti vai pa citu pieejamu ceļu?
• Cilvēka apstiprinājums. Kurš saņem pieprasījumu, kāda informācija viņam ir par iecerēto darbību un kas notiek pēc atteikuma vai neatbildēšanas? Vai apstiprinājums attiecas tikai uz sākotnēji izvērtēto darbību?
• Izpildes identitāte. Kādas tiesības tai ir pirms darbības, tās laikā un pēc pabeigšanas? Vai var parādīt, ka pagaidu pilnvaras pēc uzdevuma vairs nedarbojas?
• Audita pēda. Vai vienam pieprasījumam var izsekot no cilvēka līdz politikas lēmumam un izpildes rezultātam? Vai ierakstā saglabājas arī noraidījums, apstiprinātājs, izmantotā identitāte un noteikuma versija?

Šie jautājumi kļūst svarīgāki, kad EVA lietojums no diagnostikas un ieteikumiem pāriet uz sistēmas stāvokļa maiņu. Neprecīzu secinājumu operators vēl var izvērtēt pirms rīcības; izpildīta komanda jau ietekmē darba vidi. Tāpēc pircējam vajadzīgs pierādījums, ka politikas lēmums ir saistīts ar tieši to komandu, kas sasniedza lieldatoru, un ka apstiprinājuma gaidīšanas laikā tā netika izpildīta.

Ko pašreizējais statuss ļauj secināt

Rocket ir izziņojusi PlanGuard kā EVA paplašinājuma daļu un aprakstījusi tā politikas un identitātes kontroles arhitektūru. Publiski aprakstītie EVA pilotprojekti rāda platformas izmēģināšanu dažādās nozarēs; tie nesniedz neatkarīgu PlanGuard izpildes kontroles mērījumu konkrētā klienta konfigurācijā. Tādēļ nākamais nozīmīgais pierādījums būs atkārtojams izmēģinājums klienta vidē, kurā noraidījums aptur rīka izsaukšanu, apstiprinājums ierobežo atļauto darbību un pagaidu tiesību atsaukšana ir redzama audita pēdā.