Strands harness, introduced on September 21, 2026 and covered in AWS’s September 28 roundup, includes memory across runs and conversation resumption through session IDs. Before connecting a persistent agent to a customer-facing service, test that one customer’s context never becomes another customer’s input.
1. Map every place that retains context
Ask your developer to identify the stores for conversation history, summaries, tool-created files and durable memory. Record how each object is associated with an authenticated customer. These are different storage surfaces and should not be treated as a single chat transcript.
A session identifier is not sufficient authorization. Your application should verify ownership before loading history, and the model should not choose a customer identity from names mentioned in a prompt.
The following is our proposed application acceptance test. It is neither a report of a Strands vulnerability nor a claim that a harness automatically provides tenant isolation. Create two fictional accounts, A and B, with separate sessions and working directories.
Keep the test data harmless. You want a boundary failure to be observable without making that failure a real disclosure.
2. Trace a marker through allowed and forbidden reads
Give account A a distinctive invented project name. Resume A’s session and first establish that the agent can retrieve the information when it is allowed to do so.
Then ask a similar question from B without supplying the marker. Inspect both the response and the underlying retrieval trace:
| Test | Expected outcome |
|---|---|
| A resumes its own session | Its history is available |
| B submits A’s session ID | Rejected before loading history |
| B searches durable memory | No objects from A are retrieved |
| B opens an A-generated file | Storage access is denied |
Absence from the final answer is not enough. The model might receive private context without repeating it. Examine retrieved objects, file access and server-side filters to establish what actually entered the request.
If your setup summarizes long conversations, repeat the test after reaching its configured summarization condition. Derived summaries must stay within the same ownership boundary as the original messages.
3. Verify revocation and retention separately
Revoke A’s access to a test session and attempt to resume it. Authorization should use current permissions even when a summary already exists. Also test a session link or identifier copied before revocation.
Define what deletion means for active history, generated files and durable memory. Document any remaining backup or audit copies and your chosen retention period. Do not promise immediate erasure from every storage surface without checking it.
Accept the pilot only when authorized resumption works, cross-account retrieval is blocked and revocation remains effective after a restart. Keep these cases as regression tests whenever the memory backend, session routing or storage configuration changes.
Sources: Strands harness announcement and AWS’s September 28 roundup.
See it in our social posts
The key steps of this article, as a carousel. Follow us to catch the next ones.