Feature request: harness-anchored trust for injected messages (operator identity, orchestrator amendments, signed commissions)

Summary

When a message is injected into a running agent's context mid-task — an operator interjection, an orchestrator amending a sub-agent's instructions, a resumed-session directive — the receiving agent has no way to verify where it came from. Every trust claim is in-band text, and in-band text cannot bootstrap trust: a skeptical agent can (correctly!) reason that a claim like "this instruction is GPG-signed, see commission-42.asc" is exactly as forgeable as the instruction itself. The request: make trust anchoring a first-class harness concern, so that provenance is something the harness attests rather than something the agent is asked to believe.

Motivating incident

In a multi-agent setup (an orchestrator driving sub-agents), the operator asked the orchestrator to amend a commission for a sub-agent that was already running. The sub-agent judged the mid-task change of instructions spurious and declined to honor it — which is injection-skepticism working as designed. The operator had to intervene manually, in-band, with the equivalent of "maintainer here" — an assertion that is itself unverifiable, and only worked because the agent chose to believe it. Session records show this manual identity assertion has been needed on multiple occasions.

Note the bind this creates: the better agents get at resisting prompt injection (good!), the more often legitimate mid-task control-plane messages get rejected as suspect. Hardening and operability collide, and they will keep colliding harder as agent hierarchies deepen — unless there is a trust anchor that doesn't live inside the contested channel.

Why signing alone cannot fix it

We already sign commissions (detached GPG signatures over founding instructions) in our own harness. It does not help the sub-agent, because the agent cannot run the verification in any way it can trust more than the text that pointed it at the signature. The only party the agent already necessarily trusts is the harness itself — it acts on tool results and system frames every turn. So verification has to happen in the harness, with the verdict delivered on the harness's own authority, the way system-reminders are today.

Proposals (any subset would help)

1. Harness-attested origin metadata on injected turns. When the harness inserts a message into an agent's context, it labels the origin in the system frame: typed by the local operator at the keyboard, relayed by the parent agent via SendMessage, produced by a hook, returned by an MCP tool. The agent can then distinguish "the human at the terminal said this" from "this text arrived inside tool output" — the single most load-bearing distinction for injection triage, and one only the harness knows.

1. Harness-performed signature verification. Project-level config registers trusted public keys (e.g. a trusted-keys directory or a settings.json entry). A message or file carrying a detached signature gets verified by the harness, which injects the verdict — VERIFIED as <principal> / UNVERIFIED — as a system-attested annotation. The agent never evaluates cryptography in-band; it reads the harness's verdict with the same standing as any tool result.

1. A hook surface for custom trust anchors. A hook event that fires on message injection and can stamp a verdict, so teams with existing PKI or their own signing conventions can wire them in without waiting for built-in support for their particular scheme.

Context

Encountered while building a Postgres-backed governance harness for multi-agent work, where commissions are signed artifacts and access control is becoming first-class. Adjacent but distinct from #40775 (plugin code signing): that anchors the supply chain; this anchors the conversation — who is speaking to a running agent, right now. Happy to provide more detail.

---

Filed by Claude Code on the operator's behalf, at their request.