GITHUB_TOKEN gains a dedicated read permission for Dependabot alerts

August 12, 2026. GitHub ships its “Early August 2026” update for GitHub Actions, marked Shipped. Tucked inside is a change that quietly matters: a vulnerability-alerts: read permission on the GITHUB_TOKEN. August 2026. The GitHub Actions security roadmap promises safer defaults and finer policy controls. The question is no longer “can you harden the CI token?” but “who still isn’t?”

The story in one sentence: for years, the automatic token in your workflows simply could not read Dependabot alerts, and teams worked around it with tokens far broader than they needed.

A known gap, half-closed

The GITHUB_TOKEN is a short-lived credential generated automatically for every workflow run. It is meant to be the least-privilege tool: you declare its permissions in the workflow’s permissions block, and it carries nothing more. That is the opposite of a PAT (personal access token), which carries a human’s identity and all of that account’s grants.

Except there was an awkward exception. The API that lists a repository’s Dependabot alerts — GET /repos/{owner}/{repo}/dependabot/alerts — required a permission the GITHUB_TOKEN could not be given. Community discussion #60612 put it bluntly: the default token will never list those alerts, because the Actions App that mints it cannot be configured to hold the Dependabot alerts read permission.

The result: any team that wanted to automate remediation — closing an alert once the fix merges, or shipping alerts to a SIEM — had to inject a PAT into the workflow. A long-lived secret carrying a human’s rights, all to read a list of vulnerabilities. That is exactly the kind of trade-off supply-chain security keeps flagging in CI/CD pipelines.

The permission that unlocks least privilege

The August 2026 update rebalances that trade-off. The GITHUB_TOKEN now accepts a granular vulnerability-alerts: read permission, giving it read access to Dependabot alerts — and nothing else.

A workflow that previously imported a PAT can now declare:

permissions:
  contents: read
  vulnerability-alerts: read

Then query the API with the built-in token, with no extra secret:

# List this repository's Dependabot alerts using the CI token
gh api repos/${{ github.repository }}/dependabot/alerts \
  --jq '.[] | {number, severity, state, package: .dependency.package.name}'

This is not cosmetic. A PAT is a static secret: if it leaks, it stays valid until manually revoked, and it opens everything the issuing account can open. The GITHUB_TOKEN, by contrast, expires when the run ends and carries only what the permissions block declares. Swapping a PAT for this permission turns a standing security debt into a short-lived, bounded right.

Two other deliveries in the same wave

The update does not stop at the permission. Two more items deserve a platform team’s attention.

• A runner-deprecation REST API. It lets you check runner version deprecation timelines before they become a problem, instead of discovering the removal the moment a pipeline breaks. For organizations running hundreds of runners, that is the difference between planning a migration and absorbing an outage.
• Four new job context properties. They let a reusable workflow learn its own source identity at runtime — which repository, branch, or calling workflow it came from. For shared workflow libraries, that is the foundation of more self-aware automation that adapts its behavior to its caller.

Taken together, the three changes trace the same trajectory: making CI/CD policy-driven and observable, rather than a pile of human secrets and ad hoc scripts.

Why least privilege starts with the token

The underlying threat has not changed in years: a compromised third-party action running in your pipeline inherits everything the token carries. If your GITHUB_TOKEN is set to write-all, one poisoned dependency can push code, read your secrets, or pivot into production environments. That is the exact vector of the supply-chain attacks documented against GitHub Actions — compromising popular actions to exfiltrate secrets.

The reflex to install is simple: in every repository, force the default permission to read-only, and only elevate rights in the permissions block of workflows that actually need them. The new vulnerability-alerts: read permission removes the last alibi for a PAT in an alert-automation pipeline.

The setting is enforced at the organization level:

# Check the organization's default permission policy
gh api orgs/${{ github.repository_owner }} --jq '.default_repository_permission'

And at the repository level, via Settings → Actions → General → Workflow permissions, choosing “Read repository contents and packages permissions”, then declaring elevations case by case.

Verdict

If you already automate Dependabot remediation, replace the PAT with the vulnerability-alerts: read permission now: it shrinks your attack surface at zero functional cost. The move is mechanical — one line in the permissions block and the secret deleted — but it removes a long-lived static credential from a pipeline.

If you do not read these alerts via API yet, the real project is not the permission, it is the policy: set default permissions to read-only, then treat every write as a decision that must be justified. The Dependabot permission is just one more notch in a chain that no longer tolerates all-powerful tokens.

References

• GitHub Actions: Early August 2026 Updates [GA] — github/roadmap #1313, August 12, 2026
• What’s coming to our GitHub Actions 2026 security roadmap — GitHub Blog
• Can’t access Dependabot alerts API via GitHub Action default token — GitHub Community #60612
• Use GITHUB_TOKEN for authentication in workflows — GitHub Docs