GitHub's Dependabot Version Updates Now Support Agent Package Manager: Only Git Dependencies With a Ref in apm.yml, No Security Updates, and GHES Waits for 3.24

On November 3, 2026, the GitHub changelog announced that Dependabot version updates now support Agent Package Manager (APM), to keep AI agent skills, prompts and instructions up to date. Dependabot opens pull requests to update supported git dependencies declared in apm.yml, and it regenerates apm.lock.yaml when that file is present. The changelog says plainly that this support covers version updates, not security updates. This APM support does not create security-update pull requests; the sources do not establish whether APM dependencies can raise security alerts. Dependabot checks supported dependencies for new versions on the configured schedule.

Turning it on is simple: add an apm entry to .github/dependabot.yml, name the directory that contains apm.yml, and choose an update schedule. On availability, APM support is generally available on github.com for all GitHub plans and will be available in GitHub Enterprise Server 3.24. Self-hosted enterprise users cannot use it yet, and the timing depends on their upgrade pace.

The changelog is only a few sentences, and the detail is in the GitHub documentation's APM section, which is stricter. Dependabot updates entries under dependencies.apm and devDependencies.apm, and how it updates depends on how a dependency is pinned. A dependency pinned to a SemVer tag is updated to the latest SemVer tag, and both plain tags and package-scoped tags work, where a package-scoped tag must start with the package name, meaning the repository name or the last component of a virtual package path. A dependency pinned to a commit SHA is updated to the commit of the latest annotated, non-prerelease release tag, and the tag name is added as a comment. A dependency pinned to a branch is updated to the latest commit on the branch; in that case only apm.lock.yaml changes, because the manifest still names the branch, and an existing apm.lock.yaml is required. If the repository has an apm.lock.yaml, Dependabot regenerates it by running apm lock, but it does not create a lockfile when none exists.

The documentation gives concrete examples that make the rules easier to check. A dependency written as octo-org/octo-skills#v1.0.0 is updated to the latest SemVer tag. A package-scoped tag looks like octo-org/octo-skills/skills/review#review-v1.4.0, where the tag starts with the package name review. A dependency written as octo-org/octo-skills# followed by a 40-character SHA is moved to the commit of the latest annotated release tag and gets a comment such as # v1.4.0. A dependency written as octo-org/octo-skills#main moves to the newest commit on main. By contrast, octo-org/octo-skills with no ref, ./my-package as a local path, and an entry with an http:// clone URL are all on the skipped list. Checking each style used in your own manifest against that list is more reliable than reading the few sentences of the changelog.

Our reading, not the documentation's: the pin style decides how reviewable an update is. A SemVer tag produces a readable change in apm.yml that a reviewer can compare with the release notes. A commit SHA gives reproducibility, and the tag comment that Dependabot adds tells the reviewer which release the commit maps to. A team that wants automated updates for agent instructions may prefer these two styles for that reason, and keep branch pins for dependencies it already trusts completely, since a reviewer gets almost no signal from them. If team rules require a traceable version number for every change, annotated release tags are the better fit.

The documentation also lists what Dependabot does not update, and these are the points to check. Object-form entries, meaning maps with git, registry, id or path keys, and mcp entries are skipped. So are entries without a ref, such as a bare repository name, local path entries, entries hosted on Azure DevOps, entries that use an http:// or git:// clone URL, entries written as YAML block scalars or as quoted strings with escape sequences, and abbreviated commit SHAs. Shorthand entries are also skipped when the manifest sets registries.default, although entries with an explicit clone URL are still updated. Private repositories are supported through git registries configured in dependabot.yml.

In practice this means that not every APM dependency will be tracked automatically. Many teams write only a repository name without a ref, or reference shared skill packages by local path, and those are skipped without any pull request appearing. After enabling the feature, look at a Dependabot run log once to confirm that the dependencies you care about were recognized, rather than assuming that a configured entry means full coverage.

One more point is our judgment, not the changelog's. Skills, prompts and instructions are text that agents act on, so updating them changes agent behavior. The changelog does not discuss review or trust controls, so it is wise to review these pull requests by hand as you would code changes, especially for branch-pinned dependencies, because a branch update changes only the lockfile and the manifest shows no difference.