AWS on lisanud Amazon Bedrock AgentCore Memory'ile täpse juurdepääsukontrolli, andes arendajatele hallatava võimaluse isoleerida agendimälu kasutaja või rentniku poolt AgentCore Gateway kaudu. 28. augusti väljalase teisaldab tundliku osa agendi kujundamisest infrastruktuuripoliitikasse: kes saab lugeda, kirjutada, tuua või muuta mälu, mida AI agent seansside jooksul kasutab.
See funktsioon kasutab AWS-i kohaselt OAuthi JWT autentimist ja Cedari eeskirju. Hallatud mäluliides paljastab 12 mälutoimingut Cedari toimingutena, nii et meeskonnad saavad väljendada mälutoimingute kohta juurdepääsureegleid, selle asemel et tugineda ainult rakenduse koodile, et filtreerida kirjeid enne või pärast iga kõnet.
See võib tunduda väikese volituse värskendusena. Ei ole. Püsmälu on üks peamisi erinevusi lihtsa vestlusliidese ja kaua töötava agenditoote vahel. Kui agendid mäletavad kasutaja eelistusi, konto konteksti, projekti ajalugu, eelnevaid otsuseid, tugijuhtumeid või äriprotsessi olekut, muutub mälu turvapiiriks. AWS kohtleb seda nüüd nii.
Mis muutus
Amazon Bedrock AgentCore Memory on osa AWS-i agenditaristu virust. See on loodud selleks, et aidata agentidel interaktsioonide vahel konteksti salvestada ja hankida, selle asemel, et sundida iga rakendusmeeskonda nullist üles ehitama oma mälukihti.
Uus juurdepääsukontrolli võimalus võimaldab ehitajatel AgentCore Gateway kaudu rakendada kasutaja- ja rentnikupõhist isolatsiooni. AWS ütleb, et funktsioon töötab koos OAuthi JWT autentimise ja Cedariga, poliitikakeelega, mida kasutatakse ka teistes AWS-i autoriseerimissüsteemides. AgentCore'i dokumentatsioon kirjeldab AgentCore'i poliitikat kui Cedari-põhist mehhanismi juurdepääsu kontrollimiseks lüüsi tööriistadele.
Praktiline nihe seisneb selles, et mälu autoriseerimine võib nüüd asuda lüüsi ja tööriistakihile lähemal. Selle asemel, et kirjutada rakenduses igale mälukõnele kohandatud kontrolle, saavad meeskonnad määratleda eeskirjad, mis määravad, milline helistaja saab millise mälutoimingu millises nimeruumis või rentniku kontekstis sooritada.
Mitme rentniku tarkvara puhul on see oluline arhitektuuriline muudatus. Advokaadibüroo, agentuuri, tugimeeskonna või ettevõtte osakonna tehisintellekti assistent võib teenindada paljusid kasutajaid sama agendikoodi kaudu. Ohtlik rikkerežiim ei seisne ainult selles, et mudel annab halva vastuse. See seisneb selles, et ühe üürniku mälu hangitakse teise üürniku seansse või agent kirjutab tundliku oleku valesse ulatusse. Täpse poliitika jõustamise eesmärk on seda veaklassi vähendada.
Miks on mälu isoleerimine praegu oluline?
Agendi mälu tekitab tehisintellekti platvormidele uue püsivusprobleemi. Viipade logid, allalaaditud dokumendid, tööriista väljundid, kasutaja eelistused ja töövoo olek võivad kõik saada osaks tulevasest arutluskäigust. See muudab mälu kasulikuks, kuid raskendab ka andmepiiride mõtlemist.
Traditsiooniline API autoriseerimine keskendub tavaliselt päringule: kas see helistaja pääseb praegu sellele ressursile juurde? Agendimälu venitab küsimuse üle aja. Ühe seansi jooksul salvestatud kirje võib nädalaid hiljem kätte saada mõne teise tööriista kutse, erineva mudeli või agendi erineva versiooni abil. Kui platvorm ei kanna nendesse mälutoimingutesse identiteedi ja autoriseerimise konteksti, võib mälukiht muutuda vaikseks kasutajatevahelise lekke allikaks.
AWS-i Cedari kasutamine on samuti oluline, kuna see viitab agendisüsteemide poliitikale kui infrastruktuurile. Agentide koostajad vajavad üha enam juhtelemente, mis hõlmavad tööriistu, mälu, täitmiskeskkondi, API võtmeid ja auditiloge. Nende juhtelementide paigutamine lüüsikihti annab platvormimeeskondadele võimaluse poliitikat järjekindlalt jõustada, isegi kui rakendusmeeskonnad katsetavad erinevaid mudeleid või agentide raamistikke.
See on AI API lüüsi kujundusega otseselt seotud. Lüüsist, mis suunab ainult viipasid mudelitele, ei piisa enam tõsiste agentide juurutamiseks. Juhttasand peab mõistma identiteete, rentnikke, tööriistu, mälu ulatust, kiiruspiiranguid ja kontrolljälgi. Model Gate'i ja sarnaste platvormide liikumissuund on sama: ühtne juurdepääs on kasulik ainult siis, kui sellega kaasnevad jõustatavad piirid.
Keda see mõjutab
Vaheseks vaatajaskonnaks on AWS-i kliendid, kes loovad agente Bedrock AgentCore'is, eriti meeskonnad, kes töötavad SaaS-i toodetega, ettevõttesisesed assistendid, klienditoe automatiseerimise partnerid, uurimisagendid ja agentuurid. Iga toode, mis teenindab jagatud infrastruktuuri kaudu mitut organisatsiooni või meeskonda, peab vastama samale küsimusele: kuidas agent teab, millist mälu tal on lubatud kasutada?
Arendajad võivad sellest kasu saada, kuna nad saavad tugineda hallatud poliitikakontrollidele, selle asemel et hajutada autoriseerimisloogikat rakenduse koodi kaudu. See ei eemalda vajadust hoolika kavandamise järele, kuid võib vähendada kohtade arvu, kus viga võib paljastada valed andmed.
Mõjutatud on ka turvalisuse ja platvormide meeskonnad.Agendi mälu tuleb nüüd üle vaadata nagu andmebaas, dokumendiregister või saladuste pood. Juurdepääsumudel peaks olema selgesõnaline. Kontrolljälg peaks näitama, milline identiteet millisele mälutoimingule juurde pääses. Üürnike isolatsiooni tuleks testida otse, mitte rakenduste marsruutimisest järeldada.
Ettevõtete jaoks, kes ostavad või ehitavad agentsüsteeme, tõstatab väljalase tarnijaga seotud küsimusi. Enam ei piisa küsimisest, kas assistendil on mälu. Ostjad peaksid küsima, kuidas mälu jaotatakse, kas autoriseerimist jõustatakse väljaspool mudelit, kuidas poliitikaid värskendatakse ja kuidas logides kuvatakse juurdepääs mälule.
Praktilised tagajärjed ehitajatele
Kõige ilmsem tagajärg on arhitektuur. Pikaealisi agente loovad meeskonnad peaksid eraldama mudeli võime marsruutimise täitmis- ja mäluõigustest. Võimas mudelil võidakse lubada ülesande üle arutleda, kuid see ei tähenda, et iga tööriistakutse või mäluotsing peaks pärima laia juurdepääsu.
Teiseks peaksid lüüsid ja agendiplatvormid käsitlema mälutoiminguid esmaklassiliste sündmustena. Lugemisel, kirjutamisel, otsimisel, kustutamisel ja värskendamisel on erinevad riskiprofiilid. Kasutusanalüütika ei tohiks piirduda lubade arvuga. Agendi töökoormuse puhul peavad analüüsid näitama üha enam tööriista kasutamist, juurdepääsu mälule, rentniku ulatust, kasutaja identiteeti ja poliitikatulemusi.
Kolmandaks peaksid mitme rentnikuga tooted vältima andmete eraldamise jõustamiseks viivitamatute juhiste lootmist. Mudelile võib öelda, et ta ei too teise kliendi konteksti, kuid mudeli all tuleb jõustada vastupidav isolatsioon. See tähendab ulatusega mandaate, lüüsipoliitikat, nimeruumi kujundust ja teste, mis tõestavad rentnikeülese juurdepääsu ebaõnnestumist.
Lõpuks peaksid partnerite ja edasimüüjate platvormid tähelepanu pöörama. Kui agentuuride AI API või Partner API automatiseerimiskiht võimaldab alluvatel klientidel agente luua, muutub mälu haldamine tootelepingu osaks. Platvorm peab andma partneritele piisavalt paindlikkust, et luua kasulikke automatiseerimisi, laskmata neil luua klientide vahel nähtamatuid andmete jagamise teid.
Mis jääb ebaselgeks
AWS on kirjeldanud juhtimismudelit ja OAuthi JWT-de, Cedari poliitikate, AgentCore Gateway ja hallatud mäluoperatsioonide kasutamist. Avalikust teadaandest jääb vähem selgeks see, kuidas meeskonnad neid poliitikaid keerukates tootmisjuurutustes kujundavad, kui lihtne on eeskirjade silumine ja kui palju operatiivseid üksikasju saavad kliendid logidesse vaikimisi.
Laim suund on siiski selge. Agendimälust on saamas infrastruktuur. Sel juhul peavad autoriseerimine, jälgitavus ja arveldamine sellele lüüsikihti järgima. Usaldusväärseid agentide platvorme loovad ettevõtted saavad muuta mudelile juurdepääsu, tööriista load ja mälu oleku ühes kohas nähtavaks ja juhitavaks.