GitHub Dependabot Adds APM Version Updates for AI Agent Dependencies

What changed​

Dependabot can update git dependencies declared in apm.yml manifest files for APM. GitHub's changelog dated November 3, 2026 adds that Dependabot opens pull requests for those updates. It also regenerates apm.lock.yaml when that file is present. The scope is version updates only. Dependabot security updates for APM are not part of this release.

On availability, the changelog says APM support is generally available on github.com for all GitHub plans. It is slated to arrive in GitHub Enterprise Server 3.24. Server administrators on earlier releases should not expect it.

The Dependabot documentation backs up the security caveat. The supported-ecosystems reference describes a related situation for pnpm: version updates still work, but alerts and security updates are not created for those dependencies. The APM entry is a separate case, but the lesson is the same. Version-update coverage and vulnerability coverage are separate features, so check each one.

Why it matters​

APM treats agent context the way npm or pip treats libraries. GitHub's Dependabot contribution describes APM as a git-based package manager for AI agent context, including skills, prompts, chat modes and instructions. Microsoft's APM repository describes apm.yml as the manifest. It lists instructions, skills, prompts, agents, hooks, plugins and MCP servers as things the manifest can describe. apm.lock.yaml pins the resolved tree.

Pinned agent context goes stale like any other dependency. A skill pinned to v1.0.0 stays there until someone remembers to bump it. Dependabot automates that reminder and puts the change in a pull request that can be reviewed.

Agent prompts also behave like executable input. Microsoft's own APM documentation says a prompt is effectively a program for an LLM. That makes review of an automated bump more than a formality. Treat each Dependabot pull request that touches agent skills as a code change.

How to turn it on​

1. Make sure the repository has an apm.yml manifest.
2. Create or edit .github/dependabot.yml on the default branch. The file requires the top-level keys version and updates, and it must start with version: 2.
3. Add an apm entry, point it at the directory holding apm.yml, and set a schedule.

A minimal configuration looks like this:

version: 2
updates:
  - package-ecosystem: "apm"
    directory: "/"
    schedule:
      interval: "weekly"

Documented intervals include daily, weekly, monthly, quarterly, semiannually, yearly or cron. Weekly is only an example. Use / for a manifest in the repository root, or name the subdirectory if it lives elsewhere.

How Dependabot treats each pin​

The behavior depends on how a dependency is pinned. Entries under both dependencies.apm and devDependencies.apm are covered.

A package-scoped tag must start with the package name, which is the repository name or the last component of a virtual package path. An example is octo-org/octo-skills/skills/review#review-v1.4.0.

Branch pins need a lockfile. Only apm.lock.yaml changes, because the manifest still names the branch, and the behavior requires an existing apm.lock.yaml file. If your repository tracks #main and has no lockfile, Dependabot has nothing to update.

The lockfile rule​

If your repository contains an apm.lock.yaml, Dependabot regenerates it by running apm lock. The GitHub documentation also states that Dependabot does not create a lockfile when one is missing. Commit the lockfile if you want reproducible installs and lock changes in the same pull request.

What Dependabot will not touch​

The documentation lists several entry types that are skipped:

• Object-form entries (git:, registry:, id: or path: maps) and mcp: entries.
• Entries with no ref, such as a bare octo-org/octo-skills.
• Local path entries such as ./my-package.
• Entries hosted on Azure DevOps.
• Entries using an http:// or git:// clone URL.
• Entries written as YAML block scalars, or as quoted strings with escape sequences.
• Abbreviated commit SHAs.
• Shorthand entries when the manifest sets registries.default. Entries with an explicit clone URL are still updated in that case.

The mcp: exclusion is easy to miss. APM can declare MCP servers, but Dependabot's APM updates do not cover them. Those entries will need a manual process.

Private repositories are handled through git registries. You configure access by specifying a git registry in dependabot.yml. The ecosystem table lists private registry support as git only.

Practical advice​

• Audit your pins. Unpinned or abbreviated-SHA entries are silently skipped, so a quiet Dependabot may mean exclusion rather than currency.
• Commit apm.lock.yaml. Without it, branch-pinned dependencies are not updated and lock regeneration does not happen.
• Keep a separate security process. This release does not add Dependabot security updates for APM. Review sources and content before merging.
• Check your GHES version. Server customers need 3.24 before this works on-premises.
• Pick a sensible cadence. A slower interval keeps pull request noise down for prompt libraries that change frequently.

Bottom line​

This is an incremental but useful step in treating agent configuration as supply-chain material. It automates routine bumps for supported git-based APM dependencies. It does not add security alerts, MCP coverage or support for every manifest form. The limits above decide whether it helps your repository.