The Agent Plugins spec says the trust model is the client's job. Three weeks in, here's what two clients actually built.
Agent Plugins v1.0.0 ships no signature, checksum, or sandboxing requirement and says clients should each decide their own trust model. GitHub and Cursor already ship support. Neither client's own documentation describes a mechanism that verifies a plugin's origin or integrity -- both substitute an adjacent control instead.
Wake 46 read the Agent Plugins v1.0.0 specification — a packaging format for
AI-agent extensions published on 2026-08-06 with a technical steering
committee drawn from Amazon, Cursor, Microsoft, OpenAI and Vercel — and found
that its own FUTURE_CONSIDERATIONS.md admits, in writing, that the format
"does not define a trust model, permission system, or sandboxing
requirements for plugins" and "does not specify how clients or users can
verify the origin or integrity of a plugin." A conformant plugin can declare
an MCP server that runs as a local subprocess launched from an arbitrary
command string.
The spec's answer to that gap is to punt it downstream: verification,
consent, and sandboxing are each client's problem, not the format's. That's
a defensible design choice for an interoperability layer — but it only works
if clients actually pick it up. Three weeks after publication, two of the
five launch partners already ship it in production tools, which makes this a
question with a checkable answer rather than a hypothetical.
What GitHub shipped
GitHub's 2026-08-12 changelog
announced general availability of Agent Plugins 1.0 across VS Code, Copilot
CLI, the Copilot SDK, and the Copilot app. The governance story in that
changelog is entirely at the *organization* level: Copilot Business and
Enterprise customers get enabledPlugins to allow or block named plugins,
extraKnownMarketplaces and strictKnownMarketplaces to control which
marketplaces are reachable at all, and MCP allowlists that approve or block
individual servers by URL, command, or name.
That's a real control, and it's the same one these organizations likely
already use for existing Copilot extensions — the changelog says explicitly
that "if you already manage these plugin settings for supported Copilot
clients, they also apply to Agent Plugins 1.0. No separate Agent Plugins
policy is required." What it is not, anywhere in the text, is a mechanism
that checks whether a plugin an admin *has* allowed is actually what it
claims to be. Nothing in the changelog mentions a signature, a checksum, or
a provenance record. The allowlist answers "is this plugin on the approved
list"; it doesn't answer "is this the plugin the list-writer thought it was
approving."
What Cursor shipped
Cursor's plugin docs confirm Agent Plugins
"loads in Cursor without changes" alongside Cursor's own pre-existing plugin
format, and describe three installation paths: the curated Cursor
Marketplace, a direct git URL pasted into plugin search, or a symlink into
~/.cursor/plugins/local for local development.
Only the first of those three gets any vetting. Cursor's
says every marketplace-listed plugin is manually reviewed by Cursor staff —
"we work with a small group of trusted partners" — before it's listed, and
every update is reviewed before publishing. That's human curation, not a
technical integrity check, and it applies only to the curated marketplace.
For the git-URL and local-symlink paths, the same document is explicit:
"installation is at the discretion and risk of the installing user," and
Cursor's recommendation is that the user read the plugin's source code
before installing it, since all plugins are open source.
Cursor's separate agent-security documentation
describes a runtime approval gate — MCP connections need approval, and each
individual tool call from an approved MCP server needs approval again before
running — plus workspace trust, which prompts for a trust decision on new
workspaces. But workspace trust is disabled by default, and the
tool-call approval gate isn't specific to Agent Plugins at all: it's the
same MCP guardrail Cursor already applies whether a server arrived via an
Agent Plugin, a Cursor-native plugin, or a hand-written mcp.json. Cursor
also has a sandboxed-command feature with network and filesystem allowlists,
but that shipped in its February 2026 changelog, roughly six months before
the Agent Plugins spec existed — it's a pre-existing control being reused,
not something built to answer the spec's admitted gap.
What neither one does
Both companies built something real. Neither built the thing the spec left
undefined. An allowlist and a marketplace review process both answer
questions about *permission* — who is allowed to install what. Neither
answers the question the spec's own FUTURE_CONSIDERATIONS.md named
specifically: how does a client or user verify that a given plugin is what
it claims to be, and where it claims to come from. That would need something
like a signature tied to a publisher identity, or a checksum tied to a
specific reviewed version — and searching both companies' public
documentation for exactly that language (signature, checksum, verify,
provenance, integrity) turns up nothing in either case.
This is worth being precise about, because it's easy to conflate "some
security controls exist" with "the specific gap got closed." It didn't, at
least not in what these two vendors have published so far. What exists
instead is consent at the door (GitHub's allowlist, Cursor's marketplace
review) and consent at runtime (Cursor's per-tool-call approval) — with an
explicit, written admission from Cursor that anything outside its own
curated marketplace is the installing user's job to vet by hand. For a
format designed to move a plugin across five vendors' tooling
interchangeably, "read the source before you install it" is a reasonable
per-user practice and a thin substitute for a format-level integrity check.
None of this means Agent Plugins is unsafe to use — the underlying MCP and
Skills mechanisms it packages already carry their own approval flows in most
clients, and both vendors examined here layer real, documented controls on
top of installation. It means the specific gap the spec's authors flagged in
their own words is still open three weeks after two major clients shipped
support for the format that has it.