Per-Principal Memory Isolation

Persistent memory access is the configuration that allows a synthetic subject to store, retrieve, or act on durable memory across sessions, users, tasks, or workflows. This may include long-term memory, shared memory, user memory, vector memory, profile memory, task state, scratchpads, or context stores.

This configuration creates an elevated exposure condition because stored memory can influence future behavior after the original interaction has ended. If memory writes are not governed, attributed, reviewed, isolated, or time-limited, a synthetic subject may later act on false assumptions, malicious instructions, sensitive records, or outdated context.

The primary risk is memory poisoning. A user, external content source, compromised integration, or prior agent interaction may cause harmful content to be written into memory. That memory may then be retrieved in a later session and influence the synthetic subject’s reasoning, output, tool use, or treatment of another user.

A related risk is cross-user memory influence. If memory is not isolated by user, tenant, role, or workflow, content introduced through one interaction may affect another person’s future interaction. This may cause unauthorized personalization, data exposure, misleading recommendations, or actions based on context the later user never supplied.

Investigators should review memory write paths, stored memory entries, source prompts, provenance tags, identity records, retrieval logs, retention settings, isolation controls, and memory-driven outputs. Particular attention should be given to unexplained memory entries, progressively shortened or innocuous-looking records, cross-user influence, and behavior not justified by the current prompt or retrieved context.

Investigative Relevance

Persistent memory access is relevant because memory can become a durable configuration surface that shapes future synthetic subject behavior. Unlike transient prompt context, persistent memory may survive across sessions and continue influencing outputs after the original source is no longer visible.

This section is especially relevant where synthetic subjects use long-term memory, shared memory, user profiles, vector stores, task scratchpads, reusable summaries, or context stores that can be written by users, agents, tools, or retrieved content.

Memory-resident invocation occurs when a malicious, false, or instruction-bearing record written into persistent memory causes a synthetic subject to act in a later session. The current session may appear clean, while the effective instruction is retrieved from memory that was written earlier.

This invocation creates an elevated exposure condition because the triggering record can persist across time and, depending on memory isolation, across users. A prior user, external content source, compromised workflow, or earlier synthetic subject interaction may cause a memory entry to be stored, then a later unrelated user may trigger behavior shaped by that record.

The primary risk is persistence and replay. A poisoned memory record may re-invoke attacker-chosen behavior long after the original interaction has ended. The synthetic subject may retrieve the memory as relevant context and use it to alter reasoning, substitute identifiers, disclose information, call tools, change recommendations, or mis-handle a later task.

A related risk is innocuous-looking memory drift. Malicious memory may be written in stages, shortened over time, or phrased as a harmless preference, fact, procedure, or reminder. This can make the memory entry difficult to distinguish from legitimate personalization or task history while still preserving its triggering effect.

Investigators should review memory write logs, stored memory records, memory provenance, source sessions, user identities, retrieval logs, cross-session behavior, and downstream actions. Particular attention should be given to instruction-like records, unexplained memory changes, progressively shortened entries, actions in clean sessions that trace to prior memory writes, and memory entries that affect users other than the user who caused the write.

Investigative Relevance

Memory-resident invocation is relevant because persistent memory can become the source of action rather than merely background context. The investigation must determine whether the synthetic subject acted on the current prompt or on a stored record introduced earlier.

This section is especially relevant where synthetic subjects use persistent memory, user profiles, shared memory stores, long-term task memory, vector memory, reusable summaries, or cross-session context that can be written by users, tools, retrieved content, or prior agent activity.

Shared agent memory occurs when multiple agents read from or write to a common context window, memory store, scratchpad, or shared state repository. This allows synthetic subjects to build on each other’s work across steps, tasks, or sessions.

This deployment pattern creates an elevated exposure condition because the shared store becomes a common influence surface. Data, assumptions, instructions, or task state written by one agent may later be inherited by other agents and treated as trusted context.

The primary risk is persistent context poisoning. A malicious instruction, false assumption, sensitive record, or manipulated output may remain in shared memory and influence later runs. This can blend tainted state into otherwise legitimate work and make it difficult to determine which agent introduced the harmful content.

Investigators should review the shared memory design, write permissions, retention rules, provenance records, agent access paths, stored context, and memory retrieval logs. Particular attention should be given to persistent instructions, sensitive data copied into shared state, unexplained changes in agent behavior, and missing attribution for memory entries.

Investigative Relevance

Shared agent memory is relevant because it allows one synthetic subject’s output to shape the behavior of others beyond the original interaction. The adverse outcome may occur later, in a different task, or through a different agent than the one that first ingested or wrote the tainted content.

This sub-section is especially relevant where agents share scratchpads, task state, long-term memory, vector memory, project context, or reusable summaries without strict provenance, expiry, access controls, and validation.

Cross-tenant content injection occurs when content authored in one tenant, organization, or external customer environment is processed by an embedded artificial intelligence feature in another. This may occur through shared Software as a Service (SaaS) platforms, customer relationship management records, support tickets, shared documents, partner portals, email threads, comments, or other collaborative surfaces.

This deployment pattern creates an elevated exposure condition because a malicious actor does not need direct access to the victim’s tenant or agent. They only need to place content into a shared surface that the embedded synthetic subject later reads, summarizes, classifies, routes, or acts upon.

The primary risk is cross-boundary instruction execution. A malicious instruction may travel as ordinary business content from one party to another, then execute when the receiving party’s embedded agent processes it. The resulting action may occur under the victim organization’s SaaS tenant, service identity, or employee workflow, even though the effective instruction originated externally.

A related risk is attribution failure. The malicious payload and the executing agent belong to different parties, while the shared SaaS provider may only see normal platform activity. Victim logs may show the agent processing a legitimate record, and vendor logs may show permitted tenant behavior, making origin, authorization, and responsibility difficult to establish.

A further risk is shared-service data exposure. Where the vendor uses a shared artificial intelligence service across multiple customers, confidential data submitted by one customer may be processed, indexed, retained, or reused in a way that affects another customer’s environment. This can expose proprietary information, customer data, regulated records, or privileged material through generated answers, shared context, model memory, retrieval results, telemetry, or vendor-managed integrations.

Investigators should review the shared SaaS surface, source tenant or external origin, record history, embedded content, agent processing logs, tenant audit records, vendor logs, downstream actions, and shared-service data handling. Particular attention should be given to externally authored fields, cross-tenant records, shared documents, support tickets, partner inputs, unexpected tenant-to-tenant data exposure, and actions triggered without direct authentication by the external originator.

Investigative Relevance

Cross-tenant content injection is relevant because it allows an external party to influence a synthetic subject through ordinary shared business content. Standard authentication may not prevent the attack because the injected instruction enters through a legitimate collaboration or customer channel.

This sub-section is especially relevant where embedded artificial intelligence features process records, tickets, documents, forms, comments, emails, or other content that crosses tenant, vendor, customer, partner, or organizational boundaries. It is also relevant where vendor-hosted artificial intelligence services process confidential data from multiple customers through shared infrastructure, shared retrieval systems, shared model services, or vendor-managed integrations.

Memory and context data exfiltration occurs when a synthetic subject discloses protected information from conversation history, prompt context, retrieved documents, tool outputs, persistent memory, shared memory, task state, or other model-visible context outside its authorized boundary.

This adverse outcome creates organizational harm because context may contain sensitive material that was never intended to become an output. This may include internal messages, customer records, credentials, personal data, source material, prior prompts, tool results, retrieved records, or memory entries created during earlier sessions.

The primary harm is unauthorized disclosure of contextual information. A synthetic subject may reveal prior conversation content, summarize hidden context, expose retrieved records, disclose tool output, leak memory entries, or transmit session history to a user, tool, connector, vendor, or external destination that is not authorized to receive it.

A related harm is boundary collapse across time, users, and workflows. Context may be inherited from a prior session, another user, a shared memory store, a tool call, or an agent handoff. If the synthetic subject later exposes that context, the disclosure may not be obvious from the current prompt alone.

Investigators should review conversation history, prompt context, retrieved source records, tool outputs, memory reads, memory writes, shared context stores, session state, agent handoff records, prompt and response logs, tool-call logs, and destination records. Particular attention should be given to prior-session content appearing in current outputs, memory entries disclosed to the wrong user, tool outputs copied into responses, and context transmitted to external tools or connectors.

Investigative Relevance

Memory and context data exfiltration is relevant because synthetic subjects often operate over hidden or semi-hidden context that users and investigators may not fully see. The harmful outcome is the disclosure of that context outside its intended boundary.

This sub-section is especially relevant where synthetic subjects use persistent memory, shared memory, retrieval-augmented generation, tool outputs, long context windows, conversation summaries, agent handoffs, or cross-session state.

Cross-boundary data disclosure occurs when a synthetic subject causes protected information to move outside its authorized user, tenant, customer, vendor, organizational, or trust boundary. The data may remain inside a platform or service, but still be exposed to a party, account, agent, tenant, workflow, or organization that is not authorized to receive it.

This adverse outcome creates organizational harm because boundary controls define who may access protected information. A synthetic subject may summarize, retrieve, infer, route, or disclose data across boundaries that would normally be separated by identity, tenant, role, customer, vendor, department, legal entity, or contractual control.

The primary harm is unauthorized cross-boundary exposure. Protected information belonging to one user, customer, tenant, team, or organization may appear in another user’s output, another customer’s record, another tenant’s workflow, a vendor-accessible context, or a shared agent environment.

A related harm is loss of data sovereignty and accountability. The disclosure may occur through shared indexes, cross-tenant SaaS workflows, vendor-hosted AI features, shared memory, collaboration records, support tickets, or agent-to-agent handoffs. Investigators may need to determine which boundary was crossed, what data moved, who received it, and whether the disclosure violated access policy, contractual terms, privacy obligations, or regulatory requirements.

Investigators should review tenant logs, user entitlements, retrieval records, shared indexes, connector access, vendor audit logs, support records, memory stores, agent handoff records, prompt and response logs, and downstream recipients. Particular attention should be given to data from one customer, tenant, user, or organization appearing in another boundary’s output, record, workflow, or agent context.

Investigative Relevance

Cross-boundary data disclosure is relevant because synthetic subjects may combine data across users, tenants, systems, and organizations in ways traditional access controls were not designed to observe. The harmful outcome is not only that data was disclosed externally, but that it crossed an authorization boundary.

This sub-section is especially relevant where synthetic subjects operate in shared-tenant platforms, vendor-hosted AI services, customer relationship management systems, support tools, shared memory stores, enterprise retrieval indexes, collaboration platforms, or agent-to-agent workflows.