workflow_dispatch on the deploy workflows runs an arbitrary ref with the CM deployment credentials

[dawsontoth]

workflow_dispatch lets the caller choose the ref. So Deploy to Dev / Stage / Prod can be run against an arbitrary branch, and that branch's own workflow and action YAML executes — with the job's GITHUB_TOKEN and, more importantly, with CLI_TARGET_USERNAME, HARPERDB_CLI_TARGET_PASSWORD, CLI_DEPLOY_TARGET and the Datadog key.

Why this is a smaller problem than #1649, and why it is still a problem

Triggering a dispatch requires repository write access, so the GITHUB_TOKEN grants nothing its holder does not already have. That is the whole reason it was not folded into #1649, where the event (merge_group) is reachable via an approved fork PR from someone with no write access.

What remains is a privilege bridge rather than an escalation: repository write access reaches the CM deployment credentials, which are otherwise not in the repo. Anyone who can push a branch can dispatch a deploy workflow against it and read those secrets out of a step they added. The current controls are that write access is already trusted, and that Actions runs are visible in the run log — not that the secrets are out of reach.

Options, roughly in increasing order of disruption

• Assert the ref in the job. Fail fast unless github.ref is the environment's own branch. Cheap, and it means a dispatch against a feature branch cannot deploy — but it is expressed in the dispatched ref's own YAML, so it is regression detection rather than enforcement, exactly like the test in Merge-queue runs of Deploy to Stage carry a write-scoped GITHUB_TOKEN reachable from candidate-controlled workflow YAML #1649.
• GitHub Environments with deployment branch policies. Put the CM secrets on an environment (dev/stage/prod) restricted to that branch. This is enforcement: the platform refuses to hand the secrets to a run on a non-matching ref, and it cannot be overridden from the dispatched YAML. Needs the secrets moved from repo scope to environment scope.
• repository_dispatch instead, which always runs the default branch's workflow definition. Removes arbitrary-ref execution entirely but loses the Run-workflow button, so operators need another entry point.

The middle option looks like the right end state: it keeps the button, and it is the only one that holds even when the dispatched YAML is hostile.

Provenance

Raised by the cross-model planning review while designing #1649, which wanted it fixed in the same change. Declined there on the fact above — it is a different exposure with a different trust boundary, and bundling a deployment-authorization redesign into a trigger deletion is how the parent PR (#1647) reached twelve review rounds. Filed instead of dropped.

Related: #1649 (merge-queue token, fixed), and the org-level workflow-execution protections noted there — an org-admin setting that would constrain event execution outside candidate-controlled code.