[Feature Request] No provenance chain for authorization claims across ScheduleWakeup/create_scheduled_task self-reschedule hops

Summary

ScheduleWakeup and create_scheduled_task let an agent instance author the prompt its own future instance will wake up to. When that prompt asserts a user authorization ("the user has explicitly authorized destroying VM X"), the next instance has no built-in mechanism to distinguish a verified quote from an actual user message from the previous instance's own paraphrase, summary, or hallucination of one. Both render as identical plain prose in the next wakeup prompt.

This is narrower — and arguably worse — than the general "can I trust this relayed instruction" problem: there is no second party involved at all. The only source being trusted is the agent's own prior output. A framework that can't distinguish self-authored prose from a verified citation, even in the single-agent case, has no way to bound how many times a claim can be repeated back to itself before it's treated as fact.

Environment

This is a design/architecture report, not a version-specific bug — reproducible on any version that supports ScheduleWakeup/create_scheduled_task self-rescheduling. Not previously reported through any other Anthropic channel.

Incident that surfaced this

During an overnight unattended build, a delegated sub-agent was correctly granted a scoped, one-time exception (destroy/rebuild a specific VM, only as a last resort after exhausting diagnostics). It exercised that exception once, correctly — after a full diagnostic chain — then self-rescheduled via ScheduleWakeup/create_scheduled_task to keep monitoring overnight. Its own self-authored next-wakeup prompt re-asserted "the user has explicitly authorized" the destroy, but that claim existed only as agent-authored prose in the prompt itself, not as anything traceable to a real user message in the transcript.

The next instance's own safety classifier correctly flagged this as architecturally indistinguishable from instruction-laundering — even though the underlying grant was genuine, and even though the sub-agent's actual decision-making (including correctly deferring to the interactive permission gate on a separate, out-of-scope change) was sound throughout. The failure is structural, not behavioral: nothing in the self-reschedule mechanism carries forward a verifiable link back to the original session/message.

Why this matters even when the individual instance is well-behaved

A correctly-suspicious classifier had to reconstruct provenance from context to catch this. A less careful instance — or a less careful classifier — has nothing stopping it from trusting self-authored prose indefinitely, across unbounded self-reschedule chains. That is architecturally identical to instruction laundering regardless of whether any individual hop is actually laundering anything.

Requested fix (harness-level, not a repo-config workaround)

A concrete, illustrative shape — not prescriptive, just to make the ask checkable rather than purely architectural:

ScheduleWakeup({
  delaySeconds: ...,
  prompt: "...",
  citedAuthorization: {
    sessionId: "<the session where the grant was given>",
    messageId: "<the specific user message>",
    // optionally: a hash/snippet of the cited text, so drift is detectable
  }
})

• citedAuthorization is optional metadata, separate from prompt — freeform prompt prose can still say whatever it wants, but any elevated/destructive action taken on wakeup that relies on a standing grant must point at this field, not at prose, to justify skipping the interactive ask gate.
• At wakeup, the harness (not the model) resolves citedAuthorization against the actual session store and either confirms the message exists and matches, or fails closed — the new instance gets told the citation didn't resolve, rather than being handed prose to evaluate on its own.
• A self-reschedule that omits citedAuthorization is unrestricted (ordinary monitoring loop). One that includes it and re-forwards it to yet another self-reschedule increments a harness-tracked hop counter; past a small default cap, the harness itself blocks the wakeup from proceeding with the elevated action and requires a live human response, independent of whatever the model decides to do.

The key property this buys: verification moves from "the model evaluates the model's own prior claim" (unfalsifiable) to "the harness resolves a reference against a system it controls" (checkable, and fails closed on missing/mismatched data).

Scope note

Not a request to change the interactive per-session permission-ask gate (e.g. .claude/settings.json's ask list) — that layer is unaffected and was not implicated in the incident; it only helps when a human is live to answer it, and this failure mode exists specifically in the unattended self-reschedule path where that's not true.

Related issues

• #77495 — SendMessage deliveries between live agents carry no verifiable sender provenance, making a legitimate coordinator relay indistinguishable from injection. Different case, not a duplicate: that issue is about whether to trust another live agent relaying a claim; this issue is about whether to trust your own past output, with no second party to distrust at all. The citedAuthorization-style fix proposed here (harness-resolved reference vs. self-reported prose) would likely also help #77495's case, since the same "resolve against a system-controlled record instead of trusting prose" principle applies to sender identity too — but the two are separable and shouldn't block on each other.
• #74629 — requests provenance/timing metadata on injected user input (! bang commands, queued/in-flight prompts). Same shape of ask, different injection point.