AgentCore memory poisoning: what AWS builds in, what its new write-validation pattern adds, and where the demo evidence stops

AgentCore already has access‑level and some content‑level controls for memory writes. The new AWS pattern adds one thing the post says those controls do not provide on their own: a single, tunable scoring step on the write path that combines meaning, injection‑pattern, namespace and write‑rate signals into one decision, with quarantine and alerting [1](https://aws.amazon.com/blogs/security/help‑defend‑against‑memory‑poisoning‑in‑amazon‑bedrock‑agentcore‑with‑multi‑layer‑write‑validation/). It is a reference sample you deploy and operate. AWS does not describe it as switched on automatically. The guidance is a security blog post by an AWS delivery consultant, so treat it as a defensive architecture with AWS‑run test numbers, not as product documentation or independent testing.

The post lists these existing controls 1:

• IAM condition keys (bedrock‑agentcore:namespaceVariable/*) that gate CreateEvent at the write path.
• Namespace‑variable validation (allowedValues, regexPattern) that constrains which values are permitted.
• Custom memory‑strategy consolidation prompts that shape and filter extracted content.
• The ApplyGuardrail API, which can assess memory‑write content independently against configured policies.
• AgentCore Identity, which governs who can authenticate, and AgentCore Policy (Cedar), which controls which namespaces a principal can write to.

These cover who may write, where, and with which values, plus some content checking. The post's point is that none of them is a combined content‑aware score with isolation and alerting.

The pattern attaches a Lambda function as a pre‑write interceptor on AgentCore Gateway. It scores each memory write on four signals and returns one of three outcomes 1:

• Semantic drift (40% weight): cosine similarity between the write and the current session context, using Amazon Titan Text Embeddings V2 vectors. AWS positions it as the signal that can still help when phrasing is non‑English or obfuscated.
• Instruction pattern (25%): a regex pre‑filter for known injection markers, with 14 patterns in the test configuration.
• Namespace boundary (25%): a deterministic check of which namespaces the session may write to.
• Write‑rate anomaly (10%): a DynamoDB counter comparing writes per session with a baseline.

The decision bands are ALLOW below a score of 35, QUARANTINE from 35 to 60, and DENY above 60. Quarantined writes go to an isolated namespace and the agent keeps running. Denied writes are blocked and an Amazon SNS alert goes to the security team. Alerts carry the agent ID, target namespace, composite score and a content preview. These weights and thresholds are the sample's values. The post calls the layer tunable and says results depend on your content and configuration, so they are starting points, not calibrated policy.

• Built in, enforced by AWS identity and policy services: IAM namespace conditions, namespace‑variable validation, Cedar policy, Identity.
• Built in, but you configure the content: consolidation prompts and ApplyGuardrail policies.
• Custom, deployed by you: the Gateway Lambda interceptor, the scoring weights and thresholds, the quarantine namespace, DynamoDB tables and SNS alerts. The sample ships as a CDK stack.
• Not covered by the interceptor: writes that bypass AgentCore Gateway, such as direct SDK calls. AWS suggests validating in agent code before calling create_event, or relying on IAM namespaceVariable conditions and custom‑strategy consolidation prompts for similar controls.

The post also adds Cedar policies as a secondary layer. It says they help enforce namespace‑level access control, including for requests the Lambda interceptor does not evaluate. The sample describes eight Cedar policies. Together they block agent writes to system/ and to other users' namespaces, restrict quarantine/ writes to the validation Lambda, and require elevated permission for shared/. The namespace tiers are system/ (deployment‑only), user/{userId}/ (standard validation), shared/ (stricter thresholds) and quarantine/ (agents cannot read it) 1.

AWS tested 11 scenarios: three benign writes and eight attack payloads. The post says the pipeline returned the expected decision for all 11. The three benign writes were allowed at score 0. The two English‑language attacks were denied at 61–65, the three regex‑bypass attacks were quarantined at 40, the two namespace attacks were denied at 63–65, and a burst‑injection case was quarantined at 48 1.

The limits matter more than the tally:

• The demo uses a local keyword‑overlap approximation of semantic similarity, not Amazon Titan Text Embeddings V2. The post says real embeddings give more granular scores, and some regex‑bypass cases might move from QUARANTINE to DENY.
• Semantic drift flagged all eight attacks in the demo, but that result comes from the approximation. It is not evidence of 100% protection or of real‑embedding performance.
• Three benign cases cannot establish a false‑positive rate. The post reports none, and it gives no results for realistic, varied production traffic.
• A drift score measures divergence from the session context. The post's own example is a recipe session followed by a financial‑transfer write. A legitimate topic change would diverge too, so threshold tuning against your own traffic is required.
• The post says regex patterns should be updated as new techniques appear, which is an admission that pattern coverage ages.

The Gateway interceptor has a failure policy. Set it to ALLOW when uptime comes first, accepting that writes can proceed unvalidated if the validator is unavailable. Set it to BLOCK for high‑security environments, accepting that Lambda failures will temporarily stop memory writes 1. The post gives no test results for either mode.

AWS's figures come from a test environment in US East (N. Virginia) and will vary by configuration and Region:

• Warm‑path validation adds about 26 ms to the memory write path.
• A cold start takes about 230 ms, which the sample mitigates with provisioned concurrency.
• Titan Embeddings V2 inference (256 dimensions) takes about 12 ms.
• A DynamoDB counter read takes about 5 ms, or under 3 ms with DAX.
• Regex matching takes under 1 ms.

AWS estimates about $2.50 per day for 10,000 memory writes per day at on‑demand US East pricing when the post was written, and points readers to the AWS Pricing Calculator for their own workload. These are AWS test and estimate numbers. OpenTools has not measured latency, cost or attack prevention.

A reasonable evaluation sequence based on the post's own caveats:

• Inventory every path that writes memory. Anything that skips Gateway needs its own control.
• Run the sample with real Titan embeddings against your own benign traffic to see how many legitimate writes land in QUARANTINE or DENY.
• Choose the failure policy deliberately and decide who reviews quarantined content.
• Treat the weights and the 35 and 60 thresholds as starting values to tune.
• Keep namespace permissions tight with IAM and Cedar, since those checks are deterministic and do not depend on a score.

AWS frames the result as defense in depth that can help flag content a single technique might miss. It does not claim memory poisoning is solved.