9 min read - Dependabot for APM: Put Agent Context Under Change Control

GitHub added Dependabot version updates for Agent Package Manager (APM) on 3 November 2026. A repository can now ask Dependabot to update supported Git dependencies in apm.yml and regenerate an existing apm.lock.yaml file.

For teams that share AI agent skills, prompts and instructions, the release shows these files becoming dependencies with versions, owners and review paths. The decision to make is which agent context to manage as a dependency, and what evidence a reviewer needs before accepting a change.

What GitHub released, exactly

GitHub's 3 November announcement says Dependabot can open pull requests for supported Git dependencies declared in apm.yml. When a repository already contains apm.lock.yaml, the service regenerates that lockfile. The integration is generally available on GitHub.com for all plans; GitHub says it will also arrive in GitHub Enterprise Server 3.24.

GitHub is explicit that this is version-update support, not security-update support. A fresh pull request therefore means that a newer version was found. It does not mean GitHub assessed the package's prompt semantics, tool behaviour or security.

Microsoft describes APM as “a dependency manager for AI agents” and compares it to npm for agent context. One manifest can declare skills, prompts, instructions, plugins and MCP servers, then install supported files into several agent harnesses. Its lockfile pins versions and content hashes so a later install can resolve the same package content. APM is open source under the MIT licence.

Together, the two projects provide familiar machinery: a manifest records intent, a lockfile records the resolved state, and an update bot proposes movement. They do not decide whether the new instructions still express your policy or whether an installed tool should receive production credentials.

Agent context can change system behaviour

A conventional library update may change code your application executes. Agent context can change how a model interprets a task, which files it reads, how it frames a review and which tool it tries to call. A diff that contains only Markdown or YAML can therefore alter an operating path without changing application source.

Classify each dependency by its effect before automating updates:

The last row needs its own path. GitHub's APM support reference says Dependabot updates entries under dependencies.apm and devDependencies.apm, but does not update mcp: entries. Teams should not infer that an MCP dependency is covered because it shares the same manifest.

Know which references the updater can move

GitHub documents three supported pin patterns. A semantic-version tag moves to the latest SemVer tag; a full commit SHA can move to the commit associated with the latest annotated, non-prerelease release; a branch reference can move the lockfile to the branch's latest commit when the lockfile already exists.

Several forms remain outside the updater, including entries without a reference, local paths, abbreviated SHAs, object-form entries and dependencies hosted on Azure DevOps. Dependabot also does not create a missing APM lockfile. Because of these limits, start with an inventory.

For every shared package, record:

• the manifest location and resolved source;
• the pin type and reason for choosing it;
• the files installed into each agent harness;
• a business owner and a technical reviewer;
• tests that expose a meaningful behaviour change;
• the rollback version and removal path.

If the team cannot name the installed files or owner, automated update pull requests will pile up with nobody able to decide on them.

Separate freshness, integrity and meaning

Three questions often collapse into one green check.

Freshness: is a newer allowed reference available? Dependabot answers part of this question for the supported dependency forms.

Integrity: did installation resolve the content recorded by the lockfile? APM says its lockfile stores exact versions and content hashes, and its policy reference lists audit checks for content integrity and manifest-to-lockfile consistency.

Meaning: do the changed files still produce acceptable behaviour under your use case and permissions? Neither a version-update pull request nor a matching hash can answer that. A malicious or simply unsuitable change can have a valid version and a correct hash.

NIST's SSDF profile for generative AI (July 2024) recommends verifying the integrity, provenance and security of acquired AI components, and scanning and thoroughly testing them before use (task PW.4.4). The profile addresses AI model and system development, not APM specifically, and NIST does not endorse this tool. We read its separation of acquisition evidence from use approval as a sound pattern for agent packages.

Use APM policy without assuming it reads intent

Microsoft's APM governance guide documents allow and deny lists, pinned-dependency requirements, transitive-depth limits, MCP transport controls and CI audit checks. It also describes tighten-only policy inheritance, so a repository can narrow an organisation policy but cannot relax its parent constraints.

The same guide lists material gaps. APM scans for hidden Unicode, but it does not perform semantic prompt review or prompt-injection detection. Its MCP matcher inspects only the registry name; it does not validate the command or args of a self-defined server. It does not audit token or OAuth scopes. The compile and run commands trust what installation placed on disk rather than rechecking policy.

Treat those statements as design inputs. Keep credential scope in the identity system, inspect effective MCP commands separately, and run behavioural tests on the installed context. A policy file rejects known-bad shapes; someone still has to read the change.

A low-risk pilot for a small engineering team

Start with one shared, non-executing package, such as a code-review checklist that cannot call an MCP server. Avoid a package that changes deployment, database or cloud commands in the first trial.

1. Baseline the current behaviour. Save a small fixture set with ordinary code, a known defect and a false-positive trap. Record the accepted findings and omissions.
2. Create the manifest and lockfile deliberately. Pin a release tag or full SHA, inspect the installed files and commit both the intent and resolved state.
3. Add a slow update cadence. Weekly is easier to review than daily for a first package. Limit the updater to the directory that contains apm.yml.
4. Make the pull request show its work. Review the upstream source diff, lockfile movement, effective installed-file diff, licence and release notes. A version number alone is not sufficient evidence.
5. Replay the fixtures in isolation. Compare findings, commands requested, files touched and failure handling. Stop on unexplained behaviour, even if installation and audit checks pass.
6. Merge with a return path. Keep the previous pin and fixture result, then record who can revert the package if real work exposes a missed regression.

Our production AI dependency gate covers runtime libraries and staged rollout. Agent context needs an extra semantic diff because its main behaviour may live in prose. The GitHub package firewall pilot offers a related pattern for exception ownership and evidence when a dependency source is blocked.

Decide whether packaging pays for itself

APM is a reasonable trial when several repositories copy the same instructions, teams use more than one supported harness, or nobody can answer which version of a shared skill is installed. A manifest and update queue can reduce silent drift.

Keep plain repository files when one team owns one small agent configuration and can review every change through its normal pull request process. Adding a package manager creates another tool, policy and failure path. Adopt it only if the gain exceeds that operating cost.

Before adoption, ask:

• Which context is shared enough to package, and which should stay local?
• Can every dependency be traced to an owner, source and resolved version?
• Which changes need a security reviewer or a workflow owner?
• What test would catch a harmful instruction change without relying on a demo?
• Are MCP declarations, credentials and installed files reviewed outside Dependabot's documented scope?
• How quickly can the team restore the previous package and prove the restoration?

GitHub has made agent-package freshness easier to manage. Treat each update pull request as the start of a review.

Explore Exceev's AI and engineering services if your team needs to map agent dependencies, define review evidence or test a controlled adoption path.

Sources and limitations

We opened and reviewed every source below on 4 November 2026.

• GitHub's release announcement is the primary source for the release date, availability and version-update-only boundary.
• GitHub's supported-ecosystems reference defines supported pins, updated manifest sections, lockfile behaviour and excluded dependency forms.
• Microsoft's APM documentation describes the manifest, lockfile, supported context types, integrity claims and licence.
• Microsoft's governance guide documents policy controls, audit checks, bypass surfaces and semantic-review gaps.
• Microsoft's policy reference lists the audit checks for content integrity and manifest-to-lockfile consistency.
• NIST's SP 800-218A (July 2024) supplies independent guidance on verifying acquired AI components (task PW.4.4). It does not evaluate or endorse APM or Dependabot.

We did not install APM, run Dependabot against a test repository or inspect GitHub's service implementation. Product behaviour and availability may change after the review date. The content classification, pilot and adoption questions are Exceev's analysis. They are operational guidance, not a security certification or legal advice.