AGENTSEC01-BP01 Implement memory isolation and integrity controls
Shared agent memory is the shortest path for a single affected session to contaminate every other one. Partitioning memory along the boundaries that matter for the workload, and verifying what comes back out, contains the scope of memory poisoning to the partition it touched.
Desired outcome:
-
You partition agent memory along the isolation axes that match the workload (session, user, tenant, agent, or group), with no cross-contamination between contexts.
-
You detect unauthorized modifications to stored memories through integrity checks and keep a tamper-evident history of state changes.
-
You scope memory access per agent through least-privilege IAM policies, so each agent can read or write only the namespaces it is authorized for.
Common anti-patterns:
-
Sharing memory across agents or sessions by default, so an affected session can read or overwrite another's context and poisoning spreads laterally.
-
Storing agent memory in plaintext without encryption at rest, exposing reasoning context, intermediate tool results, and user data if the underlying storage is reached through a misconfigured IAM policy or storage exposure.
-
Skipping integrity checks on memory reads, letting silently corrupted or injected memories influence decisions and compound across sessions.
-
Granting every agent broad read/write access to the full memory store, producing a flat trust model where any affected agent reaches unrelated workflows.
Benefits of establishing this best practice:
-
Per-session and per-agent memory partitioning contains the scope of any single affected agent.
-
Cryptographic integrity verification on memory reads catches poisoning attempts before affected data influences decisions.
-
IAM-scoped memory access limits each agent to only the partitions it requires, reducing lateral movement.
Level of risk exposed if this best practice is not established: High
Implementation guidance
Memory poisoning is a lateral-movement problem. If every agent reads from the same pool, one affected write becomes every agent's input, and the cost of a single successful injection is the correctness of the entire system. The design shift is to treat memory like a tenant-aware data store from the start. Partition it along the boundaries that actually matter for the workload:
-
Session
-
User
-
Tenant
-
Agent
-
Group
Make cross-partition access the exception you must explicitly grant, not the default you must explicitly prevent.
Amazon Bedrock AgentCore Memory expresses this partitioning through a hierarchical namespace system built on actorId and sessionId identifiers, with dynamic placeholders like {actorId} and {sessionId} that resolve at call time. A namespace template like /support-agent/{actorId}/preferences gives each user an automatically scoped partition without hardcoding identifiers. The invoking session determines which namespace the agent reads from or writes to, and the IAM policy on the agent's role bounds which namespace prefixes it can touch, so even a namespace constructed incorrectly by the agent is denied by the authorization layer.
Shared namespaces are not an anti-pattern when they are intentional. A common product knowledge base read by every support agent, a team-scoped working context, or a coordination memory where cooperating agents exchange intermediate results are legitimate shared partitions. Model them as named namespaces (for example, /support-agent/shared/product-knowledge or /team-{teamId}/shared/working-context) and scope each agent role's IAM policy to the specific shared namespaces that agent is authorized to reach. The failure mode to help prevent is sharing by default, not sharing that has been designed and authorized.
Integrity is the other half of the pattern. AgentCore Memory keeps an append-only audit trail where the consolidation process marks outdated records as INVALID rather than deleting them, so the full sequence of changes is recoverable for forensic analysis. That helps protect history, but it doesn't detect whether a specific record was silently modified outside the normal consolidation flow. AWS KMS HMAC signatures layer tamper detection on individual records: sign on write, recompute and compare on read, and treat a mismatch as evidence the record was altered. Pair that with customer-managed AWS KMS keys on the memory resource itself (through the encryptionKeyArn parameter) for sensitive reasoning context, and the built-in memory strategies filter personally identifiable information (PII) from long-term records by default.
Monitoring completes the control. Route memory access events to Amazon CloudWatch Logs, alarm on cross-namespace retrieval attempts and high-frequency writes from a single agent, and run red-team exercises that simulate memory poisoning to verify isolation controls hold under pressure.
Implementation steps
-
Create the memory resource with customer-managed encryption: Provision an Amazon Bedrock AgentCore Memory resource, specify encryptionKeyArn with a customer-managed AWS KMS key for sensitive workloads, and set eventExpiryDuration to match your data retention requirements.
-
Design a hierarchical namespace schema: Use dynamic placeholders ({actorId}, {sessionId}) to partition memory per user and per session automatically, for example /support-agent/{actorId}/preferences for user-scoped data and /support-agent/shared/product-knowledge for intentional shared context.
-
Configure memory strategies at the correct isolation level: Apply semantic, user preferences, summary, or custom strategies with namespaces scoped to the partition you want, and use custom strategy overrides where domain-specific extraction and consolidation prompts are needed.
-
Scope IAM roles to authorized namespaces only: Give each agent a dedicated IAM role with resource-based policies that allow only the namespace prefixes it requires, denying all other namespaces by default.
-
Enforce namespace-scoped retrieval in agent code: Call retrieve_memory_records and list_events within the agent's authorized namespaces only, so cross-tenant data is blocked at the application layer as well as the authorization layer.
-
Layer HMAC integrity verification on sensitive records: For workloads that need tamper detection beyond the built-in audit trail, store a KMS-generated HMAC alongside each memory entry and verify it on read before the content influences agent decisions.
-
Alarm on memory access anomalies: Configure Amazon CloudWatch alarms for cross-namespace retrieval attempts, high-frequency writes from a single agent, and spikes in memory extraction failures, and route alerts through Amazon EventBridge for automated incident response.
-
Audit strategies and run red-team exercises: Periodically review extraction and consolidation patterns with list_memories and retrieve_memory_records to verify strategies are capturing the right information and that PII filtering is working, and simulate memory poisoning scenarios to validate the isolation controls hold.
Resources
Related best practices:
Related documents:
Related services:
