Durante dos años la industria vendió agentes con memoria como una virtud. Nadie preguntó en voz alta lo obvio: si el agente recuerda, ¿recuerda de quién? El 28 de agosto AWS publicó dos anuncios para Amazon Bedrock AgentCore Memory que responden esa pregunta por fin en la capa de infraestructura, y no en el código de la aplicación: control de acceso fino con políticas Cedar y variables de namespace definidas por el desarrollador.
Qué pasó
Son dos features liberadas el mismo día, y hay que leerlas juntas porque resuelven las dos mitades del mismo problema.
La primera es fine-grained access control (FGAC) para Memory. Permite poner un AgentCore Gateway al frente del recurso de memoria, autenticado con OAuth (JWT), y colgarle políticas Cedar que restringen el acceso según la identidad del llamante autenticado. Con eso se puede forzar que cada usuario solo lea los datos de su propio actor, limitar los registros a namespaces derivados de los claims del token, y permitir o negar operaciones específicas por llamante.
La segunda son las variables de namespace flexibles: el desarrollador define sus propias llaves —organización, tenant, equipo, ambiente— y las referencia en la plantilla de namespace de una estrategia de memoria, en lugar de sobrecargar las variables integradas o duplicar estrategias para cada dimensión. Están disponibles hoy en todas las regiones donde AgentCore Memory está en GA, sin costo adicional.
Por qué importa
El patrón que AWS está desmontando aquí es el mismo que rompió a media industria SaaS hace quince años: autorización implementada en el código de la aplicación. Cuando el if user.tenant == record.tenant vive en tu backend, la aislación de datos depende de que ningún developer olvide ese if en ningún endpoint, para siempre. Con agentes el problema empeora, porque el agente no es un endpoint: es un proceso que decide en runtime a qué herramientas llama y qué recuerda, y el prompt de un usuario puede intentar dirigir esa decisión.
Ahí está el punto de seguridad que me interesa. La memoria de largo plazo de un agente multi-tenant es un canal de fuga de datos entre inquilinos que no se ve en ningún escaneo de vulnerabilidades: no hay CVE, no hay puerto abierto, solo un agente que extrajo un "hecho" de la conversación del cliente A y lo recuperó como contexto en la sesión del cliente B. Es prompt injection con persistencia, y la mitigación real no es un filtro de contenido: es que el dato del cliente A sea criptográficamente inalcanzable desde la sesión del cliente B.
Que la decisión se tome contra los claims de un JWT en un gateway administrado, y no contra una variable de sesión de tu aplicación, cambia la conversación con el auditor. Deja de ser "confiamos en nuestro código" y pasa a ser "aquí está la política, aquí está la prueba de identidad".
El detalle técnico
FGAC no es un flag que se prende. Se construye sobre el AgentCore Memory connector, un conector administrado que conecta un target del gateway al data plane de Memory y expone 12 operaciones de Memory como acciones Cedar, con los atributos de cada request disponibles como condiciones de política. Esa última parte es la que importa: no se autoriza "acceso a Memory" en bloque, se autoriza esta operación sobre este namespace para este caller, con los atributos del request evaluables en la condición.
Cedar, vale recordarlo, es el mismo lenguaje de políticas detrás de Amazon Verified Permissions: sintaxis declarativa, analizable formalmente, con permit/forbid y precedencia del forbid. Eso significa que una política de aislación bien escrita se puede razonar sin ejecutar la aplicación —y sin depender de la cobertura de tus tests.
Del lado de los namespaces, el mecanismo es de tres pasos: se definen las llaves en el recurso de memoria, se referencian en la plantilla de namespace de la estrategia, y los valores se pasan en runtime vía la API CreateEvent. El servicio los sustituye en la plantilla durante la extracción de memoria de largo plazo. El límite es de cinco llaves por recurso de memoria, cada una referenciable en varias estrategias.
Cinco llaves suena generoso hasta que se modela una jerarquía real de enterprise —tenant, subsidiaria, región, unidad de negocio, ambiente— y ya se acabaron. Vale diseñar la jerarquía antes de escribir la primera plantilla.
Qué hacer
- Si ya tienes agentes en AgentCore con Memory y más de un cliente encima, esto es deuda técnica que acabas de poder pagar. Migrar la autorización del código al gateway no es cosmético: elimina una clase entera de bugs de aislación.
- Audita primero, migra después. Antes de escribir políticas Cedar, revisa qué namespaces existen hoy y si la extracción de memoria de largo plazo ya mezcló datos entre inquilinos. FGAC protege de aquí en adelante; no limpia el pasado.
- Diseña la jerarquía de namespaces contra el límite de cinco llaves, y déjala documentada. Cambiar plantillas con memorias ya extraídas es doloroso.
- Trata la memoria del agente como un data store regulado, no como caché. Si guarda datos de clientes, entra en tu inventario, en tu política de retención y en tu alcance de auditoría.
- Si vendes o evalúas plataformas de agentes, esta es la pregunta nueva para el proveedor: ¿la aislación entre inquilinos se hace contra una identidad criptográfica, o contra una variable de tu aplicación? La respuesta separa a los serios del resto.
Fuentes
- Amazon Bedrock AgentCore Memory now supports fine-grained access control — AWS What's New, 28 ago 2026
- Amazon Bedrock AgentCore Memory now supports flexible namespace variables — AWS What's New, 28 ago 2026
- Amazon Bedrock AgentCore Developer Guide — documentación de Memory, namespaces y Gateway