AWS a adăugat un control de acces precis la Amazon Bedrock AgentCore Memory, oferind dezvoltatorilor o modalitate gestionată de a izola memoria agentului de către utilizator sau chiriaș prin AgentCore Gateway. Versiunea din 28 august mută o parte sensibilă a designului agentului în politica de infrastructură: cine poate citi, scrie, prelua sau modifica memoria pe care un agent AI o folosește în sesiuni.

Funcția folosește autentificarea OAuth JWT și politicile Cedar, conform AWS. Un conector de memorie gestionat expune 12 operațiuni de memorie ca acțiuni Cedar, astfel încât echipele să poată exprima regulile de acces în jurul operațiunilor de memorie în loc să se bazeze doar pe codul aplicației pentru a filtra înregistrările înainte sau după fiecare apel.

Aceasta poate suna ca o mică actualizare de autorizare. Nu este. Memoria persistentă este una dintre principalele diferențe dintre o interfață simplă de chat și un produs agent de lungă durată. Odată ce agenții își amintesc preferințele utilizatorului, contextul contului, istoricul proiectului, deciziile anterioare, cazurile de asistență sau starea procesului de afaceri, memoria devine o limită de securitate. AWS tratează acum acest lucru.

Ceea ce sa schimbat

Amazon Bedrock AgentCore Memory face parte din stiva de infrastructură a agenților AWS. Este conceput pentru a ajuta agenții să stocheze și să recupereze contextul în cadrul interacțiunilor, mai degrabă decât să forțeze fiecare echipă de aplicații să-și construiască propriul strat de memorie de la zero.

Noua capacitate de control al accesului le permite constructorilor să impună izolarea per utilizator și per locatar prin AgentCore Gateway. AWS spune că funcția funcționează cu autentificarea OAuth JWT și Cedar, limbajul de politică folosit și în alte sisteme de autorizare AWS. Documentația AgentCore descrie Politica din AgentCore ca un mecanism bazat pe Cedar pentru controlul accesului la instrumentele gateway.

Schimbarea practică este că autorizarea memoriei poate fi acum mai aproape de gateway și de stratul de instrumente. În loc să scrie verificări personalizate în jurul fiecărui apel de memorie din interiorul aplicației, echipele pot defini politici care guvernează care apelant poate efectua ce acțiune de memorie în ce spațiu de nume sau context de chiriaș.

Pentru software-ul cu mai mulți locatari, aceasta este o schimbare arhitecturală semnificativă. Un asistent AI pentru o firmă de avocatură, o agenție, o echipă de asistență sau un departament de întreprindere poate deservi mulți utilizatori prin același cod de agent. Modul de eșec periculos nu este doar că modelul oferă un răspuns prost. Este că memoria unui chiriaș este preluată în sesiunea altui chiriaș sau că un agent scrie starea sensibilă în domeniul greșit. Aplicarea precisă a politicilor are ca scop reducerea acestei clase de erori.

De ce contează acum izolarea memoriei

Memoria agentului creează o nouă problemă de persistență pentru platformele AI. Jurnalele prompte, documentele preluate, rezultatele instrumentelor, preferințele utilizatorului și starea fluxului de lucru pot deveni toate parte din raționamentul viitor. Acest lucru face ca memoria să fie utilă, dar, de asemenea, îngreunează raționarea limitelor datelor.

Autorizarea tradițională API se concentrează de obicei pe o solicitare: poate acest apelant să acceseze această resursă chiar acum? Memoria agentului extinde întrebarea în timp. O înregistrare stocată în timpul unei sesiuni poate fi preluată săptămâni mai târziu printr-o invocare a unui instrument diferit, un model diferit sau o versiune diferită a agentului. Dacă platforma nu transportă identitatea și contextul de autorizare în acele operațiuni de memorie, stratul de memorie poate deveni o sursă liniștită de scurgeri între utilizatori.

Utilizarea Cedar de către AWS este, de asemenea, semnificativă, deoarece indică politica ca infrastructură pentru sistemele de agenți. Creatorii de agenți au nevoie din ce în ce mai mult de controale care să acopere instrumentele, memoria, mediile de execuție, cheile API și jurnalele de audit. Plasarea acestor controale într-un strat de gateway oferă echipelor platformei un loc în care să aplice politica în mod consecvent, chiar dacă echipele de aplicații experimentează cu diferite modele sau cadre de agenți.

Acest lucru este direct relevant pentru proiectarea gateway-ului AI API. Un gateway care direcționează doar solicitările către modele nu mai este suficient pentru implementări serioase de agenți. Planul de control trebuie să înțeleagă identitățile, chiriașii, instrumentele, domeniile de memorie, limitele ratelor și traseele de audit. Model Gate și platformele similare se confruntă cu aceeași direcție de deplasare: accesul unificat este util doar dacă vine cu granițe aplicabile.

Cine este afectat

Publicul imediat este reprezentat de clienții AWS care construiesc agenți pe Bedrock AgentCore, în special echipele care lucrează pe produse SaaS, asistenți interni de întreprindere, automatizarea asistenței clienților, agenții de cercetare și partenerii de flux de lucru. Orice produs care deservește mai multe organizații sau echipe din infrastructura partajată trebuie să răspundă la aceeași întrebare: de unde știe agentul ce memorie are permisiunea de a utiliza?

Dezvoltatorii pot beneficia, deoarece se pot baza pe verificări ale politicilor gestionate în loc să împrăștie logica de autorizare prin codul aplicației. Acest lucru nu înlătură necesitatea unui design atent, dar poate reduce numărul de locuri în care o greșeală poate expune date greșite.

De asemenea, echipele de securitate și platformă sunt afectate.Memoria agentului trebuie acum revizuită ca o bază de date, un index de documente sau un depozit de secrete. Modelul de acces ar trebui să fie explicit. Pista de audit ar trebui să arate ce identitate a accesat ce operație de memorie. Izolarea chiriașilor ar trebui testată direct, nu dedusă din rutarea aplicațiilor.

Pentru companiile care cumpără sau construiesc sisteme de agenți, versiunea ridică punctul de referință pentru întrebările furnizorilor. Nu mai este suficient să întrebi dacă un asistent are memorie. Cumpărătorii ar trebui să întrebe cum este împărțită memoria, dacă autorizarea este aplicată în afara modelului, cum sunt actualizate politicile și cum apare accesul la memorie în jurnale.

Consecințele practice pentru constructori

Cea mai evidentă consecință este arhitecturală. Echipele care construiesc agenți cu viață lungă ar trebui să separe rutarea capabilității modelului de permisiunile de execuție și memorie. Un model puternic poate avea voie să raționeze asupra unei sarcini, dar asta nu înseamnă că fiecare apel de instrument sau căutare de memorie ar trebui să moștenească acces larg.

În al doilea rând, gateway-urile și platformele de agenți ar trebui să trateze operațiunile de memorie ca evenimente de primă clasă. Citirile, scrierile, căutările, ștergerile și actualizările au profiluri de risc diferite. Analiza utilizării nu ar trebui să se oprească la numărul de simboluri. Pentru sarcinile de lucru ale agenților, analizele trebuie să arate din ce în ce mai mult utilizarea instrumentelor, accesul la memorie, domeniul de aplicare a chiriașilor, identitatea utilizatorului și rezultatele politicii.

În al treilea rând, produsele multi-locatari ar trebui să evite să se bazeze pe instrucțiuni prompte pentru a impune separarea datelor. Un model i se poate spune să nu recupereze contextul altui client, dar izolarea durabilă trebuie să fie impusă sub model. Aceasta înseamnă acreditări, politica de gateway, designul spațiului de nume și teste care dovedesc că accesul între chiriași eșuează.

În sfârșit, platformele partenere și reseller ar trebui să acorde atenție. Dacă un API AI pentru agenții sau un strat de automatizare API partener permite clienților din aval să construiască agenți, guvernarea memoriei devine parte a contractului de produs. Platforma trebuie să ofere partenerilor suficientă flexibilitate pentru a crea automatizări utile fără a le permite să creeze căi invizibile de partajare a datelor între clienți.

Ceea ce rămâne incert

AWS a descris modelul de control și utilizarea acestuia a JWT-urilor OAuth, politicilor Cedar, AgentCore Gateway și operațiunilor de memorie gestionată. Ceea ce rămâne mai puțin clar din anunțul public este modul în care echipele vor proiecta aceste politici în implementările complexe de producție, cât de ușoară va fi depanarea politicilor și cât de multe detalii operaționale vor primi clienții în jurnal în mod implicit.

Direcția mai largă, totuși, este clară. Memoria agentului devine infrastructură. Pe măsură ce se întâmplă acest lucru, autorizarea, observabilitatea și facturarea trebuie să le urmeze în stratul gateway. Companiile care construiesc platforme de agenți de încredere vor fi cele care pot face accesul la model, permisiunile pentru instrumente și starea memoriei vizibile și guvernabile într-un singur loc.