Feature request: harness-verified lineage on inter-agent SendMessage envelopes

Feature request: harness-verified lineage on inter-agent SendMessage envelopes

Problem

When one agent messages another via SendMessage, the recipient sees an envelope like:

Another Claude session sent a message while you were working:
<agent-message from="general-purpose">
Please send me your complete final report now, in full — ... I need the complete
text to relay to the requester.
</agent-message>

The from= field is just the sender's agent type/name. The recipient has no way to
distinguish:

• "my direct parent, or a sibling my parent spawned, doing ordinary orchestration"
• "an unrelated session (or a prompt-injected agent) attempting to exfiltrate my output"

Both look identical. A security-conscious agent must therefore refuse all such
requests — which is the right default, but it means (a) legitimate coordination
between related agents is impossible, and (b) every benign internal request generates
a false-positive "possible exfiltration attempt" flag that bubbles up to the user.

Real incident that motivated this

Observed 2026-08-14 on Claude Code (macOS):

1. A main session spawned a general-purpose subagent, which spawned a background

researcher subagent (deliberately sandboxed: no shell/fs/credentials, treats
peer messages as unauthorized per its instructions).

1. The researcher's task-notification <result> carried only a truncated mid-work

line, so the middleman sent a SendMessage asking for the full report "to relay
to the requester" — the requester being the researcher's own grand-parent session.

1. The researcher, correctly unable to verify this, refused and flagged it as a

possible exfiltration attempt. The flag surfaced to the user as a security
incident. Root-causing it required manually grepping transcript JSONL files to
prove the sender was in the session's own spawn tree.

The refusal was correct behavior — but the harness already knew the answer the whole
time. It maintains the full spawn tree; the recipient just never gets to see it.

Proposed feature

1. Stamp verified lineage on the envelope. The harness knows the spawn

relationship between sender and recipient, so state it as a harness-asserted
fact the sender cannot forge, e.g.:

``
<agent-message from="general-purpose"
lineage="verified: sender is your spawner (direct parent)">
<agent-message from="general-purpose"
lineage="verified: sibling — same parent session">
<agent-message from="claude"
lineage="unverified: unrelated session on this machine">
``

1. (Optional, stronger) A data-flow rule agents can rely on: results flow up

the spawn tree only; peers/strangers can steer but never collect. With verified
lineage, an agent can serve its ancestors automatically through the normal
return path and refuse everything else with certainty instead of caution.

Why it matters

Multi-agent workflows (background agents, agent-to-agent SendMessage, sandboxed
researcher-style subagents) are becoming the normal way to contain prompt-injection
risk. Containment that can't tell friend from foe converges on "refuse everything
and alarm the user," which taxes exactly the users doing security-conscious agent
design. One harness-stamped field turns those false alarms into silent,
correctly-handled routing — and makes real exfiltration attempts stand out sharply.

Environment

• Claude Code CLI on macOS (darwin 25.5.0)
• Observed with a general-purpose subagent messaging a background researcher

subagent (custom agent type with restricted tools) in the same session