What Installing a Salesforce Plugin Actually Gives It

claude plugin install salesforce-development@claude-plugins-official

That is one line, and Salesforce's developer documentation presents it exactly that way, as a one-step setup so your coding agent can build, modify, debug, and deploy agents without extra configuration. What the line actually does is deliver three separate kinds of artifact into a development environment that is already authenticated to a Salesforce org: instructions the model will treat as authoritative, MCP server configuration, and hooks that run on lifecycle events.

Every previous post in this series looked at agents running inside an org at runtime, where the controls are permission sets, grounding sources, and action scoping. This one looks at the other end of the pipeline, at the agent sitting outside the org holding deploy rights, because Winter '27 makes that agent something an enterprise is expected to install rather than assemble.

What Salesforce shipped

Agent Skills and Plugins was announced on August 31 as one of the top ten items in the Winter '27 release. The release goes generally available on October 12.

Salesforce launched with over 100 prebuilt skills covering common platform workflows, and companies can author and publish their own skills into the same registry. Plug-ins bundle skills together with the MCP connectors, hooks, and configuration an agent needs, so that, in Salesforce's words, a single install brings a complete, governed capability to any surface. The first of those is the Salesforce Development plug-in, live in the Claude Code marketplace now.

The scope is broader than a developer tool. Salesforce's product page states that Agent Skills and Plugins work across Claude, Claude Code, Cursor, Windsurf, Slack, Agentforce, and ChatGPT, and describes skills and plugins as structured, test-driven, and governed, in contrast to prompts.

What the first-party plugin gets right

The Salesforce Development plugin is the well-governed case, and it is worth saying so before going further.

The Claude Code listing shows it as Anthropic Verified and published by Salesforce. It resolves capabilities in three tiers, skills first, then the Salesforce CLI, then Salesforce-hosted MCP servers, which is a sensible ordering that keeps the model from reaching for raw API access when a validated path exists. The listing describes deploy and retrieve as having safety gates. The skills themselves live in a public repository at forcedotcom/sf-skills, so anyone can read what they contain before installing.

As starting positions in this category go, that is a good one. Nothing that follows is a claim that this plugin is dangerous. The concern sits one step out: the first install establishes a pattern, and the second, third, and internally authored installs will follow it.

What a plugin install is, structurally

The bundle carries three kinds of artifact, and each one fails in its own way.

Skills are instruction files the model loads and treats as authoritative guidance about how to do a kind of work. They are natural language, and nothing in the format distinguishes a procedure from an instruction to do something else entirely.

MCP server configuration looks like inert JSON. What it specifies is a process to launch, and that process runs at the user's permissions. OX Security's analysis of this pattern calls it RCE-by-configuration, which describes the gap between what the file looks like and what it does.

Hooks bind shell commands to lifecycle events. Check Point Research demonstrated the practical form of this in February 2026, showing that hook configurations injected into a project's settings could execute arbitrary shell commands at agent initialization, before any per-action approval was in play. That work was published as CVE-2025-59536 at CVSS 8.7.

The wider security research community has spent 2026 working on this artifact class. Snyk's ToxicSkills research found that roughly 37 percent of public skills examined contained a security flaw. Antiy CERT confirmed 1,184 malicious skills in the ClawHub incident. NVIDIA now runs skills through a scanner as part of its publication pipeline and is experimenting with cryptographic signing so that a downloaded skill can be verified as authentic and unchanged. OWASP has a draft Agentic Skills Top 10 in progress, with malicious skills and supply chain compromise as its first two entries. Mandiant published guidance last week recommending that organizations treat AI coding assistants, local plugins, and MCP servers as privileged development components rather than productivity tools, sign and verify them before execution, and put internal skills and hooks under strict code review.

None of that research was written about Salesforce, and all of it applies to the artifact Salesforce has now made installable in a single line.

How a bundle actually reaches a developer

The distribution mechanics matter more than the install command, and they are documented.

In the Claude Code VS Code extension, installing a plugin requires choosing a scope. One of the three options is described as shared with project collaborators. A plugin installed at that scope travels with the repository, so it can arrive in a teammate's environment through a commit rather than through a decision that teammate made.

There is also an install link. A URL of the form vscode://anthropic.claude-code/install-plugin?plugin=salesforce-development opens the editor, opens the plugin dialog, and lands on the scope choice for that plugin. The plugin parameter is required. An optional marketplace parameter accepts any GitHub owner/repo or https URL, and defaults to the official Anthropic marketplace when omitted. Worth being precise here, because the mechanism is easy to overstate. Nothing installs until the person picks a scope, so nobody acquires a plugin from clicking a link alone. What the link does is put them one choice away, arriving in a message rather than at the end of a decision they went looking to make.

One further detail changes what remediation looks like. In the extension's management dialogs, hooks supplied by plugins are read-only, and plugin-supplied skills appear as locked rather than adjustable. Locking them is a reasonable integrity decision, and it also means the surface you would reach for to inspect or disable one piece of a bundle is not where that work happens.

Where this lands in a real environment

The environments where this matters most are the ones where the tooling is load-bearing. Ours is one. We build managed packages and integrations from VS Code with Claude Code in the panel, deploying into client sandboxes and production as part of normal delivery rather than as a trial.

What that produces, over time, is a workstation with several orgs authenticated at once and a development user carrying permissions well beyond read, because source tracking and deployment require it. That is the environment a plugin install lands in. At project scope it arrives through the repository, which means a teammate can receive it without having made a decision about it, and the review that catches a bad Apex class does not currently look at that path.

We are reworking that arrangement, and this release is the reason. Several authenticated orgs and a broad development user were defensible when the only things in the session were the CLI and the person driving it. A bundle format that carries hooks, arriving from a registry any customer can publish into, changes what that session is worth to someone else. The separation in decision five below is work we are doing on our own environments, not only recommending.

An earlier post in this series made the point that the CLI operates against whatever org you have authenticated, with your user's full permission set, and that this is usually what you want during development. That is still true, and what has changed is the rest of what now sits in the session alongside that authentication. A deploy safety gate asks before it pushes metadata, which is the protection working as designed. A hook bound to session start has already run by the time anyone is asked anything.

The word governed

Salesforce's announcement describes a plugin install as bringing a complete, governed capability. The product page describes skills and plugins as governed. The developer documentation page for Plugins and Skills describes open repositories you can browse, install, and contribute to, gives the install command, and contains no language about security, vetting, signing, or review.

I could not find published Salesforce guidance on who may publish into the customer-facing skills registry, what review a published skill receives before it appears there, or whether skill provenance is verifiable after install. That may be a documentation gap rather than an architectural one, and the registry may well have a review process that simply has not been written down yet. Either way it is the question to get answered in writing before October 12, because the answer determines whether the Anthropic Verified badge on the first-party plugin describes the registry or describes one plugin in it.

What to do about it

Six decisions, each tied to something above.

1. Inventory what is installed in every environment authenticated to a client or production org. Not just the plugin, the skills and MCP servers inside it. You cannot review a bundle you have not enumerated.
2. Pin plugin versions and treat an update as a code change. A skill that was safe at install is a different artifact after its next release.
3. Put internally authored skills and hooks through the same review as Apex. This is Mandiant's recommendation and it is the right one. A hook is a shell command with a trigger, and it deserves the review a shell command gets.
4. Make project scope a decision rather than a default. A plugin that travels with the repository is a team-wide dependency. That may be exactly what you want, but someone should choose it on purpose instead of inheriting it from whatever the install dialog suggested.
5. Separate the org authentication used for agentic development from anything production-privileged. The permissions that make source tracking work are not the permissions you want present in a session that just loaded instructions from a registry.
6. Decide who in your company may publish into your own skills registry, before someone does it informally. Salesforce has invited every customer to become a skill publisher. The first internal skill will be written by whoever needs it most urgently, and that person will not be thinking about review.

Close

Multi-Agent Orchestration put a delegation decision into a text box outside Setup, editable by someone with no admin access. Agent Skills and Plugins puts a capability decision on a developer workstation, where it can arrive through a repository or a link and land in a session already holding org credentials.

The pattern in both is that the decision moved somewhere the existing review process does not reach. Extending that process to cover a plugin bundle is ordinary work, and it is considerably easier while the only thing installed in most orgs is the verified plugin from Salesforce.

Sources credited

Salesforce (Winter '27 release announcement, August 31, 2026; Agent Skills and Plugins product page; Agentforce Developer Guide, Plugins and Skills), Anthropic (Claude Code plugin listing for Salesforce Development; Claude Code VS Code extension documentation), Check Point Research (hook configuration injection, CVE-2025-59536), Snyk (ToxicSkills), Antiy CERT (ClawHub), NVIDIA (verified agent skills and SkillSpector), OX Security (RCE-by-configuration), Mandiant (AI coding assistants as privileged development components), OWASP GenAI Security Project (draft Agentic Skills Top 10).