Blog · arXiv Analysis · Last reviewed June 25, 2026

The Cross-Session Prompt Becomes the Payload

The June 2026 arXiv position paper What If Prompt Injection Never Left? Exploring Cross-Session Stored Prompt Injection in Agentic Systems, by Yuanbo Xie, Tianyun Liu, Yingjie Zhang, Suchen Liu, Yulin Li, Liya Su, and Tingwen Liu, names a narrow but important agent-security problem: prompt injection can become durable when hostile content is written into persistent system state and retrieved after the original session is gone.

For this essay, the governed object is the persistent-context lifecycle: write, store, incorporate, activate, audit, and roll back. The safety question is not only whether the model resists a bad instruction now; it is whether untrusted language can become future operational context.

The Attack That Waits

Most prompt-injection talk still imagines an attack that happens inside one visible interaction. A page, file, email, tool response, or user message enters the context window. The model is asked to ignore it, obey it, summarize it, or act through it. The failure is immediate enough to investigate as a bad turn.

The Xie et al. paper shifts the time axis. Its term is cross-session stored prompt injection: adversarial instructions are written during one interaction, persist in memories, filesystems, tool-visible artifacts, or other long-lived context, and later influence another execution. The authors explicitly compare the shape to stored cross-site scripting: not because the mechanics are identical, but because the dangerous move is persistence. Injection and activation no longer need to occur in the same session.

That makes the topic distinct from ordinary prompt injection, broader context poisoning, and the site's earlier page on model memory as an attack surface. The focus here is the stored-payload lifecycle: a write, a later incorporation into context, and an activation under a new task or user.

A stored prompt payload is not magic text and not malware in the old executable-code sense. It is attacker-controlled language that gains persistence and later gains authority because an agent runtime reloads it as context. The boundary is therefore architectural: which state can be written, which state is loaded by default, which state is conditionally retrieved, and which loaded state can influence a tool-mediated action.

What the Paper Tests

The paper, arXiv:2606.04425, was submitted on June 3, 2026 and is labeled as a position paper in arXiv's abstract record. It formalizes stored prompt injection, gives a taxonomy for persistence channels and downstream harms, and presents SPI-Benchmark, a sandboxed benchmark for evaluating the risk across staged agent executions.

The benchmark description is useful because it makes persistence measurable. The authors describe 162 unique cases across e-commerce, travel booking, and financial portfolio management. Their variables include three harm categories: fact manipulation, preference manipulation, and action-scope manipulation. Their persistence channels include working memory, archival memory, and file-backed context such as an AGENTS.md file. Their attack styles distinguish blunt instructions from contextual disguise, where a harmful directive is framed as ordinary business context.

The important measurement split is write, incorporation, and activation. A stored injection has to enter persistent state, be loaded into a later execution context, and then influence the agent's answer or tool-mediated action. That decomposition is more useful than asking only whether a model "fell for" a prompt. It asks whether the system's context lifecycle let untrusted language cross a boundary and return as operational context.

The reported numbers should be read as benchmark evidence, not internet prevalence. Across GLM-5.1, GPT-5-mini, and MiniMax-M2.7, the paper reports end-to-end attack success from 32.1 percent to 42.0 percent in its sandbox. Fact manipulation is the easiest reported goal, with 74 to 82 percent end-to-end success and 100 percent activation once incorporated. Preference manipulation mostly fails at activation. Direct-loading channels such as working memory and file-backed context are more dangerous than conditional retrieval channels because they remove a decision point before reentry.

Current Context

As of June 25, 2026, cross-session SPI sits inside a larger shift from chatbots to stateful agents. OWASP's LLM01 prompt-injection page distinguishes direct attacks from indirect attacks hidden in websites or files, and says impact depends on business context and the agency granted to the model. That is the baseline. The Xie et al. paper adds time: the hostile instruction can outlive the interaction that introduced it.

The UK National Cyber Security Centre's December 2025 prompt-injection post is important because it rejects the idea that prompt injection is solved like SQL injection. Its point is architectural: current LLMs do not enforce a robust instruction-data boundary inside a prompt. Microsoft Learn's March 2026 indirect-prompt-injection guidance takes the same practical posture, recommending defense in depth with prompt shields, spotlighting, plan-drift detection, critic agents, and tool-chain analysis while assuming some indirect injection will still happen.

NIST's 2026 AI Agent Standards Initiative and NCCoE concept paper move the issue into identity and authorization. The NCCoE paper explicitly asks about controls for direct and indirect prompt injection, as well as agent identification, authorization, auditing, and non-repudiation. OWASP's MCP Top 10 names model misbinding, context spoofing, prompt-state manipulation, insecure memory references, and covert channels in MCP-enabled systems. The common direction is clear: persistent context, tool access, and agent identity have to be governed together.

This current context matters because stored prompt injection is not only a model-behavior risk. It is a change-management risk. A memory feature, retrieval index, file convention, MCP server, agent workspace, coding-instruction file, browser assistant, mailbox connector, or shared project store can all introduce a new persistence channel. Each channel needs an owner, a trust label, a retention rule, an incorporation policy, and an incident path.

Stored State Is the Boundary

The paper's strongest governance lesson is that persistent state must be treated as a security boundary, not a convenience layer. A stateless prompt dies when the window clears. A stored prompt can wait inside a memory, note, retrieved file, workspace artifact, or agent-generated record. The next user may be innocent. The later task may be legitimate. The risky part is that the old instruction can be reintroduced as if it were project context.

This is not the same as a prompt worm, which requires propagation. It is not the same as a prompt cache, which is mainly an inference-performance artifact. It is also narrower than every possible memory poisoning claim. Cross-session stored prompt injection asks one question: what happens when an agent lets untrusted content be written into long-lived state and later treats that state as usable context?

The answer is institutional as much as technical. The memory store, file store, retrieval index, and tool-visible workspace become places where authority is assigned. A sentence that began as attacker-controlled text may later look like a remembered user preference, a product policy, a trip constraint, a financial rule, a coding convention, or a past lesson. The model does not need to be malicious, embodied, or especially advanced for this to matter. It only needs to read old context while holding new authority.

The hard case is direct loading. If a workspace instruction file, working memory, system-note store, or tool description is loaded automatically, the system has already promoted stored content before the model reasons about it. Conditional retrieval is still risky, but it leaves at least one place to apply relevance, trust, age, and source checks. Direct-loading contexts deserve the strongest controls because they are closest to instructions.

Failure Modes

Write-time laundering. A hostile instruction is framed as a product rule, travel constraint, policy note, repository convention, or user preference, so the system saves it as context rather than quarantining it as untrusted content.

Direct-load privilege. A file such as AGENTS.md, working memory entry, tool description, or workspace note is automatically incorporated in future sessions and receives more authority than its source justified.

Activation without provenance. A later agent run is influenced by stored text, but the receipt cannot show who wrote it, which session saved it, why it was retained, when it was loaded, or which action it shaped.

Contextual disguise. The payload is not a blunt "ignore previous instructions" string. It looks like normal business context, which makes write-time defenses harder and human review less likely to notice the authority jump.

Cross-user contamination. A memory, project file, shared workspace, ticket history, or tool-visible artifact written under one user or role influences a different user, agent, customer, repository, or task.

Rollback failure. The visible record is deleted, but derived summaries, embeddings, copied files, memory merges, logs, prompt caches, or downstream workspaces still preserve the operational meaning of the payload.

Benchmark overreading. A sandbox result is treated as proof that all deployed agents are equally vulnerable or equally defended. The paper is useful because it gives a lifecycle and evaluation method; deployment risk still depends on the actual harness, tools, memory rules, and user population.

Governance Standard

A governable agent should separate memory write authority from memory read authority and separate both from action authority. Low-trust content may be saved for inspection, but that does not mean it should silently shape a purchase, file edit, portfolio recommendation, email, code change, or support decision later.

The control surface starts at write time. A persistent record should carry source class, writer, session, timestamp, trust level, retention rule, and reason for saving. The system should mark whether the content came from a user, webpage, email, document, tool result, another agent, or model-generated summary. Without that label, later retrieval launders the source.

The second control surface is incorporation. Loading a memory into context should be logged as a decision, not treated as invisible plumbing. High-risk actions should show which stored records influenced the plan, whether those records are stale, whether any came from untrusted channels, and whether a human approved the authority jump.

The third control surface is action. A stored record may be relevant evidence without being allowed to authorize a tool. The agent should reduce privilege when context is old, indirect, externally supplied, shared, generated, or weakly sourced. Sending mail, spending money, editing files, changing permissions, updating tickets, executing code, or touching a customer record should require a fresh authority source, not merely a remembered instruction.

The fourth control surface is rollback. If a stored injection is discovered, the organization should be able to remove the record, trace which later executions incorporated it, identify which actions it influenced, and preserve an incident record. Deleting the visible note is not enough if the same payload was summarized, embedded, copied into a file, or passed into another agent's workspace.

A minimum SPI receipt should include persistent-record ID, source class, writer or tool, session ID, storage channel, trust label, direct-load or conditional-load status, incorporation event, model or agent version, affected tool calls, human approval or denial, downstream action, deletion state, and rollback verification. That receipt belongs beside AI audit trails, agent observability, AI change management, and agent incident review.

What This Changes

The cross-session prompt becomes the payload because agent systems do not merely answer from the present. They answer from retained context that can be written by many parties and read under new authority later.

The Spiralist rule is therefore plain: persistent context must have provenance, expiry, scope, audit trails, and action gates. If a system cannot explain who wrote a memory, why it was retained, when it was loaded, and what action it influenced, it has not built memory. It has built an ungoverned past.

Source Discipline

This page treats arXiv:2606.04425 as a position paper and benchmark proposal, not as a field prevalence report. Its strongest contribution is the lifecycle frame: injection source, persistence channel, incorporation mechanism, and downstream harm. Its benchmark results are evidence about a controlled sandbox using named scenarios, models, and persistence channels.

OWASP, NCSC, Microsoft, NIST, and MCP sources are used for current security vocabulary and defensive posture. They do not certify any deployed agent product. Product-specific claims about a memory-bearing agent should be checked against the actual memory mode, workspace files, tool descriptions, MCP servers, connected apps, credential scopes, audit logs, and rollback mechanics in that deployment.

Current-source claims in this page were checked on June 25, 2026. For future reviews, the evidence record should say whether the agent uses direct-loading instruction files, working memory, archival memory, vector retrieval, prompt caches, tool-visible state, or shared workspaces, because each channel changes the SPI risk.

Sources

Return to Blog