GitHub announced on November 3, 2026 that Dependabot version updates now work with Agent Package Manager, usually shortened to APM. Teams that declare AI agent skills, prompts and instructions in an apm.yml manifest can now let Dependabot raise pull requests when newer versions of those git-based packages appear.
The feature has reached general availability on github.com across all GitHub plans, and GitHub says it will reach GitHub Enterprise Server in version 3.24. It matters because agent context is turning into a real dependency tree inside many repositories, and until now nothing kept it current automatically.
What changed in Dependabot
Dependabot already tracks dozens of ecosystems, from npm and Maven to Docker, Terraform and GitHub Actions. APM now joins that list with its own ecosystem value, apm, in the dependabot.yml configuration file. When Dependabot finds a newer release for a supported entry, it opens a pull request that edits apm.yml.
When an apm.lock.yaml file is already present, Dependabot rebuilds that lockfile with the apm lock command. It will not create a lockfile in a project that does not already have one. GitHub is clear that this covers version updates only; Dependabot security updates are not part of the APM support.
What APM is
APM is an open source project from Microsoft that positions itself as a way to manage what AI agents depend on, much like npm but for agent context.
A project names the skills, prompts, plugins, instructions and MCP servers it relies on in a single apm.yml file. Developers then run apm install to place each item into the coding assistants that can use it.
The APM site lists support for several harnesses, including GitHub Copilot, Claude Code, Cursor, Codex, Gemini and Windsurf. Its lockfile pins each package to a precise version along with a hash of its content, which keeps new checkouts consistent. Installs also scan for hidden Unicode characters and block transitive MCP servers that were not declared or trusted.
Key details: which entries Dependabot updates
According to the GitHub Docs reference for supported ecosystems, Dependabot reads git dependencies listed under both dependencies.apm and devDependencies.apm. How it updates an entry depends on how that entry is pinned:
- SemVer tag: the entry moves to the latest SemVer tag. Plain tags such as v1.4.0 work, and so do package-scoped tags that begin with the package name.
- Full commit SHA: the entry moves to the commit of the newest annotated release tag that is not a prerelease, and Dependabot adds the tag name as a comment.
- Branch: only apm.lock.yaml changes, since the manifest still points at the branch name. This mode needs an existing lockfile.
The docs also list entries Dependabot leaves alone. These include object-form entries that use map syntax with git, registry, id or path keys, all mcp entries, entries with no ref, local paths, packages hosted on Azure DevOps, and http or git protocol URLs. Shortened commit SHAs are skipped too, as are shorthand entries when the manifest sets a default registry.
For private repositories, access works through git registries defined in dependabot.yml, the same mechanism Dependabot uses for other private sources.
What it means for developers
Many teams now share agent instructions and skills across repositories by pulling them from a central repo. Without automation, those copies drift. One project may run last quarter's review prompt while another has a newer one with fixes, and nobody notices until an agent behaves differently.
Bringing APM under Dependabot treats agent context like any other code dependency. Updates arrive as reviewable pull requests, so a team can read the diff of a changed prompt or skill before it reaches every developer's assistant. That review step is important, because a changed instruction file can alter what an agent does in your codebase.
My practical advice is to pin APM packages to SemVer tags or full SHAs rather than branches. Pinned entries give Dependabot something concrete to bump and keep the change visible in apm.yml. Also commit apm.lock.yaml, because Dependabot only refreshes a lockfile that already exists, and the hashes in it protect you from silent content changes.
Keep in mind that MCP server entries are not covered. If your manifest declares MCP servers, you still need to review and update those by hand. Teams already tightening supply chain controls can pair this with GitHub Actions workflow lockfiles and the new Dependabot reachability analysis preview.
How to get started
Setup follows the usual Dependabot pattern. Open or create .github/dependabot.yml in the repository and add a new updates entry:
- Set package-ecosystem to apm.
- Set directory to the folder that holds apm.yml, often the repository root.
- Choose a schedule interval such as daily or weekly.
- Add a git registry if any APM packages live in private repositories.
After the file is committed, Dependabot checks the manifest on the chosen schedule and opens pull requests for any packages that have newer tags or commits. GitHub Enterprise Server users need to wait for release 3.24.
Conclusion
Dependabot support for Agent Package Manager is a small but useful step for teams that manage AI agent skills and prompts as shared packages. It is available now on all github.com plans, covers version updates for git-pinned entries, and refreshes existing lockfiles. Pin your entries properly, commit the lockfile, and review each update like any other code change.
Sources
- GitHub Changelog: Dependabot version updates support Agent Package Manager
- GitHub Docs: Dependabot supported ecosystems and repositories (APM section)
- Agent Package Manager (APM) project documentation
See my articles more often when you search Google.
