
MI aģenta apstiprinājuma poga nav drošības robeža — vajadzīgs saglabāts stāvoklis

MI aģenta sensitīvu rīka izsaukumu apturiet pirms izpildes un saglabājiet gan darbplūsmas stāvokli, gan konkrēto darbības priekšlikumu. Apstiprinājuma poga tikai nosūta lēmumu; serverim vēl jāpārbauda, vai pilnvarota persona atļāvusi tieši to rīku, mērķi un argumentus, kurus izpildītājs izmantos.
LangGraph pārtraukumu dokumentācija apraksta, kā interrupt() aptur izpildi, saglabā stāvokli kontrolpunktā un ļauj to vēlāk atsākt ar Command, izmantojot to pašu thread_id. Ražošanas vidē vajadzīga noturīga kontrolpunktu glabātuve. Atsākot pārtrauktā mezgla kods sākas no jauna, tāpēc darbībai ar ārēju efektu jāatrodas pēc pārtraukuma un pēc servera pārbaudes.
Apturiet izpildi pie rīka robežas
Nosakiet, kuri rīki var mainīt datus, nosūtīt ziņas, atklāt informāciju vai veikt maksājumu, un katram šādam izsaukumam paredziet pārbaudes punktu. Ja to pašu rīku var izsaukt arī pa citu darbplūsmas zaru, pārbaudei jāaptver arī šis ceļš. Drošākais novietojums ir izpildes komponents, kuru aģents nevar apiet, izvēloties citu uzvedni vai darbību secību.
Atdaliet priekšlikuma sagatavošanu no ārējā efekta. Aģents drīkst sagatavot rīka nosaukumu, mērķa resursu un argumentus, bet izpildītājs tos saņem tikai pēc pārbaudes. Ja pirms interrupt() tiek nosūtīts e-pasts vai mainīts ieraksts, mezgla atkārtota palaišana šo darbību var atkārtot. Arī priekšlikuma saglabāšanai šajā mezglā jābūt idempotentai vai jānotiek atsevišķā iepriekš pabeigtā solī.
Saglabājiet priekšlikumu un tā versiju
Minimālais ieraksts sasaista darbplūsmas un kontrolpunkta identifikatoru ar priekšlikuma ID, versiju, rīka nosaukumu, mērķi un normalizētiem argumentiem. Pievienojiet argumentu jaucējvērtību, sākotnējā pieprasītāja identitāti, piemērojamo pilnvaru politiku un lēmuma derīguma termiņu. Jaucējvērtība palīdz atklāt izmaiņas; tā pati par sevi nepiešķir pilnvaras un neaizstāj piekļuvi pašiem saglabātajiem argumentiem.
Vienkārša stāvokļu shēma ir sagatavots → gaida pārbaudi → apstiprināts → izpildē → pabeigts. Noraidījums aizver konkrēto priekšlikumu. Labojums izveido jaunu argumentu versiju un atgriež to pārbaudē; vecais apstiprinājums uz jauno versiju neattiecas. Glabājiet arī iepriekšējo versiju sasaisti, lai vēlāk varētu noteikt, ko pārbaudītājs redzēja un kas nonāca līdz rīkam.
Kontrolpunktam un priekšlikumam jābūt noturīgi saglabātiem, pirms pārbaudītājam parādās gaidošs uzdevums. Ja serveris pēc restartēšanas atrod paziņojumu, bet nevar atjaunot ar to saistīto stāvokli, lēmumu izpildei nepieņem. Tāpat neatsāciet plūsmu, ja priekšlikuma versija vairs neatbilst saglabātajam kontrolpunktam.
Parādiet cilvēkam izpildāmo darbību
Pārbaudes skatā rādiet rīku, konkrēto mērķi, būtiskos argumentus un paredzamo ārējo efektu. Nosūtāma e-pasta gadījumā tie ir, piemēram, adresāts, temats un saturs; ar aģenta skaidrojumu par nodomu nepietiek. Ja sensitīva vērtība jāaizklāj, atstājiet redzamu tās pārbaudei vajadzīgo kontekstu un skaidri norādiet, kura daļa ir paslēpta.
Skatu veidojiet no saglabātā priekšlikuma, nevis no atsevišķa modeļa rakstīta kopsavilkuma. Pretējā gadījumā cilvēks var apstiprināt vienu aprakstu, kamēr izpildītājs saņem citus argumentus. Lēmuma pieprasījumā izmantojiet strukturētas izvēles — apstiprināt, labot vai noraidīt — kopā ar priekšlikuma ID un versiju; brīva teksta komentārs var paskaidrot izvēli, bet nedrīkst nemanāmi aizstāt rīka argumentus.
Labojumu uztveriet kā jaunu priekšlikumu: validējiet mainītos laukus, saglabājiet nākamo versiju un parādiet galīgo darbību apstiprināšanai. Piemēram, ja pārbaudītājs nomaina e-pasta adresātu, lēmumam jāattiecas uz jauno adresātu un saturu kopā. Tas nepieļauj, ka labojums vienā laukā nejauši apstiprina nepārskatītas izmaiņas citos.
Pirms atsākšanas vēlreiz pārbaudiet pilnvaras
OWASP aģentu drošības vadlīnijas prasa pilnvaras pārbaudīt izpildes komponentā ārpus aģenta konteksta un apstiprinājumu piesaistīt precīzam izsaukumam. Tajās norādīts, ka ar user_confirmed pazīmi nepietiek: jāņem vērā lēmuma pieņēmējs, rīks, mērķis, normalizētie parametri, derīguma termiņš un tas, vai apstiprinājums jau izmantots. Pārbaude un apstiprinājuma patērēšana jāveic vienā atomārā solī tieši pirms izpildes.
Atsākšanas pieprasījumā serveris ielādē saglabāto kontrolpunktu un priekšlikumu, autentificē lēmuma pieņēmēju, pārbauda viņa tiesības attiecīgajai darbībai un salīdzina versiju ar apstiprināto argumentu kopu. Rīka izpildītājs argumentus ņem no šīs saglabātās versijas, nevis no atsākšanas pieprasījuma brīvā teksta vai aģenta jaunākās atbildes. Ja mērķis vai argumenti ir mainījušies, vajadzīgs jauns priekšlikums un lēmums.
Vienlaicīgus apstiprināšanas pieprasījumus apstrādājiet ar atomāru stāvokļa maiņu: tikai viens drīkst pārvērst gaidošu priekšlikumu izpildāmā darbībā. Atkārtots pieprasījums saņem jau pieņemtā lēmuma statusu. Ja gaidīšanas laikā mainījusies pieprasītāja piekļuve vai piemērojamā politika, pilnvaras izvērtējiet pēc izpildes brīdī spēkā esošajiem noteikumiem.
Saglabājiet audita saiti līdz rīka rezultātam
Audita ierakstā sasaistiet darbplūsmas ID, priekšlikuma versiju, rīku, mērķi, argumentu jaucējvērtību, pieprasītāju, pārbaudītāju, lēmumu, laiku, politikas versiju un izpildes rezultātu. Parakstot ierakstus vai izmantojot HMAC, ietveriet arī saiti ar iepriekšējo notikumu, lai izmaiņas secībā būtu pamanāmas. Žurnālā nekopējiet pilnus noslēpumus vai personas datus, kas audita mērķim nav vajadzīgi.
Atsevišķi reģistrējiet apstiprinājuma patērēšanu un ārējā rīka atbildi. Ja savienojums pārtrūkst pēc izsaukuma, atjaunota darbplūsma nedrīkst automātiski pieņemt, ka darbība nav notikusi. Vispirms noskaidrojiet tās statusu; kur rīks to atbalsta, izmantojiet konkrētajam priekšlikumam piesaistītu idempotences atslēgu.
Pirms palaišanas pārbaudiet četrus gadījumus: noraidīts priekšlikums neizsauc rīku; laboti argumenti gaida jaunu apstiprinājumu; novecojis vai jau izmantots lēmums neizraisa izpildi; servera restartēšana saglabā gaidošo priekšlikumu un tā audita saiti. Katru gadījumu vērtējiet pēc faktiskā rīka izsaukuma un saglabātajiem ierakstiem, nevis tikai pēc saskarnē parādītā paziņojuma.
Lasiet arī:
Saistītie raksti


Pydantic AI vai LangGraph: tipi uzvar vienkāršībā, grafi — ilgā darbplūsmā

LangGraph vai CrewAI: vienkāršāka komanda maksā ar mazāku kontroli

MI aģenta testi: viens veiksmīgs mēģinājums vēl nepierāda uzticamību

MI lietošana aug, bet spriestspēja atpaliek: IBM atklāj bīstamu plaisu

PayPal vai Mollie: PayPal pogai nav vajadzīgs PayPal kā galvenais procesors
Abonējiet mūsu jaunumu vēstuli
Saņemiet jaunākās Web3, MI un kriptovalūtu ziņas tieši savā e-pastā.