Dependabot Updates Agent Skills, Not Security Alerts

Agent context just became a dependency

The shift underneath this changelog entry is worth naming first. A coding agent's behavior is no longer set only by the model and a chat window. It is set by files a project installs: skills that teach it a workflow, prompts and instructions it loads every session, plugins, and MCP servers that hand it tools. APM exists to manage exactly those files. APM's manifest declares agent-context dependencies and their references, while its lockfile records resolved dependencies and content hashes. That gives teams a more explicit record of the material being installed, although a hash establishes content identity rather than trustworthiness. Its install step deploys each item to whichever of the nine supported harnesses a developer actually runs.

Once instructions are packages, they inherit the package problem. They go stale. They change upstream. A skill you installed in September may have been rewritten twice by November, and without a manifest and a lockfile there is no record of which version your agent has been following. Dependabot's arrival is GitHub treating that problem the way it has treated npm and Maven for years: watch the manifest, and when a newer version exists, propose the change as a pull request a human can read.

That framing is correct, and for teams using APM it is immediately practical. A dependency-version change arriving as a scheduled pull request is easier to review than an agent silently picking up an upstream change. Dependabot makes the manifest and lockfile changes visible. Reviewing the actual behavioral change may still require inspecting the upstream package contents. ALFW has covered the other side of that pattern this month, in Postman's auto-installed agent plugins: context that changes without a review step is context nobody approved.

What the support actually covers

Start with the sentence GitHub put in its own announcement: "This support covers version updates, not security updates." Dependabot has two jobs in most ecosystems. Version updates keep dependencies current. Security updates respond when a dependency is found to be vulnerable, raising a targeted pull request to a fixed version. For APM, only the first job exists. If an APM dependency is later found to be malicious or compromised, this integration does not provide Dependabot security alerts or vulnerability-triggered security-update pull requests for it. A scheduled version-update PR may still offer a newer release, but that is not the same as identifying a vulnerability or recommending a verified fix.

The coverage inside version updates is also narrower than the headline suggests. According to GitHub's documentation, Dependabot examines supported Git dependencies under dependencies.apm and devDependencies.apm. For SemVer-tagged entries, it selects newer eligible SemVer tags under the documented update rules. For entries pinned to a full commit SHA, it resolves the newest eligible annotated, non-prerelease release tag and updates the SHA, noting the tag in a comment. For branch-pinned entries, it updates only the existing lockfile. These behaviors do not extend to the excluded manifest forms or mcp entries.

Then the exclusions. GitHub's documentation lists several forms Dependabot leaves alone: object-form entries using git, registry, id or path keys; entries with no ref; local paths; packages hosted on Azure DevOps; entries using HTTP or Git protocol URLs; entries written as YAML block scalars or quoted strings containing escape sequences; and abbreviated commit SHAs. Every mcp entry is excluded as well. That last exclusion deserves emphasis. In an APM manifest, MCP entries describe tool connections that may give agents access to external services and data. Dependabot's APM version-update integration does not update them.

None of this is hidden. GitHub published the limit in the announcement itself and the exclusions in its docs, which is more candor than most launch posts manage. But the practical shape is easy to misread from the headline alone, because "Dependabot support" sounds like the full Dependabot. For APM it is roughly half of it: the half that keeps things current, not the half that warns you.

The protections that are not Dependabot's

APM documents several install-time safeguards separate from Dependabot. According to Microsoft's APM site, installation scans for hidden Unicode, records content hashes and restricts transitive MCP servers unless explicitly declared or trusted. Its apm-policy.yml mechanism is designed to enforce policies at installation, with restrictions that can tighten from enterprise to organization to repository level. These are documented APM controls, not security capabilities introduced by GitHub's Dependabot integration. Their effectiveness against malicious agent instructions is not established by this announcement.

The gap sits between the two systems. An update pull request from Dependabot tells you a dependency has a newer version and rebuilds the lockfile to match. Reviewing that pull request should include examining the upstream skill, prompt or instruction changes, not merely approving a manifest version bump and regenerated lockfile: a different question from checking a library's changelog, and a newer habit for most teams. The tooling now delivers those diffs on a schedule. It does not assess whether an upstream instruction change is safe. GitHub's announcement explicitly excludes APM security updates; it does not claim that the version-update process performs a security review.

For Enterprise Server shops there is also a wait. The feature is live on github.com for every plan, but self-hosted instances get it in GitHub Enterprise Server 3.24, for which GitHub gave no date in the announcement. As of 8 November 2026, the supported route to current agent skills is the hosted one.

Sources

[1] GitHub Changelog, "Dependabot version updates support Agent Package Manager", 3 November 2026 (the feature, the pull-request and lockfile behavior, the "version updates, not security updates" limit, the dependabot.yml setup, and the github.com / Enterprise Server 3.24 availability)Read source
[2] APM, Agent Package Manager official site, Microsoft (what apm.yml declares, the nine target harnesses, lockfile hash pinning, hidden-Unicode scanning, transitive-MCP blocking, apm-policy.yml governance, MIT license)Read source
[3] GitHub Docs, "Dependabot supported ecosystems and repositories", APM section (dependencies.apm and devDependencies.apm scope; SemVer, SHA and branch update behavior; the excluded entry forms, including all mcp entries; read first-hand)Read source
[4] Andrew Nesbitt, "This Week in Package Management: 7 November 2026" (the apm ecosystem added in Dependabot Core 0.400.0)Read source
[5] Plexicus, "Dependabot APM updates: review agent skills", updated 6 November 2026 (secondary confirmation of the 3 November announcement, the all-plans availability and the version-updates-only limit)Read source

THE ALFW VERDICT

Dependabot's APM integration makes agent-context dependencies easier to maintain through scheduled, reviewable version-update pull requests. It can update supported manifest references and regenerate an existing lockfile, giving teams a clearer record of changes to the skills, prompts and instructions their agents use. That is version hygiene, not a security review. GitHub explicitly excludes APM security updates, does not update MCP entries and leaves several dependency formats unsupported. A newer dependency may be legitimate, compromised or simply behaviorally different; the integration does not establish which. Teams should treat an APM update PR as the beginning of review, not proof that the updated instructions are safe. Inspect upstream changes, evaluate their effect on agent behavior and apply appropriate installation policies before merging.