Stop Treating Coding Agent Plugins Like Settings: Introducing Agent Plugins Repositories

Your developers install agent plugins every day: pulling from unmanaged GitHub repos, copying Cursor commands out of Slack, pointing Codex at a personal Git fork. Each of those is a new, uncontrolled distribution channel inside your software development lifecycle, and your platform team has zero visibility into any of it.

A plugin is not a preference file. It is executable software, and right now it’s arriving on developer machines with no versioning, no provenance, and no audit trail.

That’s a provisioning problem, a versioning problem, and a security problem. And it’s fixable.

What a plugin actually does

What started as simple system prompt text files has become structured plugin packages. Today’s plugins consolidate skills, slash commands, subagents, hooks, and MCP definitions into a single manifest, which local coding engines like Claude Code or Cursor parse and execute in full, on the developer’s machine, with the developer’s permissions.

That means:

• Hooks run shell commands on agent events, directly on the developer’s machine.
• MCP servers (Model Context Protocol, the open standard for wiring agents into tools and data) broker access to your machine and external systems and frequently hold credentials.
• Skills, commands, and subagents read and rewrite files in the repository the engineer is working in.

Here’s the scenario your security team should be losing sleep over: a malicious update is pushed into a plugin in a public GitHub repo your team points their agents at. Within hours, every developer who syncs pulls down code that executes arbitrary shell commands on their machine, inside your source code, under their credentials, with no alert, no audit trail, and no fast path to containment. You won’t know it happened until something breaks, or someone tells you.

This is not a hypothetical. It is the textbook supply-chain attack pattern, applied to a surface that most enterprises have not yet brought under governance. JFrog made the version of this argument for skills in Agent Skills are the New Packages of AI. Plugins raise the stakes further because they bundle execution, credentials and much more in one artifact.

Version control is not a package registry

The adopted default for hosting agentic assets was naturally Git. However, it is a version control system, not a package registry, and that distinction matters enormously once you accept that plugins are executable software.

Pointing environments at a Git repo or shared branch means you’re tracking a moving target. Tags are mutable, branches shift, and there is no guarantee that what ran yesterday runs today.

Without immutable, pinned versions, an agent plugin is an untracked, unreproducible input to every build your team ships. Two engineers tracking “the latest” on the same branch can run different code on the same day, and you have no way to know why. When something breaks, there is no known-good version to revert to, because there are no versions at all.

Versioning is the foundation everything else is built on. It turns a plugin from an informal artifact into a real dependency: something you can lock, diff, review, promote, and roll back. And once an asset is versioned, you can govern it. You can sign it, scan it, control who publishes and who consumes it, and trace exactly which machines pulled a given version. Without versioning, security controls have nothing to attach to. That is why these two pillars go together: versioning makes plugins manageable, and security makes them trustworthy.

What governed distribution actually looks like

The answer is not separate infrastructure for AI tooling. It is bringing agent assets into the same pipeline you already run. That is what JFrog Artifactory’s new Agent Plugins local repositories provide with the Plugins standard. The same controls protecting your npm packages and Docker images now extend to agent assets:

• Signed, immutable releases: every plugin version is a real artifact with provenance you can prove.
• Unified access control: the same enterprise Access Control Lists (ACLs) that govern your build targets apply to your agent repositories.
• Complete audit trails: when a vulnerability surfaces in an MCP server, you can search Artifactory metadata to identify every machine and pipeline that pulled that exact version, and act immediately.
• Single-copy storage: no footprint bloat as the same plugin propagates across teams.
• Security scanning (coming soon): CVE and license checks join the same pipeline your other artifacts already run through.

Consumption stays native. For Claude Code, Artifactory becomes the corporate marketplace itself: developers browse, install, and update approved plugins without leaving their coding environment.

For Cursor and Codex, the JFrog CLI downloads, verifies, and installs approved plugins into the correct local folders on the developer’s machine. Note that Cursor’s team marketplace currently requires a GitHub or GitHub Enterprise source. A feature request has been submitted to the Cursor team to add HTTP marketplace support, the same standard Claude Code already uses, so enterprise teams can point Cursor directly at a governed registry instead of a Git repo. The Cursor team is tracking it, and developer demand is what moves the timeline. If this matters to your organization, add your +1 to the thread.

The window to act is now

You centralized npm to stop dependency confusion attacks. You governed Docker to secure container runtimes. Agent plugins are the next package surface, and they are younger and less hardened than either of those were when you made those calls.

The cost of acting now is low: one governed registry, a familiar set of controls, and a distribution channel your developers barely notice. The cost of waiting is a supply-chain incident that teaches the lesson the hard way, at the expense of your source code, your credentials, and your customers.

Set up an Agent Plugins repository in Artifactory, or reach out to our team to hear more.