AWS ha aggiunto il controllo capillare degli accessi alla memoria Amazon Bedrock AgentCore, offrendo agli sviluppatori un modo gestito per isolare la memoria dell'agente per utente o tenant tramite AgentCore Gateway. La versione del 28 agosto sposta una parte sensibile della progettazione dell'agente nella policy dell'infrastruttura: chi può leggere, scrivere, recuperare o modificare la memoria utilizzata da un agente AI tra le sessioni.

La funzionalità utilizza l'autenticazione OAuth JWT e le policy Cedar, secondo AWS. Un connettore di memoria gestito espone 12 operazioni di memoria come azioni Cedar, in modo che i team possano esprimere regole di accesso relative alle operazioni di memoria invece di fare affidamento solo sul codice dell'applicazione per filtrare i record prima o dopo ogni chiamata.

Potrebbe sembrare un piccolo aggiornamento di autorizzazione. Non lo è. La memoria persistente è una delle principali differenze tra una semplice interfaccia di chat e un prodotto agente di lunga durata. Una volta che gli agenti ricordano le preferenze dell'utente, il contesto dell'account, la cronologia del progetto, le decisioni precedenti, i casi di supporto o lo stato dei processi aziendali, la memoria diventa un limite di sicurezza. AWS ora lo tratta in questo modo.

Cosa è cambiato

Amazon Bedrock AgentCore Memory fa parte dello stack dell'infrastruttura degli agenti di AWS. È progettato per aiutare gli agenti a archiviare e recuperare il contesto attraverso le interazioni, anziché costringere ogni team applicativo a creare da zero il proprio livello di memoria.

La nuova funzionalità di controllo degli accessi consente agli sviluppatori di applicare l'isolamento per utente e per tenant tramite AgentCore Gateway. AWS afferma che la funzionalità funziona con l'autenticazione OAuth JWT e Cedar, il linguaggio delle policy utilizzato anche in altri sistemi di autorizzazione AWS. La documentazione di AgentCore descrive la Policy in AgentCore come un meccanismo basato su Cedar per il controllo dell'accesso agli strumenti del gateway.

Il cambiamento pratico è che l'autorizzazione della memoria può ora essere più vicina al livello del gateway e dello strumento. Invece di scrivere controlli personalizzati su ogni chiamata di memoria all'interno dell'applicazione, i team possono definire policy che regolano quale chiamante può eseguire quale azione di memoria in quale spazio dei nomi o contesto tenant.

Per il software multi-tenant, si tratta di un cambiamento architetturale significativo. Un assistente AI per uno studio legale, un'agenzia, un team di supporto o un dipartimento aziendale può servire molti utenti tramite lo stesso codice agente. La pericolosa modalità di fallimento non risiede solo nel fatto che il modello fornisce una risposta errata. Il problema è che la memoria di un tenant viene recuperata nella sessione di un altro tenant o che un agente scrive lo stato sensibile nell'ambito sbagliato. L'applicazione dettagliata delle policy ha lo scopo di ridurre questa classe di errori.

Perché l'isolamento della memoria ora è importante

La memoria dell'agente crea un nuovo problema di persistenza per le piattaforme AI. I registri dei prompt, i documenti recuperati, gli output degli strumenti, le preferenze dell'utente e lo stato del flusso di lavoro possono diventare tutti parte del ragionamento futuro. Ciò rende la memoria utile, ma rende anche più difficile ragionare sui limiti dei dati.

L'autorizzazione API tradizionale di solito si concentra su una richiesta: questo chiamante può accedere a questa risorsa in questo momento? La memoria dell'agente estende la domanda nel tempo. Un record archiviato durante una sessione può essere recuperato settimane dopo mediante l'invocazione di uno strumento diverso, un modello diverso o una versione diversa dell'agente. Se la piattaforma non trasporta identità e contesto di autorizzazione in tali operazioni di memoria, il livello di memoria può diventare una fonte silenziosa di perdite tra utenti.

L'uso di Cedar da parte di AWS è significativo anche perché punta verso la policy come infrastruttura per i sistemi di agenti. Gli sviluppatori di agenti necessitano sempre più di controlli che coprano strumenti, memoria, ambienti di esecuzione, chiavi API e registri di controllo. Posizionare questi controlli a livello gateway offre ai team della piattaforma un luogo in cui applicare le policy in modo coerente, anche quando i team delle applicazioni sperimentano modelli o framework di agenti diversi.

Ciò è direttamente rilevante per la progettazione del gateway API AI. Un gateway che instrada solo le richieste ai modelli non è più sufficiente per distribuzioni serie di agenti. Il piano di controllo deve comprendere identità, tenant, strumenti, ambiti di memoria, limiti di velocità e audit trail. Model Gate e piattaforme simili affrontano la stessa direzione di viaggio: l'accesso unificato è utile solo se presenta limiti applicabili.

Chi è interessato

Il pubblico più immediato sono i clienti AWS che creano agenti su Bedrock AgentCore, in particolare i team che lavorano su prodotti SaaS, assistenti aziendali interni, automazione dell'assistenza clienti, agenti di ricerca e flussi di lavoro a contatto con i partner. Qualsiasi prodotto che serve più organizzazioni o team da un'infrastruttura condivisa deve rispondere alla stessa domanda: come fa l'agente a sapere quale memoria può utilizzare?

Gli sviluppatori possono trarne vantaggio perché possono fare affidamento su controlli di policy gestiti invece di diffondere la logica di autorizzazione attraverso il codice dell'applicazione. Ciò non elimina la necessità di un'attenta progettazione, ma può ridurre il numero di luoghi in cui un errore può esporre dati errati.

Anche i team di sicurezza e piattaforma sono interessati.La memoria dell'agente ora deve essere rivista come un database, un indice di documenti o un archivio di segreti. Il modello di accesso dovrebbe essere esplicito. La traccia di controllo dovrebbe mostrare quale identità ha avuto accesso a quale operazione di memoria. L'isolamento del tenant deve essere testato direttamente, non dedotto dal routing delle applicazioni.

Per le aziende che acquistano o creano sistemi di agenti, la versione aumenta la base per le domande dei fornitori. Non basta più chiedersi se un assistente abbia memoria. Gli acquirenti dovrebbero chiedersi come viene partizionata la memoria, se l'autorizzazione viene applicata all'esterno del modello, come vengono aggiornate le policy e come viene visualizzato l'accesso alla memoria nei log.

Conseguenze pratiche per i costruttori

La conseguenza più ovvia è l'architettura. I team che creano agenti di lunga durata dovrebbero separare il routing delle funzionalità del modello dalle autorizzazioni di esecuzione e di memoria. A un modello potente può essere consentito di ragionare su un'attività, ma ciò non significa che ogni chiamata di strumento o ricerca di memoria dovrebbe ereditare un ampio accesso.

In secondo luogo, i gateway e le piattaforme di agenti dovrebbero trattare le operazioni di memoria come eventi di prima classe. Le letture, le scritture, le ricerche, le eliminazioni e gli aggiornamenti presentano tutti profili di rischio diversi. L'analisi dell'utilizzo non dovrebbe fermarsi al conteggio dei token. Per i carichi di lavoro degli agenti, l'analisi deve sempre più mostrare l'utilizzo degli strumenti, l'accesso alla memoria, l'ambito del tenant, l'identità dell'utente e i risultati delle policy.

In terzo luogo, i prodotti multi-tenant dovrebbero evitare di fare affidamento su istruzioni tempestive per imporre la separazione dei dati. Si può dire a un modello di non recuperare il contesto di un altro cliente, ma è necessario imporre un isolamento duraturo al di sotto del modello. Ciò significa credenziali con ambito, policy del gateway, progettazione dello spazio dei nomi e test che dimostrano il fallimento dell'accesso tra tenant.

Infine, le piattaforme di partner e rivenditori dovrebbero prestare attenzione. Se un'API AI per agenzie o un livello di automazione dell'API partner consente ai clienti a valle di creare agenti, la governance della memoria diventa parte del contratto del prodotto. La piattaforma deve offrire ai partner la flessibilità sufficiente per creare automazioni utili senza lasciare loro la creazione di percorsi invisibili di condivisione dei dati tra i client.

Ciò che rimane incerto

AWS ha descritto il modello di controllo e il suo utilizzo di JWT OAuth, policy Cedar, AgentCore Gateway e operazioni di memoria gestite. Ciò che rimane meno chiaro dall'annuncio pubblico è il modo in cui i team progetteranno queste policy in distribuzioni di produzione complesse, quanto sarà semplice il debug delle policy e quanti dettagli operativi i clienti riceveranno nei log per impostazione predefinita.

La direzione più ampia, tuttavia, è chiara. La memoria degli agenti sta diventando un'infrastruttura. Quando ciò accade, l’autorizzazione, l’osservabilità e la fatturazione devono seguirlo nel livello gateway. Le aziende che costruiscono piattaforme di agenti affidabili saranno quelle che potranno rendere visibili e governabili l'accesso ai modelli, le autorizzazioni degli strumenti e lo stato della memoria in un unico posto.