Don't Install That Portable Plugin Blind — Agent Plugins 1.0 Moves the Trust Boundary

Agent Plugins 1.0 is an open standard for packaging skills and MCP servers into one installable directory. Portable does not mean safe-to-install-everywhere. The spec standardizes discovery and layout. Installation policy, marketplace review, sandboxing, and secrets remain client- and org-owned.

Why it matters

Agent Plugins Specification 1.0.0 shipped on 2026-08-06. On 2026-08-12, GitHub marked 1.0 support generally available across VS Code, Copilot CLI, the GitHub Copilot SDK, and the Copilot app (all Copilot plans). Launch-compatible clients also include Cursor, ChatGPT/Codex, Kiro, and VS Code. The proposal was refined with AWS, Anysphere, GitHub, Microsoft, OpenAI, and Vercel; Google joined as a core maintainer the same day the spec published.

The operational shift is blunt: teams used to maintain Cursor skills, Copilot plugins, and one-off mcp.json files separately. Now the same skills/ + mcp.json bundle can load in multiple agent clients. Packaging cost drops. Blast radius of a bad plugin rises.

How it compares

Cursor runs a dual track. Agent Plugins use a root plugin.json for portable skills + MCP. Cursor Plugins use .cursor-plugin/plugin.json and can also ship rules, agents, commands, hooks, and variables. Same word, two contracts — label the format in team docs.

On Copilot, existing non-1.0 plugins keep working; there is no forced migration. Targeting 1.0 means adding $schema to plugin.json, keeping skills under skills/, MCP in mcp.json, and moving Copilot-specific files into com.github.copilot/. Business/Enterprise reuse enabledPlugins, extraKnownMarketplaces, and strictKnownMarketplaces — no separate Agent Plugins policy.

Minimal plugin + Copilot enterprise settings

Smallest useful plugin:

hello-plugin/
├── plugin.json
└── skills/
    └── greet/
        └── SKILL.md

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "hello-plugin",
  "version": "1.0.0",
  "description": "Portable greeting skill for Agent Plugins 1.0 clients"
}

---
name: greet
description: Greet the user and offer concrete next steps.
---

Greet briefly, inspect repository context, and propose one next action.
Never print secrets, tokens, or internal URLs.

When you also ship MCP, declare servers in root mcp.json with an explicit transport type per entry. Spec intent (and Google’s write-up) is independent failure: a broken MCP entry should not take unrelated skills down with it.

Copilot Business/Enterprise baseline sketch (managed-settings.json concept):

{
  "enabledPlugins": {
    "hello-plugin@awesome-copilot": true,
    "shadow-exfil@random-market": false
  },
  "extraKnownMarketplaces": [],
  "strictKnownMarketplaces": [],
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.example.com/*" }
  ]
}

GitHub docs describe an empty strictKnownMarketplaces array as a complete lockdown posture. Team overrides treat enabledPlugins and extraKnownMarketplaces as additive, so a loose enterprise baseline lets teams open more holes.

Practical use

1. Inventory skills and MCP configs into “portable core” vs “client-only.”
2. Package one internal plugin with plugin.json + skills/ and load it in Cursor and Copilot (or VS Code).
3. Lock policy before opening markets — Copilot: enabledPlugins / strictKnownMarketplaces / MCP allowlists first. Cursor: document official marketplace vs cursor.directory community paths.
4. Failure-mode test — break an MCP URL and confirm skills still load; plant a secret-exfil instruction in a skill and see what the client blocks.
5. Ownership — fill manifest metadata and put CODEOWNERS on the plugin repo.

Senior-engineer perspective

Portable packaging feeds a real engineering desire: build once, run everywhere. From a review desk, the attack surface becomes multiplicative. Yesterday’s sketchy MCP that lived only in Cursor can ride a default marketplace into every onboarding laptop tomorrow.

Default posture:

• Marketplace badge ≠ internal approval.
• Skill markdown is code review. Prompt injection and exfil instructions travel inside prose.
• MCP is a network boundary. Treat plugin allowlists and MCP allowlists as a pair.
• Do not conflate Cursor Plugins (hooks/rules) with Agent Plugins (portable core); separate release pipelines.

“The standard shipped, governance can wait” is the most expensive sentence of the quarter.

Using it in Cursor

Cursor docs: install/manage Agent Plugins from Customize / marketplace paths; use Cursor Plugins (.cursor-plugin/plugin.json) when you need IDE-tight rules, hooks, commands, or variables.

Practical split:

• Shared skills + MCP across tools → Agent Plugins (plugin.json)
• Cursor agent loop / hooks / commands → Cursor Plugins (.cursor-plugin/)
• Both can live in one git repo, but README must name which manifest is SSOT

If you run cloud agents, check whether plugin MCP endpoints collide with environment egress allowlists. The “works locally, fails quietly in cloud” pattern shows up fast with portable packages.

Where I got stuck

I first treated a root plugin.json as “done.” Loading the same folder in Cursor and Copilot made the mess obvious: Copilot-only commands and hooks were still sitting at the package root, blurring portable core and client extensions. Moving them under com.github.copilot/ is when “other clients ignore this directory” stopped being abstract. The second trap was enterprise settings — plugins blocked, MCP URLs still open — so tool-call paths survived without the skill layer. Pairing the allowlists closed the review checklist.

FAQ

Does Agent Plugins 1.0 replace MCP?

No. It packages and discovers MCP server configuration alongside skills. It does not redefine the MCP protocol.

Must we migrate existing Copilot plugins immediately?

GitHub says existing non-1.0 plugins remain supported with no forced migration. Start 1.0 layout on new shared packages.

Agent Plugin or Cursor Plugin?

Shared skills + MCP only → Agent Plugins. Need Cursor rules/hooks/commands/variables → Cursor Plugins. Need both → keep portable core and Cursor extensions separate.

What should enterprises enable first?

On Copilot: lock markets with strictKnownMarketplaces, pin approvals via enabledPlugins, and review MCP allowlists together. Do not default to “open the whole Awesome marketplace.”

Outlook

The next few months will compete less on “who supports the spec” and more on who contains portable careless or malicious plugins first. Marketplace review depth will differ by client; the spec deliberately does not equalize that. Our team default stays the same: adopt the packaging standard, keep install defaults closed, and supply only approved plugins through a controlled pipeline.

Sources

• Introducing Agent Plugins (Vercel)
• Agent Plugins 1.0.0 changelog (Vercel)
• Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app (GitHub Changelog, 2026-08-12)
• agentplugins/agent-plugins-spec
• Google Developers Blog — Agent Plugins
• Cursor Docs — Plugins
• GitHub Docs — Configure enterprise managed settings