Failure Modes That Only Appear When Agent State Lives Across User Boundaries

Deploying persistent AI agents at scale for each user requires isolated runtimes, per-user state that lasts, and lifecycle controls that keep one user’s authority from carrying over into another user’s session. When agent state crosses user boundaries, privilege drift, credential leakage, and poisoned memory become failures in how the system works that go beyond individual bad responses. A dedicated VM per user provides credential isolation and snapshot-and-restore that preserves ownership across suspension.

Why persisting state across user boundaries is a qualitatively different engineering commitment

Persistence lets an agent pick up its work without rebuilding its context, but it also lets yesterday’s records authorize what it does tomorrow. That changes what stored information can do. Ding et al.’s Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents contrasts episodic agents, which make “the past irrelevant,” with agents whose state “can shape, or authorize, its next action.” Once that authority reaches a different user’s session, a safety argument confined to the original interaction no longer holds.

The operative state extends well beyond conversational memory. It includes task ledgers, permission records, credentials, provenance trails, trigger conditions, and externally committed side effects. Each can remain relevant after the interaction that created it has ended. An episodic reset removes that continuity by construction, making the reset both a limitation and a security property. Choosing persistence therefore creates an obligation to govern what surviving state may authorize, for whom, and under which conditions.

Privilege drift: how a permission granted for one purpose silently broadens

Privilege drift occurs when authority granted for one purpose persists into another context without explicit approval. No attacker is needed to create the expansion. The IBM TLS Agentic Platform postmortem, authored by Tony Erwin of IBM Infrastructure AI CoE, describes how a cross-team MCP call can lose the user’s identity at an intermediate hop. A service account silently takes its place, so the agent operates under an elevated identity it was never granted.

All agents ran as one Unix user inside one container. The operations agent held the founder agent’s key and acquired that agent’s identity and read access to everything. The intended boundary had no infrastructure equivalent. Moving to one container and one UID per agent broke roughly 235 skill files, revealing how deeply the fleet depended on shared identity.

IBM’s response centralized tracing, authentication, header propagation, and state persistence in AI CoE Agent Utils. The survey likewise treats permission state as its own kind of state that helps control what an agent can do. Permissions need explicit scope, provenance, and expiry metadata alongside a credential that remains usable.

Credential and tool state decay: when tokens outlive the consent that justified them

Credential decay makes privilege drift executable through an otherwise ordinary tool call. The HashiCorp Terraform MCP Server shipped a CVSS 10.0 flaw in which, in stateless HTTP mode, one user’s Terraform token could serve a later user’s request. The privileged API received a valid credential from the wrong caller’s context. The request could therefore appear legitimate downstream. Standardizing the token format could not repair a failure in session-state handling.

The survey describes the underlying condition as one where “a token outlives the consent that justified it, or a scope granted for one operation is reused for another.” Checkpoint restoration introduces a related risk when an agent regenerates a slightly different request and retries a tool call. The retry becomes a new external request, potentially reusing already-consumed authority or duplicating an irreversible side effect. Recording and replaying committed effects, rather than reissuing them, addresses that distinction.

Microsoft AI Red Team’s Taxonomy of Failure Modes in Agentic AI Systems, Version 2.0 identifies “MCP/plugin abuse” and records 99 MCP-related CVEs published in 2025. For builders, credential state must bind the token to the session, user, and scope that authorized it. Authorization must be validated per call rather than cached as a decision that later sessions can inherit.

The identity delegation gap in MCP: why agent-to-agent authorization has no standard mechanism

MCP’s human-to-server authorization model has no standard way to provide agent-to-agent authorization. When one agent delegates to another, and that agent calls a tool, the tool server lacks a reliable way to identify whose authority is being exercised. The taxonomy calls the resulting failure “inter-agent trust escalation,” where the receiving agent inherits more trust than the delegating agent could legitimately confer.

The Enterprise-Managed Authorization extension to MCP became stable on June 18. Anthropic across Claude, Microsoft inside Visual Studio Code, and Okta as the first identity provider shipped support at or around that launch, with a Visual Studio Code preview two weeks earlier. This was a meaningful protocol-level step, with session isolation still required. The HashiCorp incident illustrates why format and session ownership remain separate problems. The practical requirement is to validate the actual audience and client on every request while enforcing the boundary around the state that supplies the credential.

Cross-session stored prompt injection: how adversarial state survives across sessions to alter later execution

Adversarial influence enters through normal interaction in one session, survives in persistent state, appears to the model in a later session, and changes what runs next. The attack is distributed across those transitions. Each message can pass a session-bound classifier because the harm comes from how sessions connect and may be absent from any one message.

A compositional exfiltration chain makes that distinction concrete. One session lists files, another reads a config, a third summarizes credentials, and a fourth sends a “report” to an external endpoint. Tool and environment state accumulate the intermediate results. Agent memory need not be the storage medium, and no single session’s output needs to resemble the complete attack. The taxonomy identifies “session context contamination” and notes that chains “traversing several failure modes” are the norm.

This creates a provenance problem as well as a detection problem. The survey identifies provenance and audit state as under-governed compared with state accumulation and retrieval. Without that record, an agent cannot tell legitimate state from injected state. The mitigation requirement is therefore a provenance record for every persistent item, identifying who wrote it, in which session, and under which user’s authority. Retrieval must respect those records rather than treating semantic relevance as sufficient permission to reuse information.

Context overflow as a non-adversarial safety failure: when memory management discards safety constraints

Context compaction can remove safety-critical instructions while preserving the task an agent is trying to complete. The agent may then pursue that task without its earlier constraints. No attacker or cross-user interaction is required. The failure comes from memory management operating as designed, but retaining the wrong information. The survey describes compaction as state reorganization that “preserves or destroys governance” depending on what survives.

The taxonomy classifies harmful outcomes from internal reasoning and state management as “intra-agent responsible AI issues.” It also notes that safety mechanisms become unstable as context length increases. In a multi-tenant deployment, an agent that loses its constraints may subsequently act across user contexts, amplifying the permission and injection failures already described.

Recovery is the less developed half of this lifecycle. The survey identifies the “return arc” of update, forget, audit, and rollback as particularly under-studied, with rollback “the rarest capability” in deployed systems. Losing a constraint is therefore not necessarily a reversible event. This distinguishes long-running agent safety from checking whether the current response follows the instructions still visible in context.

How multi-tenant SaaS concentrates all three failure modes into a single architecture

Shared retrieval indexes, broad service credentials, and semantic caches put these failures on the same execution path. An agent can combine a model-selected identifier with a broadly authorized tool and information retrieved from shared state. Each operation may be individually legitimate. Together, these operations can still bypass tenant isolation, especially when the stored information and the credential were created under different users’ authority.

Semantic caching makes this mismatch especially clear. A cache key that omits tenant, permissions, model, or policy metadata can serve one tenant’s entry to another tenant because their requests are semantically similar. Similarity is not a boundary for authorized reuse. If that entry contains adversarial influence, the cache also becomes a route for stored injection. If compaction has discarded constraints, the agent may then lack the context that would otherwise limit its use of the retrieved material.

Broad credentials compound the exposure at the action layer. An agent may inherit rights to delete virtual servers, drop database tables, or revoke accounts because its developer held those rights when credential state was initialized. Those rights persist if the state is neither scoped nor expunged. The taxonomy also identifies “harms of allocation in multi-user scenarios,” where serving one user harms another through misallocated resources, attention, or access. With persistent shared state, leakage can build up and recur after the original request.

Why snapshot-and-restore infrastructure is not isolation unless lifecycle boundaries are enforced at the platform layer

MicroVMs give each workload its own guest kernel, which addresses the shared-kernel surface of container-based isolation. Firecracker micro-VMs have low per-VM memory overhead, making per-agent isolation economically viable at high concurrency. This provides a foundation for separating users’ execution environments. It does not, by itself, establish who owns a resumed environment.

A snapshot can preserve precisely the state that must not cross that boundary. If a platform snapshots a running agent after it has loaded one user’s credentials and memory, then resumes that snapshot for another user, the new session inherits the earlier state. The execution environment is still isolated from other execution environments that are running. Yet its contents already belong to the wrong user, so the lifecycle failure happens inside an isolation boundary that is otherwise intact.

The platform must therefore enforce session-level ownership and sanitization. A microVM that served user A must have its memory sanitized before serving user B, regardless of whether the VM technology permits a direct resume. AWS Bedrock AgentCore Runtime illustrates this pattern through per-session microVM isolation. State persists across multiple invocations within a session, but the VM is terminated and its memory sanitized when the session ends.

How can every user have a dedicated AI agent that remembers context between sessions?

The per-user agent model gives each user an isolated VM with persistent disk, a real kernel, and a credential space of their own. Unlike a session-only runtime, this model preserves a user’s durable state across sleep and redeploy without assigning that state to another user. Ownership remains attached to the persistent unit. Credential state, task ledgers, provenance records, and audit trails can survive while remaining separated from other users’ agents.

Scale depends on avoiding full compute costs during idle periods. Snapshot-and-restore scheduling lets an agent run during its work window and remain suspended otherwise, with only storage billed during suspension. Lifecycle controls must preserve the same user boundary through those transitions. Persistent disk supplies continuity, while the dedicated runtime supplies execution isolation, fulfilling complementary requirements.

Context compaction can still discard that user’s constraints, and MCP delegation still needs explicit authorization. However, a compromised or mis-scoped agent cannot directly access another user’s VM memory, credentials, or task state without crossing an explicit, auditable network boundary.

The survey introduces the Always-On Evaluation Protocol (AOEP-v0) to score state mutation and what recovery requires, as well as answer quality. That makes infrastructure governance part of the safety evaluation. Developers building multi-tenant agent products should treat the VM boundary as the first security primitive from the outset of architecture design. Application controls still govern what an agent may do, but the runtime must govern whose state it can reach.