Adopt workflow execution protections across the portfolio

[devantler]

🤖 Generated by the Agentic Engineer

Objective

Adopt GitHub Actions workflow execution protections across every active portfolio repository so only approved actors and events can start each workflow, with stricter policy for deployment and manual-entry workflows.

Context

GitHub made workflow execution protections generally available on 2026-09-17. Policies can restrict actors and events, target specific workflow paths, expose enforcement insights, and be managed through REST at repository, organization, or enterprise scope.

Current verified evidence:

• The monorepo has no pull_request_target workflow.
• Its three workflow_dispatch entry points are audit-docs.yaml, publish-pages.yaml, and todos.yaml.
• The monorepo repository-level Actions policy inventory is empty.
• Organization-level policy inventory is currently QUERY-UNKNOWN because the routine credential lacks admin:org; no absence is inferred.
• GitHub will enforce its default public-repository pull_request_target restriction on 2026-11-02 for affected repositories.

References:

• https://github.blog/changelog/2026-09-17-workflow-execution-protections-in-github-actions-generally-available/
• https://docs.github.com/en/actions/concepts/about-actions-policies
• https://docs.github.com/en/actions/how-tos/administer/control-workflow-execution
• https://docs.github.com/en/rest/actions/policies

Desired state

Every workflow is covered by a deliberate layered policy. Broad CI remains usable by the contributors and automation that need it; deployment, publication, workflow_dispatch, and repository_dispatch workflows are limited to explicitly approved identities and events. pull_request_target is prohibited by default and permitted only for a reviewed workflow-path exception with a documented threat model.

Acceptance criteria

• Inventory every active, non-archived portfolio repository, workflow path, trigger event, required caller, and current policy inherited from repository/organization/enterprise scope.
• Resolve every required actor to its live GitHub actor type and ID, including trusted humans, repository roles, Dependabot, Renovate, suite-owned Apps/bots, and reusable-workflow callers.
• Classify workflows by exposure: ordinary CI, required reusable workflow, scheduled maintenance, manual/repository dispatch, publication, deployment, and privileged administration.
• Define layered actor/event policies rather than one account-wide allowlist.
• Prohibit pull_request_target by default; document and independently review any workflow-path exception before enforcement.
• Apply workflow-path targeting to deployment, publication, privileged administration, and manual-entry workflows.
• Preserve required pull_request, push, merge_group, schedule, workflow_call, workflow_dispatch, and repository_dispatch events only where the inventory proves they are needed.
• Use Evaluate mode and policy insights where the plan supports it; otherwise stage enforcement through a representative low-risk repository before portfolio rollout.
• Exercise positive controls for every required actor/event pair and safe negative controls through policy insights or a dedicated test repository.
• Verify no required checks, releases, deployments, dependency updates, or scheduled workflows are stranded.
• Manage policies through the reviewed declarative path when supported, otherwise use the versioned REST API and record the remaining GitOps gap under Adopt remaining rulesets declaratively as provider-upjet-github gains support (10 org rulesets + push + Actions policies) #69.
• Read back policy source, enforcement mode, target repositories, workflow paths, actor IDs, and events after every mutation.
• Add drift coverage so deletion, broadening, or actor/event omission is detected.
• Document staged rollback and the 2026-11-02 pull_request_target enforcement deadline.

Dependencies

• Parent epic: Adopt remaining rulesets declaratively as provider-upjet-github gains support (10 org rulesets + push + Actions policies) #69
• Requires organization-administration access to inventory and manage inherited policies.
• Final actor allowlists and enforcement activation require maintainer approval.
• Provider support may lag the REST surface; that must not be misreported as declarative enforcement.

Notes

Do not infer trust from a provider name or repository write access. GitHub features may be exempt for built-in processes, but custom workflows triggered by their identities still require the relevant actor to be allowed.

[devantler]

🤖 Generated by the Agentic Engineer

First inventory, 2026-09-19 ~17:30Z

Ran the read-only inventory from #203 across all 23 active repositories. It exited cleanly, with no unreadable repositories or workflows.

What	Count
Workflows	142
Can be started by hand or from another repository (workflow_dispatch / repository_dispatch)	85
Publish, release or deploy (by name; confirm each by reading it)	42, of which 26 can also be started by hand
Reusable (workflow_call)	18
Scheduled	26
Plain CI only	28
Use pull_request_target or workflow_run	0
Repositories with any execution policy today	0 of 23

Findings that shape the policy design:

• No workflow uses a privileged trigger. A code search agrees: the only pull_request_target match is an if: condition in actions/dependency-review.yaml, not a trigger. So the "prohibit pull_request_target by default" rule can start in enforce mode without breaking anything, and it needs no exceptions today.
• Manual entry is the big surface. 60% of workflows accept workflow_dispatch, including 26 release or deploy workflows. Restricting who can dispatch those is the most valuable first rule.
• Nothing is protected yet. Every repository reports zero policies, so each rule we add is purely additive.

Next slice: resolve the live actor identities each workflow needs (people, Dependabot, Renovate, our Apps). Then draft layered policies in Evaluate mode. Organization-scope policies still need an admin:org read, which this run cannot do.

[devantler]

🤖 Generated by the Agentic Engineer

Live default-branch inventory — 2026-09-20

Ran the repository's fail-closed scripts/workflow-execution-inventory.sh --org devantler-tech against the live organization. Its repository-list completeness check passed, every default-branch workflow document parsed, and the run exited successfully.

• 23 active organization repositories yielded default-branch workflows. Archived repositories were excluded by the inventory.
• Every observed repository-level workflow-execution policy count was 0.
• No workflow was classified privileged-trigger: no default-branch workflow currently uses pull_request_target or workflow_run.
• Manual-entry workflows are widespread, including deployment, recovery, publication, maintenance, and test entry points, so a single organization-wide actor/event allowlist would be too coarse.

This closes no acceptance criterion by itself. Repository-level zero does not prove that organization- or enterprise-level inherited policy is absent, and the routine credential still cannot read that scope. The inherited-policy join therefore remains QUERY-UNKNOWN; no policy mutation or enforcement recommendation was made from this partial view.