AWS je dodao preciznu kontrolu pristupa u Amazon Bedrock AgentCore Memory, dajući programerima upravljani način izolacije agentske memorije od strane korisnika ili stanara putem AgentCore Gatewaya. Izdanje od 28. kolovoza premješta osjetljivi dio dizajna agenta u politiku infrastrukture: tko može čitati, pisati, dohvaćati ili modificirati memoriju koju AI agent koristi kroz sesije.

Značajka koristi OAuth JWT autentifikaciju i Cedar pravila, prema AWS-u. Upravljani memorijski konektor izlaže 12 memorijskih operacija kao Cedar akcije, tako da timovi mogu izraziti pravila pristupa oko memorijskih operacija umjesto da se oslanjaju samo na kod aplikacije za filtriranje zapisa prije ili nakon svakog poziva.

To može zvučati kao malo ažuriranje autorizacije. Nije. Trajna memorija jedna je od glavnih razlika između jednostavnog sučelja za chat i dugotrajnog agentskog proizvoda. Nakon što agenti zapamte korisničke postavke, kontekst računa, povijest projekta, prethodne odluke, slučajeve podrške ili stanje poslovnog procesa, memorija postaje sigurnosna granica. AWS to sada tako tretira.

Što se promijenilo

Amazon Bedrock AgentCore Memory dio je AWS-ovog skupa agentske infrastrukture. Osmišljen je kako bi pomogao agentima da pohrane i dohvate kontekst kroz interakcije, umjesto da tjera svaki aplikacijski tim da izgradi vlastiti memorijski sloj od nule.

Nova mogućnost kontrole pristupa omogućuje graditeljima da provedu izolaciju po korisniku i po stanarima putem AgentCore Gatewaya. AWS kaže da značajka radi s OAuth JWT autentifikacijom i Cedarom, jezikom pravila koji se također koristi u drugim sustavima za autorizaciju AWS. Dokumentacija AgentCore opisuje Pravila u AgentCoreu kao Cedar-based mehanizam za kontrolu pristupa pristupnim alatima.

Praktični pomak je da autorizacija memorije sada može sjediti bliže pristupniku i sloju alata. Umjesto pisanja prilagođenih provjera oko svakog memorijskog poziva unutar aplikacije, timovi mogu definirati pravila koja određuju koji pozivatelj može izvršiti koju memorijsku radnju u kojem prostoru imena ili kontekstu zakupca.

Za softver s više zakupaca, to je značajna arhitektonska promjena. AI asistent za odvjetničku tvrtku, agenciju, tim za podršku ili poslovni odjel može služiti mnogim korisnicima putem istog koda agenta. Opasan način kvara nije samo to što model daje loš odgovor. To je da je memorija jednog stanara dohvaćena u sesiju drugog stanara ili da agent zapisuje osjetljivo stanje u pogrešan opseg. Fina provedba pravila usmjerena je na smanjenje te klase pogreške.

Zašto je izolacija memorije sada važna

Memorija agenta stvara novi problem postojanosti za AI platforme. Brzni zapisnici, dohvaćeni dokumenti, rezultati alata, korisničke postavke i stanje tijeka rada mogu postati dio budućih razmišljanja. To memoriju čini korisnom, ali također otežava razmišljanje o granicama podataka.

Tradicionalna autorizacija API-ja obično se fokusira na zahtjev: može li pozivatelj pristupiti ovom resursu upravo sada? Memorija agenta proteže pitanje kroz vrijeme. Zapis pohranjen tijekom jedne sesije može se dohvatiti tjednima kasnije drugim pozivanjem alata, drugim modelom ili drugom verzijom agenta. Ako platforma ne prenosi kontekst identiteta i autorizacije u te memorijske operacije, memorijski sloj može postati tihi izvor curenja među korisnicima.

AWS-ova upotreba Cedra također je značajna jer upućuje na politiku kao infrastrukturu za agentske sustave. Sastavljači agenata sve više trebaju kontrole koje pokrivaju alate, memoriju, izvršna okruženja, API ključeve i revizijske zapisnike. Postavljanje tih kontrola u sloj pristupnika daje platformskim timovima mjesto za dosljednu provedbu pravila, čak i dok aplikacijski timovi eksperimentiraju s različitim modelima ili agentskim okvirima.

Ovo je izravno relevantno za dizajn pristupnika AI API-ja. Gateway koji samo usmjerava upite modelima više nije dovoljan za ozbiljne implementacije agenata. Kontrolna razina mora razumjeti identitete, stanare, alate, opsege memorije, ograničenja stope i revizijske tragove. Model Gate i slične platforme suočavaju se s istim smjerom kretanja: objedinjeni pristup koristan je samo ako dolazi s provedivim granicama.

Tko je pogođen

Neposredna publika su klijenti AWS-a koji grade agente na Bedrock AgentCoreu, posebno timovi koji rade na SaaS proizvodima, internim pomoćnicima poduzeća, automatizaciji korisničke podrške, istraživačkim agentima i radnim procesima okrenutim partnerima. Bilo koji proizvod koji služi više organizacija ili timova iz zajedničke infrastrukture mora odgovoriti na isto pitanje: kako agent zna koju memoriju smije koristiti?

Razvojni programeri mogu imati koristi jer se mogu osloniti na provjere upravljanih pravila umjesto raspršivanja autorizacijske logike kroz aplikacijski kod. To ne uklanja potrebu za pažljivim dizajnom, ali može smanjiti broj mjesta na kojima pogreška može otkriti pogrešne podatke.

Timovi za sigurnost i platformu također su pogođeni.Memoriju agenta sada je potrebno pregledati poput baze podataka, indeksa dokumenata ili pohrane tajni. Model pristupa treba biti eksplicitan. Revizijski trag trebao bi pokazati koji je identitet pristupio kojoj memorijskoj operaciji. Izolacija stanara trebala bi se testirati izravno, a ne izvesti iz usmjeravanja aplikacije.

Za tvrtke koje kupuju ili grade agentske sustave, izdanje podiže temelj za pitanja dobavljača. Više nije dovoljno pitati ima li asistent memoriju. Kupci bi trebali pitati kako je memorija podijeljena, provodi li se autorizacija izvan modela, kako se pravila ažuriraju i kako se pristup memoriji pojavljuje u zapisnicima.

Praktične posljedice za graditelje

Najočitija posljedica je arhitektonska. Timovi koji grade dugotrajne agente trebali bi odvojiti usmjeravanje sposobnosti modela od izvođenja i dopuštenja za memoriju. Moćnom modelu može se dopustiti da razmišlja o zadatku, ali to ne znači da bi svaki poziv alata ili pretraživanje memorije trebali naslijediti široki pristup.

Drugo, pristupnici i agentske platforme trebali bi tretirati memorijske operacije kao prvorazredne događaje. Čitanje, pisanje, pretraživanje, brisanje i ažuriranje imaju različite profile rizika. Analitika upotrebe ne bi se trebala zaustaviti na broju tokena. Za radna opterećenja agenata, analitika sve više mora prikazivati ​​upotrebu alata, pristup memoriji, opseg zakupca, identitet korisnika i ishode pravila.

Treće, proizvodi za više zakupaca trebali bi izbjegavati oslanjanje na brze upute za provedbu odvajanja podataka. Modelu se može reći da ne dohvaća kontekst drugog kupca, ali ispod modela mora se provesti trajna izolacija. To znači vjerodajnice s opsegom, politiku pristupnika, dizajn prostora imena i testove koji dokazuju da pristup među zakupcima ne uspijeva.

Konačno, platforme partnera i preprodavača trebale bi obratiti pozornost. Ako AI API za agencije ili sloj automatizacije Partner API-ja dopušta daljnjim korisnicima izgradnju agenata, upravljanje memorijom postaje dio ugovora o proizvodu. Platforma treba dati partnerima dovoljno fleksibilnosti za stvaranje korisnih automatizacija bez dopuštanja stvaranja nevidljivih puteva za dijeljenje podataka između klijenata.

Ono što ostaje neizvjesno

AWS je opisao kontrolni model i njegovu upotrebu OAuth JWT-ova, Cedar pravila, AgentCore Gatewaya i operacija upravljane memorije. Ono što ostaje manje jasno iz javne objave jest kako će timovi dizajnirati ova pravila u složenim proizvodnim implementacijama, koliko će jednostavno biti otklanjanje pogrešaka u politici i koliko operativnih detalja će korisnici dobiti u zapisnicima prema zadanim postavkama.

Širi smjer je, međutim, jasan. Memorija agenta postaje infrastruktura. Kad se to dogodi, autorizacija, vidljivost i naplata moraju ga pratiti u sloj pristupnika. Tvrtke koje grade pouzdane agentske platforme bit će one koje mogu pristup modelu, dopuštenja alata i stanje memorije učiniti vidljivima i njima se može upravljati na jednom mjestu.