Agent Plugins 1.0.0: The npm Moment Arrived. The Gatekeepers Stayed.

0xSam
Macro

August 6, 2026. The date is now burned into the agent ecosystem's collective memory.

At 9:41 AM Lisbon time, my market surveillance feed lit up with an announcement that had the unmistakable texture of a real event. Amazon, Microsoft, OpenAI, Vercel, and Cursor simultaneously adopted Agent Plugins 1.0.0, an open, vendor-neutral standard for packaging Agent Skills and Model Context Protocol (MCP) servers into portable plugins.

Not a proposal. Not a white paper. Not a roadmap. A shipped, working standard already integrated into VS Code, GitHub Copilot, Cursor, ChatGPT, and Kiro.

The ecosystem got its npm moment. Pulse on the chain, breath in the market. It is the kind of moment we in the market surveillance world usually see once or twice a decade: a sudden alignment of the biggest platform operators around a common technical artifact. The chaos of the agent economy suddenly had a shared container. The rush to ship had overtaken the rush to debate.

The contrast with the IETF DAWN working group was brutal. DAWN spent July debating the discovery layer underneath agent ecosystems in Vienna. Twelve pre-charter Internet-Drafts. A charter deferred at IETF 126. The industry had a front-row seat to a standards process moving at glacial speed. Then, on August 6, the industry built its own answer. Not the same answer—Agent Plugins packages capabilities, it does not solve discovery—but the timing was not a coincidence. The industry chose shipping over consensus.

I have spent sixteen years watching protocols die in committee meetings and watching products win on the ground. This was the latter. But the thrill of a shipping moment always creates a blind spot. The real story is not the package format. It is the distribution channels, the trust vacuum, and the company missing from the photo.

Welcome to the gatekeeper economy of agent infrastructure.


Agent Plugins 1.0.0 sits at the intersection of two powerful layer shifts in the AI stack.

The first shift is the rise of Agent Skills. An agent skill is a packaged, executable behavior that lets a model do something beyond generating text. It can query a database, interact with a trading API, submit a compliance report, execute a workflow, or call a series of tools. Skills transform an AI model from a conversational interface into an autonomous worker. They are the difference between a chatbot that tells you what happened and a system that does something about it.

The second shift is MCP, the Model Context Protocol. MCP is the standardized connector that gives agents access to tools and data. Think of it as the USB-C of AI data access. It is the interface that lets a model reach into external systems—databases, CRMs, cloud services, blockchain indexers, exchange APIs—without building a custom integration for each source. MCP servers are the actual endpoints, the containers of capability. They power everything from a file reader to an entire quantitative trading desk.

Agent Plugins 1.0.0 packages those skills and MCP servers into a portable, drop-in format. If you are a developer, you can now build a plugin that contains the skill plus the MCP server configuration, the instructions, the metadata, and the relevant files. You can ship it to any client that supports the standard. That is the promise.

The adoption list is the clearest sign that this is not a vanity standard. VS Code is where millions of developers write code. GitHub Copilot is the AI pair-programmer that reshaped the IDE experience. ChatGPT is the largest commercial AI entry point. Cursor is the AI-native editor that has become the default choice for a new generation of developers. Kiro is the agentic browser that treats the browser window as an autonomous worker. These five clients collectively represent the dominant surfaces where people meet software agents.

Google joined as a core maintainer the same day. Kevin Hou is leading the effort from Google Developers. Google ships two plugin producers—the Agents CLI and the Data Agent Kit—though it is not yet listed as a client entry. That is a strategic pause. Google is not ceding anything. It is waiting to see where the client value accrues before fully stepping onto the battlefield.

The Technical Steering Committee includes Clare Liguori from AWS, Roshan Sadanani from Cursor, Harald Kirschner from Microsoft, Gav Verma from OpenAI, and Jonathan Hefner from Vercel, who serves as lead core maintainer. The project name, logos, domains, and GitHub organization are held in trust by a neutral entity. The licenses are CC-BY-4.0 for the spec and Apache-2.0 for code. That is about as open as a software standard can get.

Now let me tell you what the announcement did not say.

The announcement did not say who controls the installation channel. It did not say how a plugin moves from a developer repository to a user's client. It did not say how a user verifies that a plugin is authentic. It did not say what the plugin is allowed to do after it runs. It did not say whether there will be a shared registry. It did not say whether enterprise policies can be enforced across all clients.

Those omissions are the story.

I learned this lesson auditing Layer2 bridges. The protocol can be beautifully decentralized. The sequencer can be a shining example of consensus design. But unless the bridge's signing key is protected by a robust custody solution, none of that matters. In the same way, a plugin format can be beautifully open. But unless the distribution and trust layers are handled, the open format becomes a single shared container for a series of walled gardens.

The plugin format defines the package. It does not define the platform. The platform is where the money lives.


Let me deepen the technical picture for you. This is the part that the launch press releases gloss over.

Inside an Agent Plugin, you have a manifest file. That manifest declares the name, version, description, and the entry points for the plugin. It references the Agent Skills that should be loaded into the model's context. It references the MCP servers that should be spawned when the plugin activates. It may also include configuration for the agent's behavior, the tools available, and the memory or state files the agent is allowed to touch.

The manifest is transparent. The manifest is also just a recipe. The client executing the plugin decides how much of that recipe to honor. A client can ignore the manifest's requests if they violate local policies. A client can add extra restrictions. A client can silently log every action the plugin performs. The standard does not mandate how the client interprets the manifest.

That is why I read the first 90 seconds of any new plugin standard the way a portfolio manager reads a new token listing. I look for the missing definitions. I look for the permissions implied by silence. I look for the trust assumptions buried in documentation. Caught in the flash, framed in fact. That is the only way to stay sane in a market moving this fast.

Consider the agents.md convention. The coalition adopted agents.md as the standard file for describing agent behavior and project context. Anthropic uses claude.md for the same purpose. These two files are not interchangeable. A plugin built for Claude Code cannot simply be dropped into a coalition client and expect the same behavior. The configuration schema differs, the instruction hierarchy differs, and the client-specific features differ. This is not a small edge case. It is a fork in the road for the agent ecosystem.

The second technical point is MCP gateway configuration. When a plugin bundles an MCP server, the client needs to know how to connect to that server. Is the server local or remote? Which authentication credentials does it use? What tools does it expose? The plugin manifest can describe this, but the standard leaves the enforcement to the client. A malicious plugin could point the MCP server to an external endpoint and request credentials that the agent already possesses. Without a permission model, the client may just accept the request.

Based on my audit experience, I can tell you that this is the kind of vulnerability that enterprises will discover the hard way. In the crypto world, we had smart contract wallets that could interact with any contract. That ability was a feature until someone found a way to drain the wallet. Agent plugins are heading for the same cliff.

The standard, in other words, is a container. Containers are only as safe as the runtime that executes them and the pipeline that delivers them. The coalition has defined the container. It has not defined the pipeline or the runtime controls.

That is where the economics begin.


Now let me talk about the economics.

Let me start with the obvious. The technical spec is open and vendor-neutral. That is not marketing speaking. The license is permissive. The governance structure is balanced. The TSC seats belong to individuals, not companies. The neutral entity holding the project name and logos reduces the chance of a hostile takeover. All of that is real.

But the business model is not neutral. The economics of the agent ecosystem are determined by the parts the spec omits.

Read the spec carefully. Agent Plugins 1.0.0 deliberately excludes installation mechanisms. It excludes distribution protocols. It excludes provenance verification. It excludes permission models. It excludes sandboxing requirements. It excludes marketplaces. These are not accidental gaps. They are the load-bearing walls of a business strategy.

The platform operator who ships the client becomes the gatekeeper. Because the spec defines no registry or marketplace, each client decides how plugins will be discovered, installed, and managed. VS Code will have its own experience. Cursor will have its own. ChatGPT will have its own. Copilot will have its own. Kiro will have its own. The plugin file may be portable, but the path to the user is not.

Let me put this in language any crypto survivor understands. ERC-20 was an open token standard. Anyone could create a compliant token. But the value accrued to the exchanges that controlled listing, liquidity, and trading. The standard was open. The market was not. The same dynamic is now embedded in the agent plugin economy.

A developer building a high-value agent skill needs to decide which gatekeeper to serve. If you build a skill for financial compliance, you might want ChatGPT because of its massive enterprise reach. But OpenAI can delist you, deprioritize you, or build a competing skill at any moment. If you build for VS Code, you get a deep developer ecosystem, but you will need to navigate Microsoft's existing marketplace dynamics. If you build for Cursor, you get a fast-growing, earlier-stage ecosystem, but your enterprise visibility is thinner. If you build for Kiro, you get an agentic browser that could become the universal endpoint, but the user base is still maturing.

Each choice is a commercial relationship. The plugin format does not protect you. The plugin format gives you a sandbox in which you can compete for the favor of a gatekeeper. That is not neutrality. That is a shared battlefield.

The fragmentation is structural, not accidental. Every client will define its own discovery experience. Discovery is the new search engine. Whoever controls discovery controls which plugins get used, which skills get bought, and which agents get deployed. The plugin standard simplifies packaging, but it leaves discovery to the same companies that already dominate software distribution.

For enterprise technology leaders evaluating agent deployments, this has an uncomfortable implication. The cost of switching platforms is not just technical. It is commercial.

Suppose your team standardizes on Cursor-based agents. You build a set of internal agent skills that query your data lake, monitor your infrastructure, and generate compliance reports. Everything is packaged as Agent Plugins 1.0.0. Then the team decides to switch to ChatGPT for its enterprise controls. The plugins are portable at the file level. But the distribution experience changes. The permission model changes. The way users discover and install tools changes. The monitoring and audit capabilities change. The policy enforcement changes. You are not switching file formats. You are switching landlords.

Multi-homing is also not free. A developer who wants to reach all five clients must manage five distribution paths, five update mechanisms, five review processes, and five trust layers. The open standard lowers the cost of building the package. It does not lower the cost of distributing the package. In some ways, it raises the cost because developers now think they should be able to multi-home, and then discover that each client has its own quirks.

This is where the market surveillance perspective changes your view. You start to look at the announcement not as a technical breakthrough but as the opening of a new set of trading venues. The plugin format is the asset. The clients are the venues. Each venue has its own listing standards, its own market structure, and its own fee model. The plugin developer is the issuer. The enterprise user is the buyer. The gatekeeper is the exchange.

I have spent years running where the liquidity flows fastest. That is the same instinct that drives this analysis. Liquidity follows distribution. Distribution follows control. Control follows the client.

Let me get more specific about what the gatekeeper can do.

Imagine you are at a large financial institution. You decide to deploy agents that can query internal transaction data, flag suspicious activity, and draft regulatory filings. You need a plugin that accesses your homegrown MCP server. The plugin is built and packaged according to Agent Plugins 1.0.0. Now what?

If your institution standardizes on ChatGPT, you upload the plugin to the OpenAI administrative console. OpenAI controls the review process, the distribution of the plugin to your team, and the visibility of that plugin across their enterprise customer base. If OpenAI decides to build a similar plugin natively, it can promote its own plugin in the enterprise catalog and bury yours. That is a commercial conflict of interest.

If you standardize on VS Code, Microsoft controls the extension marketplace, the signing requirements, and the enterprise deployment tools. Microsoft already has a long history of platform stewardship. But it also has the ability to make your plugin more or less visible depending on its own product roadmap.

If you standardize on Cursor, you are betting on a smaller company that moves fast but has less enterprise muscle. Cursor could decide to create a plugin marketplace with its own revenue share. The plugin standard does not cap that revenue share. It does not even define what a marketplace transaction looks like.

If you standardize on Kiro, you are betting on the browser becoming the agent substrate. Kiro can decide which plugins appear in its search results, which are sponsored, and which are surface-level recommendations. That is a full-stack distribution advantage.

The standard is silent on all of this. That silence is not a bug. It is the source of power.

Now, I want to be fair to the coalition. They would say that the spec is a packaging layer, not an application layer. They would argue that leaving distribution out is the only way to get five competitors to agree on anything. They would point to the fact that the standard shipped, which is more than the DAWN working group has done.

They are not wrong. But the strategic goal of a package format is not the same as the strategic goal of an open ecosystem. The coalition has produced a container. The container is open. The ports are not.

The next big question is whether third parties will try to build neutral distribution infrastructure on top of the standard. A company could create a neutral plugin registry, a signing authority, a permission enforcement layer, and a governance layer that sits above the clients. That company could become the registry of record for the agent economy.

But that company would face an uphill battle. The platform operators already control the client. A neutral registry only works if the clients choose to support it. The clients have every incentive to support their own registries instead. Without a neutral registry, the ecosystem fragments into product-driven marketplaces.

In the crypto world, we saw the same thing with token discovery. Everyone agreed on the ERC-20 standard. But when it came time to discover tokens, nobody trusted a single registry. The market fragmented into centralized exchanges, decentralized exchanges, aggregators, and wallet-based discovery. Each layer extracted fees. The open standard was the substrate, not the profit center.

Agent Plugins will likely follow the same path. The substrate will be open. The profit centers will be the registries, marketplaces, gateways, and governance planes that build on top of it. Each will compete for the privilege of being the trusted middleman.


Now let me bring in the control plane war.

The trust gap in Agent Plugins is not a temporary oversight. It is a permanent business opportunity. And the first movers are already positioning themselves.

OpenAI Presence launched in July as a governance-focused control plane for enterprise agent behavior. That is the exact market signal. A governance plane sits above the agent plugins, intercepts every action, applies policy, and enforces permissions. It is the missing security layer in the plugin ecosystem. It is also a proprietary layer atop an open standard.

The sequence is telling. Ship an open plugin standard. Watch enterprises panic about trust. Sell them a proprietary governance plane. It is the same playbook used by crypto custodians, exchange operators, and Layer2 bridge providers. The open protocol creates the need. The proprietary platform harvests the value.

Let me outline the control plane stack. At the bottom, you have the agent client—VS Code, Cursor, ChatGPT, Copilot, or Kiro. Above that, you have the plugin execution runtime, which loads the plugin and interprets the manifest. Above that, you have the MCP gateway, which brokers connections to tools and data sources. Above that, you have the policy engine, which decides what actions are allowed in a given context. Above that, you have the audit layer, which records everything for compliance. And at the top, you have the admin console, where enterprise administrators set rules and review incidents.

The Agent Plugins standard only touches the packaging layer. It does not define the runtime, the gateway, the policy engine, the audit layer, or the admin console. That is five distinct layers of proprietary value waiting to be built.

Every major platform operator wants to own those five layers. But so do third parties. Cloud providers want to be the MCP gateway. Security companies want to be the trust and compliance layer. Observability companies want to be the audit layer. Identity providers want to be the permission model.

The plugin standard creates a perfect greenfield for all of them.

In my monitoring work, I can sense the tremor before the earthquake hits. The tremor here is the structural pressure building between the open packaging standard and the proprietary trust layer. When that pressure releases, we will see the first wave of enterprise plugin marketplaces, each promising to be the safe distribution channel. They will all be built on the open standard. They will all be gatekeepers.


The most interesting thing about the agent economy is not the standard that just shipped. It is the company that did not show up.

Anthropic is absent from the coalition. This is worth pausing on.

Anthropic authored the underlying Agent Skills specification. Anthropic authored the .claude-plugin format that informed the standard. Claude Code is the AI coding agent that many developers love because it is deeply integrated into the terminal and the repo. And yet, when August 6 arrived, Claude Code was not among the launch clients. No Anthropic representative sits on the TSC.

The absence suggests a deliberate strategic choice.

Claude Code's plugin format supports a broader feature set. It includes custom subagents, hooks, LSP servers, and background monitors. That is a production-grade set of primitives. The coalition's portable standard is intentionally minimal—portable but shallow. Anthropic is not choosing to be left out. Anthropic is choosing to build a richer, platform-specific experience.

This is exactly the kind of strategic tension I have seen in every major platform battle. The integrated player sacrifices universality for depth. The standard coalition sacrifices depth for universality. Both are viable strategies. Which one wins depends on where the economic value concentrates.

For Anthropic, the bet is that the enterprise market will pay more for a tightly integrated agent platform with a strong trust model and rich control than for a portable plugin that can be copied anywhere but trusted nowhere. That sounds counterintuitive. Open standards usually win. But they do not always win the enterprise layer.

Look at the history of computing. Linux won the server market. But Red Hat built a business on top of Linux by selling support and management. Android won the smartphone market. But Google captured the value through the Play Store and the permission model. Open source wins the substrate. Proprietary wins the trust layer.

Anthropic's richer plugin format may be the enterprise trust layer. The coalition's minimal portable format may be the commodity substrate. If that is the case, then the open standard has won the packaging battle but lost the economic war.

The second gap is the trust model. This is not a detail. It is the core of the enterprise go-to-market.

Version 1.0 contains no provenance or trust model. Per VS Code documentation, plugins are implicitly trusted at the moment of installation. There are no cryptographic signatures. There is no standardized permission model. There are no sandboxing requirements in the spec. That is not a nitpick. That is a wide-open door for security incidents.

Let me take you through a scenario from my audit experience. I have reviewed numerous decentralized custody solutions. One of the first things I check is whether the system has a mechanism to prove the origin of a piece of code. Without that mechanism, the entire system is a house of cards. A malicious actor can substitute a plugin, a dependency, or an entire MCP server, and the user may never notice.

Based on my audit experience, I can state the obvious: an agent plugin that is trusted implicitly can become a remote execution primitive. It can read environment variables. It can access file systems. It can call MCP servers with the same credentials the agent has. It can silently exfiltrate data. In enterprise environments, this is the equivalent of handing an attacker a key card.

The spec's omission of trust infrastructure is not a technical failure. It is a strategic choice. The coalition chose to ship first and secure later. But every day that passes with no trust model creates a revenue opportunity for whoever ships a governance layer first.

The gap also explains why OpenAI launched Presence in July. Presence is not an extension of the plugin standard. It is a separate layer that governs the plugins. OpenAI is not waiting for the standard to solve trust. It is building the trust layer itself.

That is a power move. If Presence becomes the default governance console for enterprise agents, OpenAI does not need to control every client. It controls the policies that run on top of the plugins. The client becomes a commodity. The control plane becomes the product.


The current market cycle is a bull market for agent infrastructure. The euphoria is real. Every major vendor is trying to capture a slice of the agent economy. But bull markets have a tendency to mask technical flaws. The missing trust model is a technical flaw. The fragmentation of distribution is a structural risk. The lack of a neutral registry is a gap.

You have to see through the marketing with the eyes of a code auditor. That is what I did with Layer2 projects that promised decentralized sequencing but actually operated centralized sequencers. That is what I am doing now with Agent Plugins 1.0.0.

The standard is a good start. It is not a finished ecosystem. The next six months will be more important than the announcement itself.

Let me outline what I will be watching in the next ninety days.

First, compatibility. The TSC has five major clients. The real test is whether the same plugin file can be installed, configured, and run with the same experience in each client. I expect friction. For example, the way VS Code handles plugin installation may differ from how ChatGPT handles it. The spec does not define installation. If each client installs plugins in a different way, the portability promise is largely theoretical.

Second, provenance. Watch for the first enterprise-grade plugin signing standard. If a credible third party introduces a signing and verification layer for Agent Plugins, that third party becomes a power broker. Vercel, with its lead maintainer seat, could try to make itself the registry of record. Microsoft could push GitHub signing as the default. Amazon could suggest AWS Signer. Each of these is a possible power grab wrapped in a security solution.

Third, permission models. The plugin spec leaves permissions to the client. The first client to ship a robust permission prompt will set the user expectation. The first client to ship a weak permission prompt will create a security scandal. In a world where users click through dialogs, the most secure permission model will still lose. The enterprise will demand policy enforcement at the MCP gateway level. The gateway becomes the new firewall.

Fourth, Anthropic's move. If Anthropic builds a plugin marketplace for Claude Code with a rich trust model, it could become the enterprise standard by default. The coalition will then be forced to adapt. But adapting an open standard is slower than building a proprietary ecosystem. Anthropic may win the high-value enterprise segment while the coalition wins the hobbyist and mid-market segment.

Fifth, DAWN. The IETF process may eventually deliver a discovery layer. But by then, the market will have already adopted client-specific discovery mechanisms. The DAWN protocol will arrive too late. This is the fate of most standards bodies that cannot keep pace with shipping ecosystems. The market moved on August 6. The IETF will spend the next two years catching up.


Openness at the packaging layer does not mean openness at the distribution layer. The coalition has lowered the barrier to building agent skills. It has not lowered the barrier to controlling the agent economy. The real action will happen in the registries, the trust layers, the permission models, and the MCP gateways. Each of those layers will be controlled by someone.

The standard is the free ticket. The gate is the premium seat.

The industry chose shipping over consensus. Now it has to choose trust over fragmentation. If the coalition fails to address the trust gap and lets distribution become a series of walled gardens, the open plugin standard will become a shared language for a closed market. If a neutral third party builds a trustworthy control plane on top of the standard, the agent economy could remain genuinely open.

I have been in the market long enough to know which outcome is more likely. The standard will survive. The gatekeepers will multiply. The question is whether the agent economy learns the lesson that crypto learned too late: the protocol is not the product. The market is the product. And the market is always built by someone.

Pulse on the chain, breath in the market. The standard is out. The gatekeepers are watching. The next phase is about to begin.