Why it mattersThe personal access tokens teams have been storing as Dependabot secrets to reach their own private registries can come out, which removes a long-lived credential tied to one engineer's account from the update path.
GitHub said on 8 September that Dependabot can now read from private GitHub Packages registries without a personal access token. In its own words: "If a package has granted your repository access through 'Manage Actions access' in the package settings, Dependabot reuses that grant."
What actually changes
Dependabot's GITHUB_TOKEN can now request the packages: read scope, and Dependabot jobs send that token when pulling from *.pkg.github.com and ghcr.io. The change covers every GitHub Packages ecosystem that Dependabot supports, and the workflow token replaces the personal access token teams were storing as a Dependabot secret to reach their own private registries.
To turn it on, open each package's settings, and under "Manage Actions access" grant read access to the repository that runs Dependabot. GitHub says no changes are needed to dependabot.yml, and any PAT-based registry entries added for these packages can be removed.
Why this is the second try
The feature first shipped on 23 June 2026 and was pulled shortly after. GitHub says a conflict caused some npm update jobs to resolve public packages through GitHub Packages, which is not what any of those jobs asked for. The re-enabled version keeps the automatic credentials as fallback authentication only, so explicit registry credentials in dependabot.yml and the normal registry routing continue to take precedence. In practice that means a team that has already told Dependabot which registry to use for a given ecosystem sees no behaviour change from this rollout, and the new path only kicks in when nothing else answers.
What comes out of your secrets store
The credential that comes out is the class of PAT that reads a person's private packages, held under DEPENDABOT_PAT or a similar name at the repository or organization level, and refreshed by hand whenever it expires. That token is scoped to a user account, so it grants whatever that user can see across the organization, and it survives the user leaving. Replacing it with a per-job workflow token that carries only packages: read cuts the blast radius of a leaked Dependabot secret and removes one recurring rotation task.
The narrower point is that Dependabot's authentication for GitHub-hosted registries now matches the authentication used by ordinary Actions workflows. A repository that a package has already granted through "Manage Actions access" needs nothing else, which is the state most private-package setups are already in for their own CI. The wider point is that Dependabot no longer needs a separate identity to do the same read against the same package.
Access to registries outside GitHub, such as private npm registries hosted at npmjs.com or a self-hosted Nexus, is unaffected. Those still need credentials declared in dependabot.yml and stored as Dependabot secrets in the normal way.
Source
- Automatic Dependabot access to GitHub-hosted registries, GitHub Changelog, 8 September 2026
Source: GitHub Changelog
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually shipping with them. Short, and only when there is something worth reading.

