Somewhere on your machine there is probably a folder of agent skills that arrived by copy-paste. A prompt you grabbed from a coworker. An MCP server someone pasted into a Slack thread. A plugin you cloned three months ago and never thought about again. If two people on your team run the “same” agent today, nobody can prove the pieces are identical.
Microsoft released a tool this week that treats this as the problem it is. It’s called APM, the Agent Package Manager, it’s MIT-licensed, and it lives at github.com/microsoft/apm.
What APM actually is
The pitch fits in one line: npm, but for the things agents depend on. Skills, prompts, instructions, plugins, and MCP servers get declared in a single apm.yml manifest. You run apm install once, and the tool deploys the right primitives to whichever harness you use. Nine environments are supported, including GitHub Copilot, Claude Code, and Cursor.
Under that, it builds on three standards that already exist: AGENTS.md, Agent Skills, and MCP. That choice matters. APM is not trying to become another format war entry. It manages the artifacts the ecosystem already agrees on.
The engineering details are more interesting than the headline.
The lockfile is the point
APM generates a lockfile that pins exact versions and content hashes. Clone a repo on a fresh machine, run install, and you get byte-for-byte identical dependencies. If you have ever debugged an agent that behaved differently on a colleague’s laptop, you know why this exists. Until now the honest answer to “are we running the same setup?” was a shrug.
This is JavaScript history repeating, with the timeline compressed. npm ended a dependency chaos era in one ecosystem. Agents have been shipping the same chaos for two years, except the dependencies now include prompts that steer model behavior and MCP servers that hold credentials.
Deny by default, and why that word choice matters
The security model is the part I’d pay attention to, more than the convenience features.
Every install scans for hidden Unicode characters. That sounds paranoid until you remember the demonstration attacks of the past two years, where invisible characters or homoglyphs hidden in code and config slipped past human review. Agent skills are text instructions that a model follows. Text instructions are exactly where that class of attack lives now.
The bigger rule: transitive MCP servers are blocked unless you explicitly declare or trust them. If a plugin you install secretly wants to talk to its own MCP server, APM says no by default. Compare that to npm, where a transitive dependency doing something unexpected is just Tuesday. Microsoft looked at that history and chose the opposite default.
There’s an enterprise layer too. apm-policy.yml ships governance with tighten-only inheritance, flowing from enterprise to org to repo. A team can make policy stricter locally. Nobody downstream can loosen what the org locked. And it works across GitLab, Azure DevOps, Bitbucket, and Gitea, so this is not a GitHub-only play.
Why now
Two moves in two months suggest the agent stack is getting its supply-chain layer, and fast. Anthropic donated the Agent Skills standard to the Agentic AI Foundation in October 2026. Microsoft follows in November with the package manager that manages skills among other things.
When the majors agree on standards this quickly, it usually means the layer underneath is about to become contested ground. Every vendor wants their registry, their signing infrastructure, their governance plane to be the default. Whoever runs the pipe for agent dependencies gets a position similar to what npm holds for JavaScript.
What this means if you ship agents
Suppose your team builds anything agent-shaped this quarter. Three practical reads.
First, copy-paste distribution of skills and prompts now has a credible replacement, and it’s free. The cost of adopting APM is close to zero for a greenfield project. Starting one? Begin with the manifest instead of a shared drive folder.
Second, if you operate in a regulated or security-sensitive environment, the deny-by-default model and tighten-only policy inheritance were built for you. This is the difference between hoping your agent’s MCP surface is what you think it is and having a lockfile that says so.
Third, watch the transitive-MCP rule specifically. It is an admission, from a company with a large security org, that agent dependencies are an attack surface. That framing will shape procurement checklists over the next year. Getting familiar with the vocabulary now costs an afternoon.
A quick start
The core loop, from the repository README:
- Declare skills, prompts, plugins, and MCP servers in
apm.yml - Run
apm install - Commit the lockfile it generates
- Point policy at
apm-policy.ymlif you need org-level rules
That’s the whole workflow. The tool handles translating your manifest into what each harness expects.
The honest caveats
It’s a version-one tool from a company that ships a lot of version-one tools. Reproducibility claims deserve a test on your own stack before you trust them in CI. And a lockfile only covers what goes through the pipe; the skills your team still pastes around by hand remain invisible to it, same as npm never fixed developer laptops.
But the direction is right, and it was overdue. Agent dependencies have been the least governed part of the AI stack while being the easiest vector into a system that increasingly holds credentials and takes actions on your behalf. A package manager with a paranoid security posture is the boring infrastructure answer to a problem that was never going to be solved by everyone being careful.
If you run agents in production, spend an hour with the repo this week. Even if you don’t adopt it, the manifest and policy files are a free template for what your agent governance should probably look like.
