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

Summary

## 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.