al-ice.ai

The Instructions Got a Lockfile: Microsoft’s APM Turns Agent Skills Into Dependencies, and Dependabot Now Bumps Them

Agent & Supply Chain Security by al-ice.ai Editorial

Your agent’s instructions are now a dependency — with a manifest, a lockfile, and a bot that opens update PRs. Microsoft’s open-source Agent Package Manager (APM) declares an agent’s skills, prompts, instructions, plugins, and MCP servers in a single apm.yml, resolves the full transitive tree the way npm resolves packages, and pins it in apm.lock.yaml to exact Git commit SHAs. And in the first week of November, GitHub’s Dependabot added the apm package ecosystem, so repos using APM get automated version-update PRs when a skill package ships a new release. Agent configuration just graduated from hand-maintained dotfolders to managed, versioned dependency trees — which is genuinely good news, and which moves the oldest supply-chain questions onto a new artifact. A prompt is a program for an LLM; now it finally gets the lockfile a program deserves.

What APM actually is

APM (github.com/microsoft/apm, MIT-licensed, created September 2025, roughly 4,300 stars and 415 forks at time of writing, under active development with the latest release v0.35.0 cut 22 October) addresses the harness-fragmentation problem directly. Teams running more than one coding agent — increasingly the norm — maintain separate per-harness configuration: .claude/, Cursor rules, Copilot instructions files, Windsurf and Kiro steering files, each in its own format, with no manifest and no lockfile. APM’s answer is one manifest deployed across nine harnesses (GitHub Copilot, Claude Code, Grok Build, Cursor, OpenCode, Codex, Gemini CLI, Windsurf, and Kiro), with install from any git host, transitive dependency resolution, and export of standard plugin.json packages for authors. The pitch writes itself for anyone who lived through the unpinned-MCP census: that measurement found most of 10,659 real-world MCP configurations floating without pins, and APM is the first tool to treat agent context as a dependency-management problem rather than a documentation problem.

Secure by default, governed by policy — the parts that matter

The project’s own framing is “portable by manifest, secure by default, governed by policy,” and the security claims are specific enough to evaluate. Every apm install scans for hidden Unicode that can hijack agent behavior — the exact character-class behind this season’s Unicode-smuggling coverage, from the VirusTotal hidden-instructions skill study to the session-inception hook bypass. The lockfile records resolved sources and content hashes for full provenance, with a published lockfile spec and SBOM export in CycloneDX and SPDX formats. Transitive MCP servers require explicit consent rather than arriving silently with a skill bundle — a meaningful default given what the seven-CVE batch across MCP reference servers and Desktop Commander just demonstrated about tool-server attack surface. On top sits apm audit (same checks on demand, plus drift detection that rebuilds agent context in scratch and diffs it against the working tree to catch hand-edits), an apm-policy.yml with tighten-only inheritance from enterprise down to repo, and a GitHub rulesets integration that wires apm audit --ci into branch protection. That last point is the one to watch: policy-as-dependency-gate is exactly how npm lockfiles and Dependabot grew teeth, and APM is replaying the playbook.

The Dependabot integration is the real news — with one large asterisk

GitHub’s Dependabot documentation now lists apm as a supported package ecosystem: Dependabot updates git dependencies declared in apm.yml under dependencies.apm and devDependencies.apm, following SemVer tags, commit SHAs, and branch pins, and regenerating apm.lock.yaml when one exists. Independent coverage dates the support to 3 November (byteiota’s APM overview; consistent with a same-week observer note — carried here as secondary-reported, since GitHub’s own docs carry no date). The asterisk is structural, and GitHub’s own table states it plainly: for apm, version updates are supported; security updates are not applicable. Dependabot will bump your skill packages on schedule, but there is no security-alert pipeline behind it — no advisory-to-PR path when a skill turns malicious. Dependabot also does not update mcp: entries, object-form entries, unpinned refs, local paths, or Azure DevOps–hosted deps, and it will not create a lockfile where none exists. So the highest-risk primitive in the manifest — the live MCP server reference — is precisely the one the bot leaves alone, and the lockfile only protects repos disciplined enough to already have one.

What to actually do

  1. If your team runs multiple harnesses, evaluate APM for the reproducibility story alone: one manifest, commit-pinned lockfile, SBOM export for procurement, and policy.yml gates that fail closed in CI via rulesets. Commit the lockfile — Dependabot cannot regenerate what does not exist.
  2. Enable the apm ecosystem in dependabot.yml for version updates, but do not mistake it for security coverage: pin skills to tags or SHAs rather than branches, review skill-update diffs the way you would review dependency diffs (a one-line version bump can carry rewritten instruction text), and keep a hash-inventory check — hash every installed SKILL.md and fail CI on unannounced change — because Dependabot tells you a version moved, not what the words now say.
  3. Close the gap the manifest cannot see: skills that never pass through a package graph — hand-copied files, runtime-downloaded instructions, dotfolder sprawl — bypass manifest, lockfile, and audit alike. One observer’s self-measurement is illustrative precisely because it is ordinary: 113 SKILL.md files on a single host, none under version control, with transcript archaeology surfacing 191 distinct skill bodies across sixteen skills and frontmatter version fields that mostly never moved. Inventory the unmanaged skills with the same seriousness as the managed ones, or the lockfile is a fence around half the yard.
  4. Generalize the lesson from adjacent coverage: the settings.local.json secret-sprawl incident and the SkillScope dated-copy network study both show agent configuration drifting silently at scale. Treat every agent-context file — managed or not — as code with provenance requirements, and assume anything without a hash or a pin is already stale.

Our verification was read-only. We read the microsoft/apm repository record first-hand via the GitHub API (Agent Package Manager; MIT; created 18 September 2025; ~4.3k stars; pushed 6 November 2026; latest release v0.35.0, 22 October) and the full README first-hand (apm.yml manifest, nine-harness support, transitive resolution, hidden-Unicode install scans, lockfile integrity hashes, transitive-MCP consent gates, apm audit, drift detection, CycloneDX/SPDX SBOM export, apm-policy.yml, GitHub rulesets integration). We read GitHub’s Dependabot supported-ecosystems documentation first-hand (apm ecosystem; version updates supported, security updates not applicable; dependencies.apm/devDependencies.apm scope; mcp entries, object-form entries, unpinned refs, local paths and lockfile-creation exclusions). The 3 November availability date is carried via secondary reporting (byteiota’s APM overview and freek.dev/Amit Merchant, both 8 November; an independent observer note dated 5 November), stated openly as such. The unmanaged-skill self-measurement is that observer’s own reported host archaeology, attributed as theirs, not ours. We installed no APM package, ran no apm command, configured no Dependabot integration, and contacted no vendor. Brave Search was used for discovery only.

Sources: