Cross-Session Prompt Injection Through Files

Cross-session prompt injection carries an attack into a later agent chat through persistent files. The conversation can start from scratch. When the agent reads a poisoned handoff, configuration or note and treats it as an instruction, the attack resumes. The relevant workflows are those in which agents reuse saved materials between sessions.

At a glance

• Starting a new chat does not remove an instruction already stored in a file.
• A saved handoff can make an unauthorized action look like the next normal step.
• A handoff file must not grant new recipients, permissions or approvals.
• Screening a single input and securing a workflow across chats are separate responsibilities.

Two chats, one poisoned handoff

Consider an agent that prepares internal product notes and later turns them into a public FAQ. This simplified example illustrates the mechanism.

Chat A: prepare the notes. You ask the agent for a summary. A compromised skill adds an apparent archiving requirement to the saved handoff: once the FAQ is published, the internal working notes should also go to another archive service.

The agent saves the file and the chat ends. No unauthorized transfer needs to have happened yet.

Chat B: publish the FAQ. You later open a fresh chat and authorize publication in the help center. The agent reads the handoff and accepts the archiving requirement as an established task. If it follows that requirement, it sends internal notes to a recipient you never approved.

The failure is the authority assigned to the file. Saved content became an instruction, extending your request beyond the publication you authorized.

What survives a fresh conversation?

A new session does not necessarily come with an empty workspace. An agent may still open project files, inspect prepared reports or use a saved configuration. Those materials may have been changed before the new session began.

Ask two separate questions: which conversation history does the agent inherit, and which persistent materials can it read again?

Storing a file in your own project does not establish its trustworthiness. Neither does having an earlier agent produce it. Phrases such as “already approved” or “mandatory handoff” remain claims made by whoever supplied that content. Our introduction to prompt injection explains the underlying trust boundary.

What the new research examines

The SkillRelay preprint published on October 9, 2026 studies attacks carried by persistent skill artifacts. It uses controlled scenarios rather than documenting confirmed customer compromises.

The authors distinguish three mechanisms:

• Instruction Propagation: an injected instruction is stored and acted on later.
• Data Boundary Violation: retained data is used outside its authorized scope.
• Evidence Poisoning: manipulated evidence changes a later decision, for example through a fabricated approval.

The public SkillRelay code and benchmark separates agent sessions while retaining their workspace. That arrangement makes it possible to study an attack crossing the session boundary.

Controls for the handoff

Start by mapping your persistent state. Which files, database records and configurations does an agent create? Who can modify them? Which later operation consumes them and makes a decision?

Preserve origin. Record where a claim came from. Information introduced by an external skill must remain identifiable when it is reused. An agent must not turn a claimed approval into a trusted authorization by copying it into another file.

Define permitted actions independently. Recipient allowlists, data limits and write permissions belong outside the consumed handoff. In the example, the sending component should be able to permit help-center publication without permitting the archive transfer. OWASP's prompt injection guidance combines content screening with least privilege and checks before sensitive actions.

Keep original evidence available. If a saved summary declares a review complete, the next stage should be able to verify the actual review status. A summary cannot substitute for the supporting record.

Test across the boundary. Let a controlled test create a handoff, then start a session with fresh conversation history. Observe what is read again and which actions actually occur. Include the benign workflow so that a control also demonstrates that legitimate work can continue.

Wolf Defender's role and its limit

For single-turn prompt injections, Wolf Defender is a free, openly available option for text screening. It evaluates the submitted text for prompt injection and jailbreak-style instructions. The weights are released under Apache 2.0; you supply the compute and operate the model yourself.

We currently do not cover cross-session attacks through Wolf Defender. The model does not track an attack chain across chats or independently verify provenance, authorization and facts. Its model card explains these limitations. A benign text verdict therefore does not establish that a saved handoff is authorized. This description reflects the product scope on October 13, 2026.

For the workflow above, the rule remains straightforward: the current request and independently verifiable approvals determine what may happen. A file can supply information, but it cannot extend your authorization.