AgentCore Memory can now keep one tenant's memories out of another's

Agent memory is the part of an agent that quietly accumulates other people's data, and until now the job of keeping one user's memories away from another's belonged to whatever authorization code you wrote around it. On August 28 AWS moved that job into the platform. Amazon Bedrock AgentCore Memory now supports fine-grained access control, and in a second announcement the same day, namespace variables you define yourself.

Authorization moves into the gateway

The mechanism is an AgentCore Gateway configured for OAuth authentication with JWT tokens, carrying Cedar policies that restrict access by the caller's identity. With those in place you can enforce that a user reaches only their own actor's data, restrict memory records to namespaces derived from claims in the user's own token, and allow or deny individual Memory operations per caller.

The reason policies can be that precise is that the Memory connector exposes 12 Memory operations as Cedar actions, and the request attributes of each are available as conditions inside a policy. A rule can therefore turn on what is being asked for, not merely on who is asking.

Namespaces you define yourself

The second change is about how long-term memories are filed. You can define namespace variables along any dimension your application actually has, and AWS names organization, tenant, team and environment as examples. Up to five keys are allowed per memory resource, and one key can be referenced across several strategies.

The values arrive at runtime rather than at configuration time: they are supplied through the CreateEvent API, and the service substitutes them into the namespace template while it extracts long-term memory. The layout of the memory store therefore follows the shape of your tenancy, instead of your tenancy being flattened into whatever the store offered.

Why the two belong together

Separately, each is a modest feature. Together they close a loop: namespaces derived from token claims are only a boundary if something refuses a request that reaches across them, and a Cedar policy is only useful if the records are filed along a dimension it can name. AWS ties them explicitly, describing records restricted to namespaces derived from the user's token claims.

The practical consequence is that per-tenant isolation stops being application code. Authorization logic that lives in your agent is code you have to review, test and keep in step with every new Memory call; a policy attached to a gateway is a document, checked by the platform, on all 12 operations at once.