#3512 typed-secrets 0.4: characterize worker secret authorization and control-plane secret traffic

Outcome

Characterization tests, with no behavior change, that document how a worker is authorized to read secrets today and where secret plaintext travels between serve, the worker supervisor and the runner. Phase 5 replaces this path with dispatch-bound handles and a protected data plane; it cannot be designed or reviewed against an undocumented baseline.

Why now

Design doc Phase 0 requires characterizing the post-resolution allowlist, remote readResource and control and data-plane secret traffic before any of it changes, and says any legacy repair ships with its own regression and release notes. Doing it first also separates the Phase 5 protocol work from any fix that turns out to be needed today.

Scope

In-process integration tests in integration/ using the serve, gateway and worker components on port-0 mock transports with fake vault providers, one named test per path:

• Allowlist derivation: allowedSecrets comes from vault reference extraction over post-resolution arguments; an empty allowlist denies every resolveSecret unless dynamic references were detected.
• Remote readResource: how the server authorizes the read, what the resource-schema fallback does for untagged legacy records, and what happens with a malformed sensitive-fields tag.
• The resolveSecret control-RPC relay: the request and reply pass through supervisor and runner stdio; record what each hop logs.
• Dispatch payload contents: the typed and untyped fields carried over the WebSocket dispatch and the runner bootstrap stdin frame, including globalArgs, methodArgs, secretValues and secretBag.
• Per-dispatch credential: issuance, the sliding TTL, and behavior after completion, revocation and reassignment; the off-loopback TLS and auth requirement.
• Output protection: what reaches the step lease from the worker result error, what the runner stderr debug log contains, whether serve registers resolved values with the redactor, and which file-writer data-plane routes have a redactor.

Each path gets a one-line classification in the PR description: expected by design, or a disclosure. The PR also records REMOTE_PROTOCOL_VERSION 4 and the exact-match rule at enrollment as the baseline Phase 5 revises.

Out of scope

• Fixing anything found. A disclosure is filed as its own security issue and must not be linked to this feature issue.
• The protocol revision, handles, the reveal endpoint and per-attempt re-rendering. Those are typed-secrets 5.1 to 5.6.

Acceptance

• All six paths have passing characterization tests that would fail if the current behavior changed.
• Every disclosure found has a filed security issue referenced from the PR before this issue closes.
• No production code changes in the PR.
• verify-build, verify-reviews and verify-skills pass at the reviewed commit.

References

• Design doc Sections 7.1, 9 and Phase 0, landed by swamp-club#3509.
• design/enablers/remote-execution.md for the current protocol description.