Agent Plugins 1.0 landed in Copilot clients on 12 August, backed by six vendors, installing by default from a marketplace, and bundling skills together with MCP servers.
Every part of that sentence describes a package manager. Your organisation has spent years building instincts about package managers — provenance, pinning, review, revocation — and almost none of that thinking has been written down for plugins yet. This is the short version of writing it down.
Start by naming what a plugin is
A plugin is not a preference. It is authored by a third party, it bundles capability the agent will execute, it can carry an MCP server that reaches your systems, and it installs in one click from a marketplace.
That is a dependency. Treating it as an editor setting is the mistake that makes everything downstream harder, because settings do not get review and dependencies do.
The useful reframe for a security conversation: you are not deciding whether to allow a feature, you are deciding whether to allow a supplier.
The four controls you have
Copilot Business and Enterprise govern plugins from `managed-settings.json`, and the controls compose. Know what each one answers:
- `strictKnownMarketplaces` — restricts installation to approved sources. This is the big one; without it, the rest is advisory
- `extraKnownMarketplaces` — adds your own marketplace, which is how you distribute internal plugins without opening the door to everything else
- `enabledPlugins` — auto-installs the plugins you want everyone to have, or blocks specific ones
- MCP allowlists — approve or block the servers inside plugins, by URL, command or name, as shipped on 6 August
Set the posture before the list
Decide one thing first, in a sentence, and write it where the config lives: are you allowing everything except what you block, or blocking everything except what you allow?
Deny-by-default via `strictKnownMarketplaces` is the destination. It is also the posture that generates the most friction in week one, so most teams should start permissive, watch what people install for a fortnight, and then tighten around what turned out to be genuinely useful.
The failure mode to avoid is declaring deny-by-default on day one and then spending three months granting exceptions. That is how a control gets switched off entirely.
Five questions before approving a plugin
Not a formal process — five questions someone should be able to answer out loud. If nobody can, that is the finding.
- Who wrote it, and is that a name you would accept on a package.json dependency?
- What MCP servers does it bundle, and what do they reach? A plugin is only as trustworthy as the most privileged server inside it
- Does it need to run locally, and if so, with what access? A local server inherits the developer machine's permissions
- What breaks if we remove it in three months? Anything that quietly becomes load-bearing deserves a second look before it does
- Who on our side owns it? An approved plugin with no owner is an approved plugin nobody will notice going stale
The gap to write down
Plugin controls in `managed-settings.json` reach Copilot clients. They do not reach Cursor, Claude Code, an open-source terminal agent, or any other client that adopts the same standard.
That is the whole point of a cross-vendor standard: the plugin is portable, and your policy is not. A developer who cannot install a plugin in VS Code may be able to install the same plugin somewhere else on the same machine.
Write that limitation into the same document as the policy. A control whose gaps are undocumented gets cited in a risk review as though it had none, which is worse than not having the control at all.
Keep the list alive
Approved-software lists do not fail by being breached. They fail by drifting: six months on, the list names two plugins that no longer exist and misses four that everybody uses.
Give the list an owner, put a quarterly review in the calendar, and make requesting a new plugin easier than working around the policy. If approval is slower than the workaround, you will get the workaround.