Amazon Bedrock AgentCore Memory: did you know you can wall off each user's data without writing your own access-control code?

Hey, it's me! I found an update about AI agent memory security that got me really excited. If you're building a multi-tenant agent, this one's for you, so let's dive in!

AWS What's New aws.amazon.com

What was announced?

According to AWS What's New, Amazon Bedrock AgentCore Memory now supports fine-grained access control (FGAC). Through AgentCore Gateway, you can now enforce per-user and per-tenant memory isolation without building any custom authorization logic.

Specifically, you front your Memory resource with an AgentCore Gateway configured for OAuth (JWT) authentication, then attach Cedar policies to it. Access gets restricted based on the authenticated caller's identity.

The story so far

AgentCore Memory already had IAM identity-based and resource-based policies that could scope access by action, resource, and actor / session / namespace. But those controls only match against the IAM principal making the call, so they couldn't express a rule keyed on an OAuth/JWT identity.

That meant for architectures where an agent's backend receives an end user's JWT and calls Memory on their behalf — say, an agent app where users sign in through OpenID Connect — checks like "this user can only read their own actorId's data" had to be hand-rolled in application code.

What changes

With FGAC, you can move that authorization logic to the infrastructure layer (the Gateway). Concretely, you can now:

• Only allow a request when the caller's JWT sub claim matches the request's actorId (so users can only touch their own data)
• Restrict memory record access to namespaces derived from the user's token claims
• Allow or deny specific Memory operations per caller (for example, by OAuth client_id)

In other words, you get access control backed by cryptographically proven identity, without having to trust your application code at all. For anyone building a multi-tenant SaaS-style agent, that's a meaningful way to cut down authorization-bug risk.

Dive Deep

FGAC is built on the AgentCore Memory connector, a managed connector that wires a gateway target to the Memory data plane and exposes 12 Memory operations as Cedar actions. Here's the full list:

• ListEvents
• CreateEvent
• GetEvent
• DeleteEvent
• ListSessions
• ListActors
• RetrieveMemoryRecords
• ListMemoryRecords
• GetMemoryRecord
• DeleteMemoryRecord
• ListMemoryExtractionJobs
• StartMemoryExtractionJob

Each operation becomes a Cedar action named {target-name}___{METHOD}:{uri-template}, and policies can condition on that action plus path parameters (memoryId / actorId / sessionId / eventId / memoryRecordId) and request-body fields (namespace / namespacePath / metadata / filter / payload, among others). Evaluation is deny-by-default, and forbid overrides permit.

For example, enforcing "a caller can only see their own actorId's events" can look like this:

context.input.actorId == principal.getTag("sub")

Setup works by creating a policy engine, adding Cedar policies to it, and attaching it to your Gateway via policyEngineConfiguration (console, SDK, or CLI all work). The policy engine has two modes: ENFORCE and LOG_ONLY (evaluate and log without blocking traffic). The recommended flow is to validate in LOG_ONLY first, then switch to ENFORCE, so you don't accidentally deny live traffic.

One thing to watch out for: the batch operations BatchCreateMemoryRecords, BatchUpdateMemoryRecords, and BatchDeleteMemoryRecords aren't exposed as Cedar actions, so FGAC doesn't cover them. Since each request carries multiple records at once, the policy engine can't evaluate per-record or per-namespace conditions on them. You can still allow or deny these as a whole via IAM policies — it's just all-or-nothing at that level.

If you already run Memory and your actorId doesn't match your JWT's sub, there are migration paths:

• Compare against a custom claim your identity provider can issue (one that already carries your internal user id)
• Isolate by namespace instead of actorId (have your identity provider carry the namespace path as a claim and compare against that)
• Gradually align new events and records so actorId equals sub going forward, with a transition period for historical data

Wrap-up

• Amazon Bedrock AgentCore Memory now supports fine-grained access control (FGAC), so you can isolate memory per user or tenant without custom authorization code
• You attach Cedar policies to an OAuth (JWT)-authenticated Gateway, comparing things like actorId or namespace against JWT claims
• 12 Memory operations are exposed as Cedar actions, and you can roll this out safely with LOG_ONLY before switching to ENFORCE
• The three batch operations aren't covered by FGAC and still rely on IAM policies
• This is a great update if you're building a multi-tenant agent app and want authorization logic out of your application code