Amazon Bedrock AgentCore: Session Isolation Is Not Long-Term Agent Memory

An AI agent that remembers a conversation is useful. An agent that remembers another customer's conversation is a data incident. Amazon Bedrock AgentCore provides managed session isolation, but your application still decides which user is allowed to open which session and retrieve which memories.

This guide focuses on that boundary. It is for teams moving a single-user agent prototype into a service shared by multiple customers.

Runtime Sessions and Durable Memory Solve Different Problems

AWS documents AgentCore runtime sessions as isolated execution environments. A session can retain working state across invocations within its lifecycle. AgentCore Memory is a separate capability for retaining and retrieving context beyond that temporary execution environment.

Think of runtime state as a workbench and durable memory as a record store. Files created while solving a task may belong on the workbench. A customer preference that should survive a future session needs an intentional persistence policy.

Check the compute type and lifecycle configuration you actually deploy. Do not assume that every AgentCore compute option has identical isolation or persistence behavior.

Bind a Session to an Authenticated Owner

A session identifier is a routing value, not proof that the caller owns the session. Resolve ownership on your server before forwarding a request.

A simple application record can look like this:

{
  "tenantId": "tenant-example",
  "userId": "user-example",
  "conversationId": "conversation-example",
  "runtimeSessionId": "server-generated-session-id"
}

This is an application data model, not an AgentCore API request. For each incoming message, authenticate the caller and load the conversation within that caller's tenant. Only then read the associated runtime session ID.

Do not accept a client-supplied tenant ID as authorization. A legitimate-looking identifier can still reference another customer's record.

Keep Memory Retrieval Inside the Same Boundary

Runtime isolation does not repair an overly broad database query. If a tool retrieves records without a tenant filter, the isolated agent can still receive data it should never see.

Apply ownership constraints in the storage layer or tool service. Use separate credentials where the security model calls for them, and make each retrieval auditable. Define retention and deletion behavior before storing conversation content indefinitely.

A support agent may need an order status for the current customer. It usually does not need the full historical conversation archive for every customer in the account.

Test the Failure Paths

Before rollout, create two test tenants with obviously different synthetic data. Run these checks:

1. Start separate conversations and confirm ordinary follow-up works.
2. Attempt to reuse the other tenant's conversation identifier.
3. Start a fresh runtime session and verify that only explicitly persisted state returns.
4. End or expire a session and test the application's recovery behavior.
5. Delete a synthetic memory and verify retrieval no longer returns it.

The expected cross-tenant outcome is an authorization failure before agent execution. Passing only a happy-path chat test is insufficient.

Operate It Like an Application

Track session creation, failed ownership checks, tool calls, and lifecycle errors. Avoid logging raw sensitive prompts by default. Give the support team enough correlation information to investigate a failure without exposing customer content.

Start with a narrow agent workflow, a clear session owner, and an explicit persistence boundary. Managed isolation is valuable infrastructure; the application remains responsible for deciding what that isolated agent is allowed to access.

Further Reading

• Production agent memory and planning
• LLM evaluation and testing

Sources

• AWS: AgentCore isolated sessions
• AWS: Runtime lifecycle configuration
• AWS: AgentCore Memory organization
• AWS: Runtime security practices