AgentCore Memory can now enforce who gets which memories

Amazon Bedrock AgentCore Memory now supports fine-grained access control through AgentCore Gateway. AWS says a gateway can authenticate an OAuth JSON Web Token and apply Cedar policies before a caller reaches stored short-term events or long-term memories.

For businesses building multi-user or multi-tenant agents, this changes where an important control can live. Instead of trusting every application route to perform the same tenant check, a team can enforce user identity, namespace scope, and allowed operations at a managed infrastructure boundary. The practical promise of this article is narrower: understand that boundary, then prove that the wrong user cannot cross it.

What did AWS add to AgentCore Memory?

AWS's August 28 announcement describes an AgentCore Gateway configured for OAuth JWT authentication in front of an AgentCore Memory resource. Cedar policies can evaluate the authenticated caller and request attributes before allowing a memory operation.

The managed Memory connector exposes 12 Memory operations as Cedar actions. AWS says policies can limit a caller to its own actor data, restrict records to namespaces derived from token claims, and allow or deny particular operations. That is more specific than giving an application one broad credential and asking its code to remember which records belong to whom.

The dependency order matters. An identity provider issues claims; the gateway validates the token; a Cedar policy relates those claims to actor, namespace, and action attributes; only an allowed request reaches the Memory data plane. A failure or ambiguity earlier in that chain cannot be repaired by a well-written policy later in it.

Why are namespaces and authorization different controls?

AgentCore Memory uses namespaces to organize extracted long-term memories. In a companion release, AWS added flexible namespace variables, allowing dimensions such as organization, tenant, team, or environment instead of relying only on built-in variables.

AWS says a memory resource can define up to five keys, reuse them across strategies, and receive values through the CreateEvent API. During long-term memory extraction, the service substitutes those values into a strategy's namespace template. AWS states that this namespace feature is available in regions where AgentCore Memory is generally available at no additional cost.

A namespace organizes data; it does not prove the caller should see that data. BaristaLabs' interpretation is that a tenant identifier becomes a defensible boundary only when the value comes from a trusted source, the policy binds it to the authenticated caller, and a denied cross-tenant request is observed. Letting a client choose both its identity claim and target namespace would preserve the appearance of separation while weakening the control.

What does the gateway remove from application code?

A centralized gateway can remove repeated authorization decisions from individual handlers. That reduces the chance that one new route fetches memory by actor ID but forgets to compare the actor with the authenticated user. It also gives reviewers one policy surface for the supported connector actions rather than several implementations in different services.

It does not remove all application responsibility. The application still decides which identity provider to trust, which claims represent a tenant or user, which runtime values enter namespace templates, and what content should become an event. It must also handle denied requests without silently retrying under a broader service identity.

Nor does fine-grained access control answer retention, deletion, extraction quality, prompt injection, or whether a remembered statement is true. Our earlier memory misfire drill addresses contamination and forgetting behavior; this release addresses who may call memory operations. A team needs both kinds of evidence, but they are not interchangeable.

How should a team test tenant isolation?

Start with the exact authorization chain, not a diagram of the intended architecture. Record the token issuer and audience, the claims used by Cedar, the actor and namespace attributes each operation supplies, and the policy version attached to the gateway. AWS's fine-grained access-control guide is the implementation reference; the announcement alone is not a deployment specification.

Then run paired requests with synthetic data. User A should create and retrieve a harmless marker inside tenant A. User B should attempt the same read against tenant A, and user A should attempt an operation its role does not permit. The expected result is not simply that the user interface hides the marker: the gateway request itself should be denied, with evidence that identifies the tested action and policy version without recording sensitive token contents.

Include claim and namespace mutations. Try a missing tenant claim, a valid token with an altered request namespace, an expired token, and a service identity that has no user binding. If a backend legitimately needs cross-tenant access, give that path a separate identity and explicit policy instead of weakening the normal user rule.

Finally, repeat the negative tests when the identity provider, Cedar policy, gateway target, connector, or namespace template changes. This is a BaristaLabs recommendation, not an AWS requirement. Its purpose is to keep “the gateway is configured” from becoming an untested proxy for effective isolation.

What should the production decision record say?

The decision should name the resource and region, trusted issuer, claim-to-tenant mapping, actor and namespace pattern, allowed connector actions by role, and owner of the Cedar policy. It should link to one successful same-tenant test and at least one denied cross-tenant test.

Keep the conclusion bounded. A passing result supports the tested identity, action, policy, and namespace combination at that time. It does not establish that every application path is safe or that stored memory is correct, deletable, or compliant with a particular obligation.

AgentCore Memory's new control makes infrastructure-level isolation more practical, but the valuable business outcome is not fewer lines of authorization code. It is a smaller, reviewable boundary with a denial that the team can reproduce.

BaristaLabs helps teams turn agent capabilities into testable operating controls through responsible AI consulting. If you are preparing a multi-tenant AgentCore Memory deployment, bring one identity-to-namespace path to a focused boundary review.

Sources

• AWS: AgentCore Memory now supports fine-grained access control
• AWS Developer Guide: Fine-grained access control for Memory
• AWS: AgentCore Memory now supports flexible namespace variables
• AWS Developer Guide: Specify long-term memory organization with namespaces