How to Use GitHub Actions' Three September Updates: Runner Deprecation API, Least-Privilege Tokens, Reusable Workflow Provenance

GitHub shipped three GitHub Actions updates on 2026-09-03. None is large, but each is the kind of change that saves you one incident. Here is what each one solves and how to use it.

Update 1: you can finally query when a runner version dies

The problem: Actions runner versions get deprecated on a schedule. Until now, finding out when yours stops working meant tracking announcements, reading blogs, or discovering it the morning your pipeline went red.

Now there is an API:

GET /actions/runners/deprecations/{version}

It returns runner_version, runtime_deprecates_at and registration_deprecates_at.

In plain terms: when that version stops running, and when it stops being able to register new machines. Those dates usually differ — blocking new registrations before blocking execution is standard practice — so read both.

Scope: available at the repository, organization and enterprise levels.

How to make it actually useful: do not check by hand. Schedule a weekly workflow that collects your self-hosted runner versions, queries their deprecation dates, and opens an issue or sends a notification when a date approaches. That turns upgrades into planned maintenance rather than firefighting.

Especially relevant for self-hosted runners. GitHub-hosted runners update themselves; yours do not.

Update 2: GITHUB_TOKEN gains vulnerability-alerts

The problem: a workflow that needed to read Dependabot alerts previously had to be granted a much broader scope, because no narrow permission existed. Reading one thing required the right to read many things — awkward to defend in a security review.

Now: GITHUB_TOKEN supports a vulnerability-alerts permission granting read-only access to Dependabot alerts, accepting read and none. GitHub frames it explicitly as enabling least-privilege practice.

How to use it, at workflow or job level:

permissions:
  contents: read
  vulnerability-alerts: read

Recommended move: if you run a workflow that inspects vulnerability alerts and produces a report, swap its oversized scope for this one. While you are in there, set everything else you do not need to none — once permissions is declared explicitly, anything unlisted is withheld, which is the cheapest way to tighten a pipeline.

Update 3: reusable workflows now know who called them

The problem: when a reusable workflow runs in another repository’s context, it has been hard for the workflow to tell whether it was invoked directly or as a component, and harder still to identify which file and version was used. That hurts both debugging and audit.

Four new job context properties:

What to do with them:

1. Audit trails: emit all four into logs or build artifacts so you can answer “which workflow, at which revision, produced this artifact?” months later.
2. Behavioural branching: let a workflow behave differently when run directly versus invoked as a reusable component — for example, only deploying in the former case.
3. Supply chain verification: paired with npm trusted publishing, this “who am I and where did I come from” data is exactly what publish-source verification is built on.

Limitation: GitHub notes these properties are not available on GitHub Enterprise Server. Self-hosted GHES teams will get empty values, so do not make a pipeline depend on them.

Read together: one direction

The three look scattered but point the same way: make automation predictable, auditable and least-privileged.

• Runner deprecation API = predictable (no more surprises)
• vulnerability-alerts permission = least privilege (stop handing over a keyring for one door)
• Workflow context properties = auditable (every output traceable to a source)

If you own a CI setup that has not been touched in two years, these three make a decent checkup list: schedule a deprecation check, declare permissions explicitly once, and log source provenance in your critical workflows. Roughly half a day of work, in exchange for not firefighting some future morning.

Source: GitHub Changelog, 2026-09-03, verified 2026-09-07. Follow GitHub’s documentation for exact syntax. Developer tool plans are tracked on our GitHub Copilot tool page. For the related supply-chain change, see npm’s multiple trusted publishing configurations.