AWS ha afegit un control d'accés detallat a la memòria d'Amazon Bedrock AgentCore, que ofereix als desenvolupadors una manera gestionada d'aïllar la memòria de l'agent per usuari o llogater mitjançant AgentCore Gateway. La versió del 28 d'agost trasllada una part sensible del disseny de l'agent a la política d'infraestructura: qui pot llegir, escriure, recuperar o modificar la memòria que fa servir un agent d'IA a les sessions.
La funció utilitza l'autenticació OAuth JWT i les polítiques de Cedar, segons AWS. Un connector de memòria gestionat exposa 12 operacions de memòria com a accions Cedar, de manera que els equips poden expressar regles d'accés sobre les operacions de memòria en lloc de dependre només del codi de l'aplicació per filtrar els registres abans o després de cada trucada.
Això pot semblar una petita actualització d'autorització. No ho és. La memòria persistent és una de les principals diferències entre una interfície de xat simple i un producte d'agent de llarga durada. Una vegada que els agents recorden les preferències de l'usuari, el context del compte, l'historial del projecte, les decisions prèvies, els casos de suport o l'estat del procés empresarial, la memòria es converteix en un límit de seguretat. Ara AWS ho està tractant d'aquesta manera.
El que va canviar
Amazon Bedrock AgentCore Memory forma part de la pila d'infraestructura d'agents d'AWS. Està dissenyat per ajudar els agents a emmagatzemar i recuperar el context a través de les interaccions, en lloc d'obligar cada equip d'aplicacions a crear la seva pròpia capa de memòria des de zero.
La nova capacitat de control d'accés permet als constructors fer complir l'aïllament per usuari i per inquilí mitjançant AgentCore Gateway. AWS diu que la funció funciona amb l'autenticació OAuth JWT i Cedar, el llenguatge de política que també s'utilitza en altres sistemes d'autorització d'AWS. La documentació d'AgentCore descriu la política d'AgentCore com un mecanisme basat en Cedar per controlar l'accés a les eines de passarel·la.
El canvi pràctic és que l'autorització de memòria ara es pot situar més a prop de la passarel·la i de la capa d'eines. En lloc d'escriure comprovacions personalitzades a cada trucada de memòria dins de l'aplicació, els equips poden definir polítiques que governin quin interlocutor pot realitzar quina acció de memòria en quin espai de noms o context d'inquilí.
Per al programari multi-inquilí, aquest és un canvi arquitectònic significatiu. Un assistent d'IA d'un despatx d'advocats, agència, equip de suport o departament empresarial pot servir a molts usuaris mitjançant el mateix codi d'agent. El mode d'error perillós no és només que el model doni una mala resposta. És que la memòria d'un inquilí es recupera a la sessió d'un altre inquilí o que un agent escriu un estat sensible a l'àmbit incorrecte. L'aplicació detallada de les polítiques té com a objectiu reduir aquesta classe d'error.
Per què és important ara l'aïllament de la memòria
La memòria de l'agent crea un nou problema de persistència per a les plataformes d'IA. Els registres ràpids, els documents recuperats, les sortides d'eines, les preferències de l'usuari i l'estat del flux de treball poden formar part del raonament futur. Això fa que la memòria sigui útil, però també dificulta el raonament sobre els límits de les dades.
L'autorització de l'API tradicional se centra normalment en una sol·licitud: aquesta persona que truca pot accedir a aquest recurs ara mateix? La memòria de l'agent allarga la pregunta al llarg del temps. Un registre emmagatzemat durant una sessió es pot recuperar setmanes més tard mitjançant una invocació d'eina diferent, un model diferent o una versió diferent de l'agent. Si la plataforma no inclou el context d'identitat i autorització a aquestes operacions de memòria, la capa de memòria pot convertir-se en una font silenciosa de fuites entre usuaris.
L'ús de Cedar per part d'AWS també és important perquè apunta cap a la política com a infraestructura per als sistemes d'agent. Els creadors d'agents necessiten cada cop més controls que cobreixin eines, memòria, entorns d'execució, claus API i registres d'auditoria. Col·locar aquests controls en una capa de passarel·la ofereix als equips de la plataforma un lloc on aplicar les polítiques de manera coherent, fins i tot quan els equips d'aplicacions experimenten amb diferents models o marcs d'agent.
Això és directament rellevant per al disseny de la passarel·la de l'API d'IA. Una passarel·la que només enviï les sol·licituds als models ja no és suficient per a desplegaments d'agents seriosos. El pla de control ha d'entendre identitats, inquilins, eines, àmbits de memòria, límits de velocitat i pistes d'auditoria. Model Gate i plataformes similars s'enfronten a la mateixa direcció de viatge: l'accés unificat només és útil si inclou límits exigibles.
Qui es veu afectat
El públic immediat són els clients d'AWS que creen agents a Bedrock AgentCore, especialment els equips que treballen en productes SaaS, assistents interns d'empresa, automatització d'assistència al client, agents de recerca i flux de treball de socis. Qualsevol producte que serveixi a diverses organitzacions o equips des d'una infraestructura compartida ha de respondre a la mateixa pregunta: com sap l'agent quina memòria pot utilitzar?
Els desenvolupadors poden beneficiar-se perquè poden confiar en comprovacions de polítiques gestionades en lloc de dispersar la lògica d'autorització a través del codi de l'aplicació. Això no elimina la necessitat d'un disseny acurat, però pot reduir el nombre de llocs on un error pot exposar dades incorrectes.
Els equips de seguretat i de plataforma també es veuen afectats.La memòria de l'agent ara s'ha de revisar com una base de dades, un índex de documents o un magatzem de secrets. El model d'accés ha de ser explícit. La pista d'auditoria hauria de mostrar quina identitat ha accedit a quina operació de memòria. L'aïllament dels inquilins s'ha de provar directament, no deduir-se de l'encaminament de l'aplicació.
Per a les empreses que compren o construeixen sistemes d'agents, la versió planteja la línia de base per a preguntes dels proveïdors. Ja no n'hi ha prou amb preguntar-se si un assistent té memòria. Els compradors haurien de preguntar com es divideix la memòria, si l'autorització s'aplica fora del model, com s'actualitzen les polítiques i com apareix l'accés a la memòria als registres.
Conseqüències pràctiques per als constructors
La conseqüència més òbvia és arquitectònica. Els equips que creen agents de llarga vida haurien de separar l'encaminament de la capacitat del model dels permisos d'execució i memòria. Es pot permetre que un model potent raoni sobre una tasca, però això no vol dir que totes les trucades d'eines o cerques de memòria hagin d'heretar un accés ampli.
En segon lloc, les passarel·les i les plataformes d'agents haurien de tractar les operacions de memòria com a esdeveniments de primera classe. Les lectures, les escriptures, les cerques, les supressions i les actualitzacions tenen diferents perfils de risc. L'anàlisi d'ús no s'ha d'aturar al recompte de testimonis. Per a les càrregues de treball d'agents, les analítiques han de mostrar cada cop més l'ús d'eines, l'accés a la memòria, l'abast de l'inquilí, la identitat de l'usuari i els resultats de les polítiques.
En tercer lloc, els productes multiinquilí haurien d'evitar confiar en instruccions ràpides per aplicar la separació de dades. Es pot dir a un model que no recuperi el context d'un altre client, però s'ha d'aplicar un aïllament durador a sota del model. Això vol dir que les credencials amb abast, la política de passarel·la, el disseny d'espais de noms i les proves que demostren que l'accés entre inquilins falla.
Finalment, les plataformes de socis i distribuïdors haurien de prestar atenció. Si una API d'IA per a agències o una capa d'automatització de l'API de partner permet als clients aigües avall crear agents, el govern de la memòria passa a formar part del contracte del producte. La plataforma ha de donar als socis prou flexibilitat per crear automatitzacions útils sense deixar-los crear camins invisibles per compartir dades entre clients.
El que segueix sent incert
AWS ha descrit el model de control i el seu ús de JWT OAuth, polítiques de Cedar, AgentCore Gateway i operacions de memòria gestionada. El que queda menys clar a partir de l'anunci públic és com els equips dissenyaran aquestes polítiques en desplegaments de producció complexos, la facilitat de la depuració de polítiques i la quantitat de detalls operatius que els clients obtindran als registres de manera predeterminada.
La direcció més àmplia, però, és clara. La memòria de l'agent s'està convertint en una infraestructura. Quan això succeeix, l'autorització, l'observabilitat i la facturació l'han de seguir a la capa de passarel·la. Les empreses que creen plataformes d'agents fiables seran les que puguin fer que l'accés al model, els permisos d'eines i l'estat de la memòria siguin visibles i governables en un sol lloc.