AWS ir pievienojusi detalizētu piekļuves kontroli Amazon Bedrock AgentCore Memory, sniedzot izstrādātājiem pārvaldītu veidu, kā izolēt aģenta atmiņu no lietotāja vai nomnieka, izmantojot AgentCore Gateway. 28. augusta laidienā jutīga aģenta izstrādes daļa tiek pārvietota uz infrastruktūras politiku: kurš var lasīt, rakstīt, izgūt vai modificēt atmiņu, ko AI aģents izmanto sesijās.

Funkcija izmanto OAuth JWT autentifikāciju un Cedar politikas saskaņā ar AWS. Pārvaldītais atmiņas savienotājs atklāj 12 atmiņas darbības kā Cedar darbības, tāpēc komandas var izteikt piekļuves noteikumus saistībā ar atmiņas darbībām, nevis paļauties tikai uz lietojumprogrammas kodu, lai filtrētu ierakstus pirms vai pēc katra zvana.

Tas var izklausīties kā neliels autorizācijas atjauninājums. Tā nav. Pastāvīgā atmiņa ir viena no galvenajām atšķirībām starp vienkāršu tērzēšanas interfeisu un ilgstoši darbojošos aģenta produktu. Kad aģenti atceras lietotāja preferences, konta kontekstu, projekta vēsturi, iepriekšējos lēmumus, atbalsta gadījumus vai biznesa procesa stāvokli, atmiņa kļūst par drošības robežu. AWS tagad pret to attiecas šādi.

Kas mainījās

Amazon Bedrock AgentCore Memory ir daļa no AWS aģentu infrastruktūras kopas. Tā ir izstrādāta, lai palīdzētu aģentiem saglabāt un izgūt kontekstu dažādās mijiedarbībās, nevis likt katrai lietojumprogrammu komandai izveidot savu atmiņas slāni no jauna.

Jaunā piekļuves kontroles iespēja ļauj veidotājiem nodrošināt katra lietotāja un nomnieka izolāciju, izmantojot AgentCore Gateway. AWS saka, ka funkcija darbojas ar OAuth JWT autentifikāciju un Cedar, politikas valodu, ko izmanto arī citās AWS autorizācijas sistēmās. AgentCore dokumentācijā AgentCore politika ir aprakstīta kā uz Cedar balstīts mehānisms, lai kontrolētu piekļuvi vārtejas rīkiem.

Praktiskā maiņa ir tāda, ka atmiņas autorizācija tagad var atrasties tuvāk vārtejas un rīku slānim. Tā vietā, lai lietojumprogrammā rakstītu pielāgotas pārbaudes katram atmiņas zvanam, komandas var definēt politikas, kas nosaka, kurš zvanītājs var veikt kādu atmiņas darbību kādā nosaukumvietā vai nomnieka kontekstā.

Vairāku nomnieku programmatūrai tās ir nozīmīgas arhitektūras izmaiņas. Advokātu biroja, aģentūras, atbalsta komandas vai uzņēmuma nodaļas AI palīgs var apkalpot daudzus lietotājus, izmantojot vienu un to pašu aģenta kodu. Bīstamais atteices režīms ir ne tikai tas, ka modelis sniedz sliktu atbildi. Tas ir tāds, ka viena īrnieka atmiņa tiek izgūta cita īrnieka sesijā vai aģents ieraksta sensitīvu stāvokli nepareizā tvērumā. Smalkas politikas ieviešanas mērķis ir samazināt šo kļūdu klasi.

Kāpēc atmiņas izolācijai tagad ir nozīme

Aģenta atmiņa rada jaunu noturības problēmu AI platformām. Uzvednes žurnāli, izgūtie dokumenti, rīku izvades, lietotāja preferences un darbplūsmas stāvoklis var kļūt par daļu no turpmākās argumentācijas. Tas padara atmiņu noderīgu, taču apgrūtina arī datu robežu pārdomāšanu.

Tradicionālā API autorizācija parasti koncentrējas uz pieprasījumu: vai šis zvanītājs var piekļūt šim resursam šobrīd? Aģenta atmiņa izstiepj jautājumu laika gaitā. Vienas sesijas laikā saglabāto ierakstu var izgūt nedēļas vēlāk, izmantojot citu rīka izsaukumu, citu modeli vai citu aģenta versiju. Ja platforma šajās atmiņas operācijās neietver identitātes un autorizācijas kontekstu, atmiņas slānis var kļūt par klusu starplietotāju noplūdes avotu.

AWS Cedar izmantošana ir arī nozīmīga, jo tā norāda uz politiku kā aģentu sistēmu infrastruktūru. Aģentu veidotājiem arvien vairāk ir vajadzīgas vadīklas, kas aptver rīkus, atmiņu, izpildes vides, API atslēgas un audita žurnālus. Ievietojot šīs vadīklas vārtejas slānī, platformu komandas var konsekventi īstenot politiku, pat ja lietojumprogrammu komandas eksperimentē ar dažādiem modeļiem vai aģentu ietvariem.

Tas ir tieši saistīts ar AI API vārtejas dizainu. Nopietnai aģentu izvietošanai vairs nepietiek ar vārteju, kas tikai novirza uzvednes uz modeļiem. Vadības plaknei ir jāsaprot identitātes, nomnieki, rīki, atmiņas apjoms, ātruma ierobežojumi un audita pēdas. Model Gate un līdzīgas platformas ir vērstas vienā virzienā: vienota piekļuve ir noderīga tikai tad, ja tai ir piemērojamas robežas.

Kas tiek ietekmēts

Tiešā mērķauditorija ir AWS klienti, kuri veido aģentus Bedrock AgentCore, jo īpaši komandas, kas strādā ar SaaS produktiem, uzņēmuma iekšējie asistenti, klientu atbalsta partneri, darba plūsmas aģenti un pētniecības aģenti. Jebkuram produktam, kas apkalpo vairākas organizācijas vai komandas no koplietotās infrastruktūras, ir jāatbild uz vienu un to pašu jautājumu: kā aģents zina, kuru atmiņu tam ir atļauts izmantot?

Izstrādātāji var gūt labumu, jo viņi var paļauties uz pārvaldītām politikas pārbaudēm, nevis izkliedēt autorizācijas loģiku, izmantojot lietojumprogrammas kodu. Tas nenovērš nepieciešamību pēc rūpīga dizaina, taču var samazināt to vietu skaitu, kur kļūda var atklāt nepareizus datus.

Tiek ietekmētas arī drošības un platformas komandas.Aģenta atmiņa tagad ir jāpārskata, piemēram, datu bāze, dokumentu indekss vai noslēpumu krātuve. Piekļuves modelim jābūt precīzam. Audita izsekojamībai ir jāparāda, kura identitāte piekļuva kādai atmiņas darbībai. Īrnieku izolācija ir jāpārbauda tieši, nevis jāizsecina no lietojumprogrammu maršrutēšanas.

Uzņēmumiem, kas pērk vai veido aģentu sistēmas, laidiens rada pārdevēju jautājumu bāzes līniju. Vairs nepietiek ar jautājumu, vai palīgam ir atmiņa. Pircējiem jājautā, kā tiek sadalīta atmiņa, vai autorizācija tiek īstenota ārpus modeļa, kā tiek atjauninātas politikas un kā piekļuve atmiņai tiek parādīta žurnālos.

Praktiskas sekas būvniekiem

Visredzamākās sekas ir arhitektoniskas. Grupām, kas veido ilgstošus aģentus, ir jānodala modeļa spēju maršrutēšana no izpildes un atmiņas atļaujām. Jaudīgam modelim var ļaut apsvērt uzdevumu, taču tas nenozīmē, ka katram rīka izsaukumam vai atmiņas uzmeklēšanai vajadzētu mantot plašu piekļuvi.

Otrkārt, vārtejām un aģentu platformām atmiņas darbības jāuzskata par pirmās klases notikumiem. Lasīšanai, rakstīšanai, meklēšanai, dzēšanai un atjaunināšanai ir dažādi riska profili. Lietojuma analīzei nevajadzētu apstāties pie pilnvaru skaita. Aģentu darba slodzēm analīzē arvien vairāk ir jāparāda rīku lietojums, piekļuve atmiņai, nomnieka darbības joma, lietotāja identitāte un politikas rezultāti.

Treškārt, vairāku nomnieku produktiem nevajadzētu paļauties uz tūlītējiem norādījumiem, lai nodrošinātu datu atdalīšanu. Modelim var norādīt, lai tas neizgūtu cita klienta kontekstu, taču zem modeļa ir jānodrošina ilgstoša izolācija. Tas nozīmē tvēruma akreditācijas datus, vārtejas politiku, nosaukumvietas dizainu un testus, kas pierāda, ka starpnomnieku piekļuve neizdodas.

Visbeidzot, partneru un tālākpārdevēju platformām ir jāpievērš uzmanība. Ja AI API aģentūrām vai partneru API automatizācijas slānis ļauj pakārtotajiem klientiem izveidot aģentus, atmiņas pārvaldība kļūst par produkta līguma sastāvdaļu. Platformai ir jānodrošina partneriem pietiekama elastība, lai viņi varētu izveidot noderīgu automatizāciju, neļaujot tiem izveidot neredzamus datu koplietošanas ceļus starp klientiem.

Kas paliek neskaidrs

AWS ir aprakstījis vadības modeli un OAuth JWT, Cedar politiku, AgentCore Gateway un pārvaldītās atmiņas operāciju izmantošanu. Publiskajā paziņojumā nav tik skaidrs, kā komandas izstrādās šīs politikas sarežģītās ražošanas izvietošanas gadījumos, cik vienkārša būs politikas atkļūdošana un cik daudz operatīvās informācijas klienti pēc noklusējuma iegūs žurnālos.

Tomēr plašāks virziens ir skaidrs. Aģentu atmiņa kļūst par infrastruktūru. Šajā gadījumā vārtejas slānī ir jāseko autorizācijai, novērojamībai un norēķiniem. Uzņēmumi, kas veido uzticamas aģentu platformas, varēs vienuviet padarīt redzamu un pārvaldāmu piekļuvi modeļiem, rīku atļaujas un atmiņas stāvokli.