Repository navigation
Limit who can start deploy and publish workflows to the actors that actually start them #210
Description
🤖 Generated by the Agentic Engineer
Evidence
workflow-execution-actors.sh --org devantler-tech --since 2026-08-22 (run 2026-09-21) joined 30 days of run history to the 31 default-branch workflows that accept manual entry and deploy or publish. The run exited UNKNOWN: 3 rows elsewhere could not be verified (platform and ksail ci.yaml, actions enable-auto-merge.yaml). None of the three is in this set.
Actors seen starting those 31 workflows:
| Actor | ID / type | Events |
|---|---|---|
| devantler | 26203420 / User | workflow_dispatch 11, push 6, pull_request 3, schedule 2 |
| botantler-1[bot] | 185060876 / Bot | push 7 |
| github-merge-queue[bot] | 118344674 / Bot | push 4, schedule 2 |
| github-actions[bot] | 41898282 / Bot | workflow_dispatch 1 |
| dependabot[bot] | 49699333 / Bot | pull_request 1 |
7 of these workflows had no run in the window.
Audience and problem
The maintainer. Any collaborator or App with write access can start a deploy or publish workflow by hand today. #209 restricts events only, not actors.
Hypothesis
A policy that targets these workflow paths and allows only the actors above blocks unexpected starters, and does not strand a release, deployment or dependency update. Evaluate-mode insights will confirm or refute this before anything is enforced.
Acceptance criteria
- One reviewed policy file in the Record the layered workflow execution policy as reviewed desired state #208 format,
evaluatemode, targets the deploy/publish workflow paths and allows only live-resolved actor IDs. - Every actor in the table is either allowed or deliberately excluded, with the reason recorded. Workflows with no runs get their expected actor from reading the workflow.
- The 3 UNKNOWN evidence rows are resolved, or shown to be outside the targeted paths.
- How
scheduleandpushruns are attributed (to the merge queue, the pusher, or the last editor) is checked against the docs, so the policy doesn't block scheduled runs.
Rough size: S. Depends on #208.
Part of #202
Metadata
Metadata
Assignees
Labels
Type
Fields
Projects
- Status
Activity
devantler commentedon Sep 21, 2026
Carry-over from #209 (merged at b49da52): the policy validator accepts an unknown extra top-level key (measured:
.bogus_key=1→ exit 0). Required keys are all checked, so the merged policy is not weakened, but this slice should make the validator reject keys outside the documented set so a mistyped optional field cannot be silently ignored. Add it with a fixture that fails before the change.devantler commentedon Sep 21, 2026
Now unblocked: #208 is closed (#209 merged). A note for the implementing slice:
restrict_actions_actorswithallowed_actors: [{id, type}].POST /orgs/{org}/actions/policiesdescribesworkflow_pathonly as "workflow file paths or glob patterns". It does not say whether a pattern is repository-relative (.github/workflows/deploy.yaml) or owner-qualified, and gives no example. Because an organization policy can span several repositories, that choice decides whether one policy can target all 31 workflows or it needs one policy per repository.repository_nameinclude = that repository, repository-relative workflow paths). It keeps each policy unambiguous about which repository it covers. It does not settle the path format: if the API expects owner-qualified patterns, repository-relative ones would match nothing, and a policy that matches nothing blocks nothing. So confirm in evaluate mode that the insights show matches before relying on it.fix(security): reject unknown keys in workflow execution policies (#212)
chore: agent-claim #210 nonce=0e13a3516cb0d7b6a3d810092c079f9f