Agent Plugins 1.0: portability is arriving before trust does
Executive signal
Verified fact: Agent Plugins 1.0 defines a portable package format for two existing agent-extension components: Agent Skills and Model Context Protocol (MCP) server configuration. The format creates a common package boundary; it does not create a common trust or execution boundary.
AOS assessment: this is a useful interoperability step, but it changes the software-supply-chain question rather than solving it. Once reusable instructions and tool connections travel more easily between clients, organisations need to make installation, approval, identity, permissions, isolation and revocation explicit controls, not assumptions hidden inside a packaging format.
What Agent Plugins 1.0 standardises
The normative 1.0 specification defines a plugin as a directory with a required plugin.json manifest. It gives two portable component types fixed discovery locations:
- Agent Skills under
skills/, each with aSKILL.mdfile; and - MCP server configuration in
mcp.json.
This is deliberately compositional. Agent Skills remain the format for procedural instructions and supporting resources. MCP remains the runtime protocol for tool and context connections. Agent Plugins standardises how those components are carried together and discovered by a compatible client.
The package format contains useful safety-oriented constraints. A conformant client must validate the manifest before discovery, keep resolved package paths within the plugin root, and isolate certain failures: an invalid skill or individual MCP server entry should not prevent other valid components from loading. For remote MCP servers, the specification also prohibits using configuration headers as a portable secret mechanism and says that portable OAuth configuration or credential references are not defined.
Those measures reduce ambiguity at the package boundary. They are not a sandbox.
Portability has arrived before common execution policy
The specification is unusually clear about what it leaves to clients. It does not define a registry, marketplace, update channel, approval workflow, permission model, sandbox or publisher-verification system. For MCP servers, a client owns authorisation discovery, user interaction and credential storage. An MCP authorisation standard can govern token exchange on a supported HTTP transport, but it does not decide whether an enterprise should install or permit a particular plugin.
That separation is sensible. Clients differ in their operating environments, risk models and user experiences. It also means that “works in more than one client” is not evidence that a package is safe to install or safe to execute.
The distinction matters more for packages that combine instructions with executable or remotely connected tools. A portable skill can steer an agent's work. A portable mcp.json file can point that agent at a local subprocess or remote service. The format constrains the shape of those declarations; the client and organisation still decide whether to trust the publisher, accept the requested capability, store credentials, constrain execution and observe behaviour.
Evidence of adoption, with an important qualifier
The compatible-clients page includes Cursor, GitHub Copilot, ChatGPT & Codex, Kiro and Hermes Agent among clients with varying declared support for Agent Skills and MCP transports. This is meaningful implementation evidence, not proof of uniform runtime behaviour. The same page explicitly presents component and transport support, not a shared permissions, sandboxing or identity model.
A second qualification is important: the specification labels version 1.0.0 as a Working Draft. Organisations should therefore track the exact supported version and each client’s documented behaviour rather than treating “Agent Plugins” as a stable, uniform security certification.
The enterprise control plane that still has to exist
For an organisation adopting portable agent packages, a minimum control plane should answer six questions:
- Identity and provenance: Who published the package, what source and build produced it, and can that provenance be verified?
- Inventory and approval: Which packages, versions, Skills and MCP servers are installed, and who approved each of them?
- Capability and least privilege: What tools, data scopes, network destinations and credentials can each component use?
- Execution isolation: Where do local processes run, what filesystem and network boundaries apply, and what happens when a plugin fails?
- Lifecycle and revocation: How are updates assessed, vulnerabilities handled and compromised packages disabled?
- Observability: Can operators see package installation, authorisation, tool calls, policy denials and anomalous behaviour?
AOS inference: portability will make these controls more, not less, valuable. Repackaging friction previously limited distribution; a shared package shape can lower that friction across compatible clients. The resulting benefit is real: reusable capabilities can move without repeated manifest conversion. But a lowered distribution barrier also increases the value of disciplined admission and execution controls.
What to do now
Treat Agent Plugins as a packaging layer in an agent-extension supply chain. Pilot it with a small, signed or otherwise verifiably sourced allow-list; record each package’s Skills, MCP endpoints and privileges; apply client-specific approval and sandbox controls; and test revocation before broad rollout.
The strategic opportunity is not merely that agents can share components. It is that organisations can standardise the controls surrounding those components while clients retain different experiences. The winning architecture separates portable capability from trusted, authorised execution.
Limits and counterarguments
Agent Plugins 1.0 intentionally avoids over-standardising immature areas. That restraint can preserve client innovation and prevent a weak, one-size-fits-all security model from becoming the interoperability baseline. It also means an organisation may gain package portability without gaining practical cross-client parity: clients can differ in installation, permission prompts, transport support and runtime isolation.
This briefing is an analysis of published specifications and client declarations, not a security audit of those products or of any plugin marketplace.