2.5 Plugins and marketplaces
Plugins and marketplaces bundle skills, connectors, agents, extensions, and actions — how to curate distribution and review updates like code.
Last reviewed: August 18, 2026
Plugins and marketplaces: what security teams need to know
Plugins make AI tools extensible. They can distribute skills, hooks, MCP servers, agents, commands, and other configuration. That packaging is useful because it gives teams a repeatable delivery path.
The same packaging creates a supply-chain risk. A plugin update can change instructions, add a hook, alter an MCP server, or shift permissions. Marketplace trust should start the review, not end it.
Common plugins and marketplaces security failures
A plugin is approved by name, then a later update adds new behavior.
Marketplace source and repository source are not compared.
Users can add unknown marketplaces.
A plugin bundles hooks or MCP servers that were not part of the original review.
No one owns plugin retirement when the business use ends.
Plugins and marketplaces security controls checklist
Maintain an approved plugin list with owner, marketplace, source repository, version, and review date.
Use private or known marketplaces where the platform supports it.
Review bundled skills, hooks, MCP servers, agents, and commands as separate risk objects.
Require signed releases, protected branches, or comparable provenance controls for internal plugins.
Review plugin updates before rollout to production groups.
Anthropic
Overview
Anthropic plugins can be used from Claude Code and Cowork. Packages can bundle skills, agents, hooks, MCP servers, commands, and other customization, while Cowork makes supported skills and plugins available across desktop, web, and mobile. Local MCP components still depend on Claude Desktop. Because one plugin can carry several kinds of power, review each component on its own terms.
Enterprise managed settings can restrict which plugins and marketplaces are available, so production groups can be limited to a private or approved marketplace while sandbox groups experiment more freely. Record the marketplace source and the plugin's source repository separately: a marketplace listing is a distribution path, not provenance.
Claude Tag can also use plugins as part of its channel-side configuration. That configuration is separate from the channel's service-account identity and Access bundles, so approve the plugin and the connected authority as two linked objects. A safe plugin with an over-broad bundle can still create an unsafe agent.
Anthropic documentation
OpenAI
Overview
The Plugin Directory is now the packaging and discovery layer across ChatGPT Work and Codex. Plugins bundle skills, apps, app templates, and MCP-backed capabilities into reusable workflows. Users can install them from Work on the web, Work or Codex in the ChatGPT desktop app, the Codex CLI browser, or the IDE extension. Teams can also publish through approved marketplace sources, which is where provenance and update review belong.
A plugin does not grant data access by itself: bundled apps still follow ChatGPT workspace app settings and source-system permissions, and existing Codex approval settings apply to plugin workflows. Two review details matter in practice: plugins can prompt users to connect or sign in to apps at install time or on first use, and uninstalling a plugin leaves bundled apps installed in ChatGPT until they are removed there.
OpenAI documentation
Applicable Harmonic guides for OpenAI
Frequently asked questions about plugins and marketplaces
What is an AI plugin?
An AI plugin is an installable package that extends an AI client with several kinds of capability at once: skills, MCP servers, app integrations, agents, commands, or hooks. Claude Code plugins and Codex plugins both follow this model and are distributed through marketplaces. The security consequence is that one install can grant instructions, tools, and execution paths in a single step.
Are marketplace plugins safe by default?
No. A marketplace listing is a discovery and distribution path, not a security review, and even curated listings tell you who published, not what the current version does. Compare the marketplace source against the actual source repository, review each bundled component, and re-review on update.
What should be reviewed inside a plugin?
Every bundled component as its own risk object: skills (instructions and scripts), hooks (code execution at lifecycle events), MCP servers (standing tool access), agents, commands, requested permissions, install-time prompts such as app sign-ins, and update behavior. A plugin approval that only read the description has reviewed the label, not the package.
Should companies run a private plugin marketplace?
For production use, yes, where the platform supports it: Claude Code marketplaces can be restricted through managed settings, and Codex teams can publish through their own repo or team marketplace sources. Private distribution gives security a controlled approval path, version pinning, and a known rollback point.
How often should plugins be reviewed?
Review high-risk plugins before every version update reaches production groups, since an update can add hooks or MCP servers that were not in the original review. Lower-risk plugins can ride a fixed cadence, with immediate re-review when distribution, permissions, or bundled apps change. One gotcha worth building into offboarding: uninstalling a Codex plugin leaves its bundled apps installed in ChatGPT until they are removed there.
Applicable regulations and frameworks
G.1 Map your controls to NIST AI RMF and CSF 2.0
This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.
G.3 DORA and AI resilience in financial services
Conditional: for a DORA-regulated workflow, this supports ICT asset, dependency, and third-party risk management.
G.6 Write an AI Acceptable Use Policy that holds up
This article supplies a technical or process control used to enforce the acceptable-use policy.
G.7 Ownership and RACI for AI security
This control depends on the ownership and evidence responsibilities defined in the RACI.
G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.
Related handbook guidance
Was this helpful?