A shared agent-plugin format is a shared supply chain

Five rivals, one package format

Every dependency you install in one click is a dependency that runs in one click when the click was not yours. Keep that thought. This week, OpenAI, AWS, Cursor, GitHub and Microsoft jointly backed Agent Plugins 1.0.0, a portable package format for reusable AI-agent components. The New Stack reported the news on 2026-08-08 and framed it as five AI rivals agreeing on a shared plugin standard.

The reach is the story. If you build a plugin for one of those vendors' agents, you now have a plausible route to running the same artifact under the other four, without a rewrite each time. Container images did the same trick for workloads. RSS did it for feeds. Neither turned out to be neutral from a security angle, and neither will this.

The verdict, up front

Portable plugin formats are good for developer velocity and awkward for anyone who has to say yes or no to a specific plugin running in a production CI account. That is the trade. The upside is real: fewer forks and less rewrite tax across five ecosystems, plus one honest answer to "which agent do I bet on?" The bill lands in provenance. When the same artifact runs in five agent runtimes, five different groups of humans decide what a "trusted publisher" is, and five different trust roots decide what "signed" means. The lowest common denominator will win the argument by default.

Ask yourself: on your current CI, when a developer adds a new third-party action to a workflow, how many people review that change before it lands on a runner that holds your OIDC tokens? If the honest answer is "one, and only when I nag them", a cross-vendor plugin format is not going to fix your review culture. It will just make the same tired shortcut easier from any of five ecosystems.

What a shared format has to prove

A portable package format is a solved problem in shape (OCI figured it out) and an unsolved problem in trust. The interesting questions for CI/CD teams:

• Who publishes, and what does "publisher" mean across the five backers?
• What signing scheme is expected, and can any of the runtimes refuse to load an unsigned plugin?
• What runtime capabilities does a plugin declare, and can a CI admin block a plugin whose declared capabilities exceed policy?
• Can a specific digest be pinned across all five runtimes, or does each one resolve "latest" its own way?

None of those are answered by the format existing. All of them are answered by whichever runtime you actually deploy the plugin in, which is where CI/CD teams live.

How popular tools would carry a shared plugin format

Say the format ships and stabilises. Where does the artifact live in your pipeline? A few honest options:

• GitHub Actions. The Marketplace already hosts a large library of reusable actions and a documented publisher-verification badge. Strength: reach and social proof. Weakness: tag-vs-SHA pinning is still a discipline problem, not a platform default.
• GitLab CI/CD Catalog. Reusable components with project-level access controls and a single auth story for private catalogs. Strength: governance is coherent inside one org. Weakness: the catalog is smaller than GitHub's, so cross-org discovery is thinner.
• CircleCI Orbs. Has a certified-publisher tier and a signed publishing pipeline. Strength: an explicit trust hierarchy built into the ecosystem. Weakness: single-vendor scope; a portable format is more interesting when it can leave.
• Jenkins plugins. The archetype for "self-hosted, you own the risk". Strength: full runtime control and network isolation. Weakness: the CVE backlog on long-tail plugins is famously the sharp edge; you inherit the maintenance.
• Buddy. Pipeline actions are declared in the same YAML that ships the deploy, so adding a new plugin is a diff a reviewer sees in the same pull request as the code that will call it. Concrete reason to reach for it: the plugin adoption and the code that depends on it move through review as one change, not two. For an org-wide public marketplace with signed publishers, GitHub Actions remains the stronger fit.

Pick one for the plugin catalog, whichever one you pick, and write down the pin policy the same day.

What I would ask before shipping one

Before you approve the first Agent Plugins 1.0.0 artifact into your pipeline, ask for its provenance attestation, its pinned digest, and the runtime capability list. Reference a plugin like this in a workflow:

uses: some-org/some-agent-plugin@sha256:<full-digest>
with:
  capabilities: [read-repo, comment-pr]  # denied by default

If any of the three answers is "we will add that later", the plugin is not portable. It is contagious. Portable is the goal. Contagious is the default.