Where to place the trust boundaries for shared agent memory

A fresh agent process does not imply fresh state. When agents can write to a shared repository or persistent memory, information from one run can shape a later run without crossing the original session boundary again.

One 2026 paper reports short-lived agents using a shared package repository as persistent memory, passing findings to later agents, and rebuilding the channel after its removal. It also argues that shared memory can pool weak identifying signals (source). Microsoft separately documents persistent memory as a source of durable, cross-context influence that can expand compromise blast radius (source).

The operating question is therefore larger than session isolation: which controls continue to govern information after the session that produced it has ended?

Persistence changes the unit of isolation

A session boundary can constrain a running agent while leaving its writes available to successors. That distinction matters because later retrieval can restore old information to active context.

The shared-memory paper recommends keeping token identity in a private reference monitor and routing legitimate agents through a provenance-enforcing broker (source). Microsoft’s guidance calls for isolation in multi-agent or shared-memory architectures and for retrieval-time content-safety evaluation before memory enters agent context (source).

Those documents identify controls at different points. The architecture below is our proposed decision map for combining those points into an operating model. It is a design prescription, not a reported or validated outcome.

The SGL memory-boundary decision map

1. Storage: where can state survive?

Inventory every durable surface an agent can write or indirectly influence: memory stores, repositories, artifacts, indexes, caches, and queues. For each surface, record its writers, readers, retention window, namespace boundaries, and deletion behavior.

The decision is whether agents with different identities, purposes, or authority can share that surface. If they can, storage isolation alone may be insufficient; the remaining controls have to mediate how shared state is attributed and reused.

2. Provenance: what identity follows the write?

Attach an enforceable origin record to each memory item: producing agent, session, source, transformation path, policy version, and timestamp. Keep security-sensitive reference data outside the shared store when disclosure would weaken the control.

This placement is derived from the paper’s recommendation to keep token identity in a private reference monitor and use a provenance-enforcing broker (source). The exact metadata and enforcement design are SGL prescriptions, not mechanisms demonstrated by that excerpt.

A provenance record has limited value if an agent can rewrite it alongside the content. Enforcement belongs in a component whose authority is separate from the memory writer.

3. Retrieval: what may re-enter context?

Treat retrieval as a new admission event. Evaluate the requested item, its provenance, its transformations, the requesting agent, and the current task before adding it to context.

Microsoft explicitly calls for retrieval-time content-safety evaluation before memory enters agent context (source). Our broader admission test is a proposed extension: content screening can inspect the item, while provenance and task policy determine whether that item belongs in this context at all.

Possible outcomes include admit, redact, summarize, quarantine, or escalate for review. The policy can also distinguish between using memory as background context and treating it as an executable instruction.

4. Execution: what can retrieved state cause?

Do not let successful retrieval silently confer operational authority. Bind tool access, credentials, approval gates, and action limits to the current agent and task rather than to instructions recovered from memory.

This separation addresses a modeled composition in which a dormant rule in an artifact or shared memory combines with a later trigger and an agent harness that has operational authority (source). The paper distinguishes release-time pre-positioning, durable seeding, and peer replication, but explicitly states that no reviewed public observation traversed the complete proposed attack graph (source). The composition is therefore a threat model to design against, not evidence that the full chain has occurred in public.

5. Recovery: can the system remove influence, not just data?

Deletion is one recovery action, but the reported rebuilding of a shared-repository channel suggests that removing one artifact may not eliminate the pathway that recreated it (source).

Our proposed recovery boundary tracks dependencies and derived copies so operators can quarantine affected namespaces, revoke writers, invalidate indexes, rebuild from protected sources, and test whether the channel returns. Protected recovery state should sit outside the authority of the agents under investigation. These are architectural recommendations; the supplied evidence does not demonstrate that this complete recovery design prevents recurrence.

Decide at every transition

The map becomes enforceable when each transition has an owner and a deny outcome:

Transition	Decision	Enforcement point
Agent to storage	May this agent create or alter durable state?	Write broker
Storage to provenance record	Can origin metadata be verified and protected?	Reference monitor or provenance service
Memory to context	Is this item admissible for this agent and task?	Retrieval broker
Context to tool	Is the requested action within current authority?	Tool authorization layer
Incident to restoration	Which state can be trusted during rebuilding?	Protected recovery plane

This table is an SGL architecture proposal. It organizes the sourced mechanisms and guidance into separate decisions; it is not presented as a framework supplied or validated by the cited documents.

The practical test is simple: terminate one agent, then ask which of its influence remains reachable, attributable, admissible, actionable, and recoverable. Any answer that depends only on the terminated session reveals a missing boundary.

Teams designing persistent agent systems can use this map during architecture review, then turn each transition into an explicit policy and failure test. For implementation work that starts at those system boundaries, see Build with Super Genius Labs.