Six Rivals Standardized the Agent Plugin. The Folder Travels, the Permissions Don't.

Agent Plugins 1.0.0 landed on 6 August, proposed by Vercel and published by a steering committee holding AWS, Cursor, Microsoft, OpenAI, Google and GitHub, with ChatGPT, Codex, Cursor, GitHub Copilot, Kiro and VS Code reading the format on day one.

What got standardized is discovery: a plugin.json at the root, skills in skills/, MCP servers in mcp.json. Installation, distribution, permissions, sandboxing, trust and credentials are all explicitly left to each client.

The two things a plugin carries are the two most sensitive payloads in an agent stack, instructions the model will follow and a command line your machine will run, and neither one travels with a portable statement of what it is allowed to touch.

Six companies that compete directly agreed on a file layout in public, with an open license and a real technical steering committee. That is genuinely rare and I do not want to undersell it. But the pitch attached to it, build once and run anywhere, describes a smaller win than it sounds like, and the gap between the two is worth understanding before you restructure anything.

What actually got standardized

The format is deliberately tiny. A plugin is a directory. At its root sits plugin.json, which requires exactly two fields, a $schema pointing at https://agent-plugins.org/schemas/1.0.0/plugin.schema.json and a name between 1 and 64 characters. Everything else is optional.

Skills live in immediate subdirectories of skills/, each containing a SKILL.md. There is no recursive search, so a skill three levels down does not exist. MCP servers live in a single mcp.json at the plugin root. Client-specific behaviour goes in a top-level directory named after a reverse-domain namespace, like com.example.client/.

That is the whole contract. The fixed locations are the point: no discovery indirection, no alternate-source precedence, no manifest configuration telling a client where to look. Every client can implement the reader in an afternoon, which is why six of them did.

The spec is also honest about why it stops there. Agent Plugins v1 covers skills and MCP servers because, in its own words, both "have established specifications outside this project and meaningful cross-client adoption." Commands, hooks, agents, rules and LSP servers are excluded because they "remain too client-specific for a stable portable contract."

Everything that decides whether a plugin is safe stayed with the client

The specification contains a containment section, and then this sentence about it: the rules "do not sandbox a plugin subprocess or restrict paths supplied at runtime." Containment here means the plugin cannot reach outside its own package for the files it ships. It says nothing about what the process it launches can do once it is running.

Credentials get the same treatment, twice. Plugins "MUST NOT embed credentials or other secrets" in headers, and separately MUST NOT embed them in env. Both rules are correct. Neither is replaced by anything portable, and the spec says so plainly: "Agent Plugins v1 defines no OAuth configuration or portable credential-reference fields. Authorization discovery, user interaction, and credential storage are client-managed."

So take an MCP server that talks to your internal API. The command, the args and the shape of the config now travel. The token does not, and there is no portable way to even reference where the token should come from. You wire auth per client, by hand, in each client's own idiom, exactly as you did before 6 August.

That is the part of MCP adoption that costs real hours. Copying a JSON block between two editors was never the bottleneck.

The install is the security decision, and it is not in the spec

Read the two payloads for what they are. A SKILL.md is text that gets injected into a model's context and treated as instruction. An mcp.json entry is a process your machine starts, with your environment, on your network.

Both now ship in a standard box that six major clients will open. Installation, distribution and policy are, per Vercel's own announcement, left to individual clients.

Twenty-four hours before the format was published, Check Point's Yarden Porat and Shahar Tal presented 11 vulnerabilities at Black Hat spanning LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework and Google ADK. The bug classes were insecure deserialization, server-side request forgery, path traversal and use-after-free. Their framing stuck with me: "A bug in an agent framework isn't a bug in one product, it's a bug in the layer a whole category of AI apps runs on."

The same week, CISA added CVE-2026-9198 to the Known Exploited Vulnerabilities catalog with a 7 August federal remediation deadline. It is a 9.8 in Langflow, versions 1.0.0 through 1.10.0, where an unauthenticated caller pulls a superuser token from /api/v1/auto_login and then hands code to /api/v1/validate/code, which runs it through Python's exec(). IBM shipped the fix on 17 July, the day it disclosed. Public exploits followed in late July.

The standard did not cause any of that, and the two stories are not really about each other. What they share is a layer. A frictionless distribution format arrived for a middleware tier that spent the same week demonstrating it still has 2005-era bug classes underneath it.

Two rules that matter when you review a plugin

First, on namespaces: "A client MUST ignore manifest entries for namespaces it does not implement without validating the contents of their values." That rule is right for compatibility and awkward for review. A plugin can carry a manifest section and a whole top-level directory aimed at a client you do not run, and your client will step over it without looking inside. Silent-ignore is a good interop default and a poor review default, so the reviewing has to be yours.

Second, on versions: "Clients MUST NOT reject a manifest solely because version is not valid Semantic Versioning." Clients use version for update detection and cache staleness. That makes it an opaque string doing load-bearing work. A publisher who versions loosely leaves your client with no way to tell a patch from a rewrite.

The excluded list is the part you maintain

Look again at what v1 leaves out. Commands, hooks, agents, rules, LSP servers. In a mature Claude Code or Cursor setup, those are the pieces that took the longest to get right and that you still tune every month. Skills and MCP config were already the most copy-pasteable parts of the stack, which is precisely why they converged first.

That is how standards form, easy parts first, and it is the correct order. Just calibrate the payoff. The portable box holds the components that were already close to portable.

What I would do this week

Move your internal skills into the layout now. It is a folder move plus a two-field manifest, it is reversible, and it costs an hour. If your team already shares skills across ChatGPT, Cursor and Copilot, you stop maintaining three shapes of the same thing.

Keep secrets out of the package, which the spec requires anyway, and write down the per-client wiring separately. Treat that document as the real artifact, because it is the part that does not travel and the part a new engineer will otherwise rediscover.

Treat installing a third-party plugin as running code, because it is. Read the command and args in mcp.json. Read every SKILL.md, not the README. Pin a version and prefer publishers who use SemVer, given that clients are forbidden from enforcing it for you.

And do not retire your hooks and rules expecting v1 to absorb them. It says outright that it will not.

The standard is real, the governance looks serious, and the format is well-judged for what it set out to do. The honest version of the pitch is lay out once, and decide who you trust every single time you install. That decision was never portable, and this spec is careful enough to say so.