OpenClaw inter-session prompts could be treated as direct user instructions

Summary

Inter-session messages sent via sessions_send could be interpreted as direct end-user instructions because they were persisted as role: "user" without provenance metadata.

Affected Packages / Versions

• Package: openclaw (npm)
• Affected versions: <= 2026.2.12 (i.e. < 2026.2.13)
• Fixed in: 2026.2.13 (patched versions >= 2026.2.13)

Impact

A delegated or internal session could inject instructions into another session that appeared equivalent to externally-originated user input.

This is an instruction-provenance confusion issue (confused-deputy style), which can lead to unintended privileged behavior in workflows that trust role: "user" as a sole authority signal.

Technical details

Before the fix, routed inter-session prompts were stored as regular user turns without a verifiable source marker.

As a result, downstream workers and transcript readers could not distinguish:

• External user input
• Internal inter-session routed input

Fix

OpenClaw now carries explicit input provenance end-to-end for routed prompts.

Key changes:

• Added structured provenance model (inputProvenance) with kind values including inter_session.
• sessions_send and agent-to-agent steps now set inter-session provenance when invoking target runs.
• Provenance is persisted on user messages as message.provenance.kind = "inter_session" (role remains user for provider compatibility).
• Transcript readers and memory helpers were updated to respect provenance and avoid treating inter-session prompts as external user-originated input.
• Runtime context rebuilding now annotates inter-session turns with an explicit in-memory marker ([Inter-session message]) for clearer model-side disambiguation.
• Regression tests were added for transcript parsing, session tools flow, runner sanitization, and memory hook behavior.

Fix Commit(s)

• 85409e401b6586f83954cb53552395d7aab04797

Workarounds

If immediate upgrade is not possible:

• Disable or restrict sessions_send in affected environments.
• Do not use role alone as an authority boundary; require provenance-aware checks in orchestration logic.

Credit

Reported by @anbecker.

Thanks @anbecker for reporting.