Agent Plugins Got Distribution, Registry, and Isolation in 48 Hours

The average developer running AI coding agents has 18 skills and plugins installed. Some environments have more than 80 MCP servers live at once. Every one of those is executable software running on a developer's machine, with their credentials, their filesystem access, and their network permissions. Until this week, almost none of them had versioning, provenance, or an audit trail.

Three releases in 48 hours changed that. Cursor shipped team marketplaces and a unified Customize page. JFrog put agent plugins inside Artifactory as governed artifacts. Claude Code added credential sandboxing to stop sandboxed commands from reading secrets. Each one solves a different part of the same problem: agent plugins stopped being config files and became real dependencies that need real governance.

JFrog made the argument most directly in a June 23 blog post introducing Agent Plugins Repositories. The framing is blunt: "A plugin is not a preference file. It is executable software." Today's plugins bundle hooks that run shell commands, MCP servers that hold credentials, and skills that rewrite repository files. When a developer installs a plugin from an unmanaged GitHub repo or copies commands from a Slack channel, that code executes with full developer permissions and no version control.

The scenario JFrog describes is not theoretical. A malicious update pushed to a plugin in a public GitHub repo propagates to every developer who synced it within hours. Arbitrary shell commands run on their machines, inside source code, under their credentials. No alert, no audit trail, no fast containment path. This is the same supply-chain attack pattern that hit npm and Docker, applied to a surface that most enterprises have not brought under any governance at all.

Cursor builds the distribution layer

Cursor's 3.9 release on June 22 made plugins easier to distribute and discover than they have ever been. The new Customize page consolidates plugins, skills, MCPs, subagents, rules, commands, and hooks into one interface, manageable at the user, team, or workspace level. A marketplace leaderboard shows the most popular plugins across the team.

Team marketplaces now support imports from GitLab, BitBucket, and Azure DevOps, not just GitHub. On Enterprise plans, admins can mark plugins as required or optional, and distribution groups can sync with SCIM directory groups. Plugin canvases ship prebuilt setup templates: the Hex Canvas for data visualization, the Atlassian Canvas for Jira and Confluence issues.

The Cursor plugin spec is more structured than most people realize. A plugin requires a .cursor-plugin/plugin.json manifest with up to 17 fields, strict kebab-case naming validation, and additionalProperties: false enforcement. Plugins can bundle rules, skills, agents, commands, MCP server definitions, hooks, and static assets into a single distributable package. The marketplace lists official plugins from AWS, Figma, Linear, Stripe, Datadog, Slack, and Databricks, each manually reviewed before listing.

This is the distribution layer: a managed way to find, install, and enforce plugins across a team. What it does not provide is versioning, immutability, or artifact-level audit trails. That is where JFrog comes in.

JFrog builds the registry layer

JFrog's new Agent Plugins local repositories in Artifactory treat agent plugins the same way npm packages and Docker images are already treated. Signed, immutable releases. Unified access control through existing enterprise ACLs. Complete audit trails that let you search metadata to find every machine and pipeline that pulled a specific version.

The integration model differs by coding tool. Claude Code gets native integration: Artifactory becomes the corporate marketplace, and developers browse and install approved plugins without leaving their coding environment. For Cursor and Codex, the JFrog CLI handles download, verification, and installation into the correct local folders.

One gap: Cursor's team marketplace currently requires a GitHub or GitHub Enterprise source. JFrog submitted a feature request for HTTP marketplace support, the standard Claude Code already uses, so enterprise teams can point Cursor at a governed registry instead of a Git repo. The Cursor team is tracking it.

JFrog's argument for why this matters draws a direct line to previous supply-chain crises. "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."

Security scanning for CVEs and license issues is listed as coming soon. But the foundation is there: versioned, signed, auditable artifacts that behave like real dependencies instead of moving Git targets.

Claude Code builds the isolation layer

While Cursor handles distribution and JFrog handles registry governance, Claude Code's v2.1.187 release on June 23 addressed a different piece: what happens when a plugin runs on your machine.

The new sandbox.credentials setting blocks sandboxed commands from reading credential files and secret environment variables. This matters because Claude Code's sandbox already restricts filesystem and network access for Bash commands, but credential files like .env and .aws/credentials were still readable by sandboxed processes. A prompt-injected agent or a malicious plugin hook could exfiltrate secrets through the sandbox boundary.

This release also added org-level configuration, so security teams can enforce sandbox and credential policies across an entire organization rather than relying on individual developer settings. A GitHub issue from May documented that sandbox.filesystem.denyRead patterns did not actually prevent Claude Code from reading sensitive files, transmitting their contents to Anthropic servers. The sandbox.credentials setting appears to be the response: a dedicated credential isolation layer rather than filesystem deny patterns that were silently ignored.

The governance checklist

If you are deploying AI coding agents, the plugin supply chain is now a real operational concern. The three releases this week map to three questions worth asking:

Do you know what plugins, skills, and MCP servers your developers have installed? Snyk's telemetry from 9,700 environments found that 43% of developers run two or more AI coding environments simultaneously, and more than half have MCP servers installed. One in 12 of those setups contains a high or critical security finding. In most organizations, no one has a complete inventory.

Can you control what gets installed? Cursor's team marketplaces with required and optional distribution give admins enforcement power at the team level. JFrog's Artifactory integration gives platform teams signed, versioned artifacts with ACLs. If your developers are pulling plugins from random GitHub repos, neither layer is in place.

Can you isolate what plugins can do? Claude Code's sandbox credentials and org-level configuration let security teams enforce credential isolation without relying on developers to configure deny rules correctly. The sandboxing built into Claude Code reduces permission prompts by 84% in Anthropic's internal testing while maintaining filesystem and network boundaries.

The pattern mirrors what happened with npm, Docker, and every other package ecosystem that grew faster than its governance. The tools work. The productivity gains are real. The attack surface is also real, and it grows every time a developer installs a new plugin without anyone reviewing what it does.

Sources

• Cursor 3.9 changelog, cursor.com/changelog (June 22, 2026)
• "Introducing Agent Plugins Repositories," JFrog blog, jfrog.com (June 23, 2026)
• Claude Code v2.1.187 release notes, code.claude.com (June 23, 2026)
• Snyk Evo Agentic Development Security announcement, snyk.io (June 23, 2026)
• Cursor plugin reference documentation, cursor.com/docs/reference/plugins
• Claude Code sandboxing documentation, code.claude.com/docs/en/sandboxing.md