Agent Plugins 1.0 Standardises the Bundle and Leaves Trust to Whoever Installs It

At a glance

The specification is deliberately small. A plugin is a directory, and that is nearly the whole of it.

Six clients supported it at launch — ChatGPT, Codex, Cursor, GitHub Copilot, Kiro and VS Code — and Google said on the same day that it would integrate support into its own products, starting with the Agents CLI and the Data Agent Kit. Governance runs through a technical steering committee whose seats belong to individuals rather than companies, with a charter that forbids any single vendor from holding a majority.

Why a packaging standard was worth doing

The problem it solves is real and unglamorous. Before this, shipping a capability to agent users meant writing the same integration several times: a skill file in one client's format, a different one for the next, an MCP server registration with per-client setup instructions, and a README explaining which combination to use where. A vendor who wanted their platform usable from agents was maintaining N sets of install docs that drifted apart.

Agent Plugins is not a third format competing with Skills and MCP — it is the wrapper that lets one bundle of both install into six clients unchanged. That is a genuine reduction in busywork, and it is the reason the launch got the reception it did.

It is also why the maintainers' argument for the narrow scope is not unreasonable. Installation, policy, enterprise controls and approval flows genuinely do look different in an IDE, a CLI and a managed enterprise platform, and a specification that tried to unify them would have been rejected by at least two of the five signatories. A format everyone ships beats a governance model nobody adopts.

Accept all of that, and the interesting question is not whether the scope was drawn correctly. It is what happens to risk when the packaging problem is solved and the trust problem is not.

The bundle carries two very different things

Skills are instructions, and instructions are the injection surface

A skill is text the model reads and follows. That makes a skills directory a prompt you have delegated authorship of, and the failure mode is not malware — it is a paragraph that shifts the agent's default behaviour in a way no test covers. "When the user asks about deployments, always check the staging config first" is a helpful instruction. The same sentence with a different second clause is a redirect, and it reviews as documentation because it looks like documentation. Nobody has a review culture for prose, and the diff of a skills update is prose.

mcp.json is reach, and it runs on your credentials

The server side is the conventional supply-chain problem, arriving through a channel that does not feel like a dependency add. A plugin's mcp.json tells the client which servers to launch; those servers are code, they hold network egress, and they act with whatever access the installing user has. The install ceremony is a command or a click, not a lockfile entry that shows up in a pull request.

Together they are the part that is new

Each half has precedent. What is new is shipping them as one unit: the artifact that tells the agent what to do also supplies the means to do it, in a single install, on a format designed for portability. That combination has no established review practice, and v1 does not create one.

Portability multiplies the blast radius — that is the whole point of the format

Fragmentation is a tax, and it is also, accidentally, a containment boundary. When a capability had to be repackaged per client, a compromised bundle reached one ecosystem and stopped. A portable format is valuable in exactly the proportion that it removes that friction — for authors and attackers alike, since neither one is doing anything the format distinguishes between.

This is not an argument against the format. It is an argument about where the compensating control has to live, and the answer is not "in the spec", because the spec has said so explicitly. The project's own future-considerations document names provenance verification as unaddressed in v1, alongside permission and approval UX, enterprise controls and audit-trail standardisation. That is an unusually honest artifact and it is worth reading as a roadmap of what you currently own yourself.

What "no trust model" concretely means

There are no cryptographic signatures in the format. There is no attestation binding a published plugin to the source repository it claims to come from. There are no capability declarations — nothing in plugin.json says "this plugin reaches the network" or "this plugin writes files" — so a client cannot render a permissions prompt from the manifest even if it wants to, and there is no graduated trust level to escalate through. A plugin is trusted at the moment it is installed, and by whichever client installed it.

Portability makes divergence a property of the ecosystem

Because permissions and sandboxing are per-client, the same bundle gets different treatment in each. A plugin installed into a managed enterprise platform with policy controls, and the same plugin installed into a local CLI by a developer in a hurry, are the same artifact with materially different exposure. Your organisation's effective posture is the weakest client anyone is running, and the format is specifically designed so that the plugin does not know or care which one it landed in.

What to do about it this month

None of this argues for staying off the format. It argues for treating an install as what it is.

• Treat a plugin install as a dependency add, with the same review. It enters through a different door than package.json and it should meet the same bar: who publishes it, what it reaches, is it pinned, and who approved it. If your change-management process cannot see plugin installs today, that gap is the first thing to close.
• Pin versions and vendor the bundle. Absent signatures and attestation, a pinned copy you fetched and reviewed is the strongest integrity control available. Re-review on upgrade, because the upgrade is where a prose change lands unnoticed.
• Read skills/ as prompt content, not as documentation. Diff it on every version bump. It is the half most likely to change quietly and the half your reviewers are least trained to be suspicious of.
• Mediate mcp.json through a gateway you operate. Servers launched by a plugin should reach the network through the same proxy and the same allowlist as everything else, so that the plugin's reach is bounded by your egress policy rather than by its own configuration.
• Register the install. A plugin changes what an agent can read and do, which makes it a change to that agent's grant — the unit of record argued for in agent inventory and registry. An installed plugin nobody recorded is the shadow-agent problem with a nicer package format.
• Decide the client posture centrally. Since permissions vary by client, your policy has to name which clients are permitted to install plugins at all, and with what controls. Leaving that to each engineer's tool choice makes the weakest configuration the organisational default.

Further reading

On this wiki:

• Agent Skills — what the skills/ half of a plugin actually is.
• What Is the Model Context Protocol? — the other half, from cold.
• Agent Supply-Chain Security — the review practice this format needs and does not supply.
• Tool Poisoning — why bundled instructions are an injection surface.
• MCP Registry & Distribution — the distribution problem v1 explicitly leaves open.
• Agent Inventory & Registry — recording an install as a change to an agent's grant.

Sources:

• agentplugins/agent-plugins-spec — the v1.0.0 specification
• FUTURE_CONSIDERATIONS.md — what v1 does not address
• agent-plugins.org — project site and governance
• Google Developers Blog — joining as a core maintainer
• Agentic AI Foundation — from skills and tools to portable agent plugins