How do I secure plugins and skills in AI coding agents?

Treat every plugin or skill as third-party code with the same reach as the developer running the agent. In 2026 that means: keep the agent itself current (Claude Code 2.1.179+, Codex 0.146.0+ for the Plugin4Shell fix); turn off background auto-update or gate it on review; install only from marketplaces you control or that are hosted on GitHub, which rejects SHA-shaped branch names; verify the resolved commit after checkout (git rev-parse HEAD must equal the pinned SHA); run agents in a sandbox or container with least-privilege credentials; keep an allow-list of plugins per repo; and protect the repositories behind your own plugins with 2FA, branch protection and signed commits.

Is SHA pinning enough to protect AI agent plugins?

Not on its own. SHA pinning only works if the installer verifies that the checkout actually landed on the pinned commit. The Plugin4Shell vulnerability disclosed September 18, 2026 showed that Claude Code, Codex, GitHub Copilot and Gemini CLI all wrote the pin but never checked it, so an attacker who controlled a plugin's repository could serve different code under the same pin. Pinning plus post-checkout verification plus a host that forbids hash-shaped branch names is the minimum.

Should I turn off auto-update for AI coding agent plugins?

For anything with access to production credentials, yes, or replace it with reviewed updates. Background auto-update is what turned Plugin4Shell from an install-time bug into a zero-click one: when a marketplace bumps a pin, already-installed plugins re-run the vulnerable checkout with no user action. Keep auto-update on for the agent binary itself (that is how you receive security fixes) and off for plugins until you have a review step.

What is the safest way to run an AI coding agent?

In an isolated environment with scoped credentials: a container, VM or the vendor's cloud sandbox; a dedicated git identity with access only to the repos in scope; short-lived tokens instead of long-lived personal access tokens; no access to password managers, cloud consoles or production databases; and a network egress allow-list where possible. Separate browser profiles for any browser MCP server, with no banking or admin logins.

Quick Answer

How to Secure AI Coding Agent Plugins and Skills in 2026

Published: September 19, 2026

Why this matters now

By 2026 the four biggest coding agents — Claude Code, OpenAI Codex, GitHub Copilot and Google’s Antigravity (successor to Gemini CLI) — all install third-party plugins and skills from marketplaces, and most update them in the background. A plugin runs with the same reach as the developer: their repos, their tokens, their shell. Security researchers have now shown every link in the attack chain works at scale:

Getting in: AIR Security published a benign-looking skill that spread to 26,000+ agents before it was pulled.
Taking over: its SkillJacking research found 925 skills already in use whose upstream repositories had been hijacked, reaching 134,000 agents.
Defeating the safeguard: Plugin4Shell (September 18, 2026) showed that SHA pinning — the industry’s answer to rug-pulls — was written but never verified in all four agents, giving zero-click remote code execution via auto-update.

This guide is the checklist that survives the next one of these.

Step 1 — Patch the agent first

The agent binary is where pins are resolved, so the agent is where fixes land. Minimums as of September 19, 2026:

Agent	Safe version	Notes
Claude Code	2.1.179+	Plugin4Shell fix; 2.1.277 (Sep 18) also reads `AGENTS.md` as a fallback to `CLAUDE.md`
Codex	0.146.0+	Plugin4Shell fix; `codex mcp-server` binary removed Sep 5 — migrate to the app server
GitHub Copilot	No fix yet	Treat marketplace plugins as untrusted until Microsoft ships one
Gemini CLI	Deprecated	Not patched; migrate to Antigravity, which has no plugin-pinning system to bypass

Keep auto-update on for the agent itself — that is how you get security releases — and check --version in CI images, which drift.

Step 2 — Change the auto-update policy for plugins

Background plugin updates are the default in Claude Code and Codex. Decide per environment:

Developer laptops with production access: off, or reviewed. A weekly “update plugins” task with a human reading the diff beats silent updates.
Throwaway sandboxes: on is fine; nothing there is worth stealing.
CI agents: pin and never auto-update; rebuild the image to upgrade.

Step 3 — Pin and verify

Pinning is a promise the installer must keep. If you write your own installer, harness or internal marketplace, add the one assertion the big four were missing:

git clone <plugin-repo> ./plugin
git -C ./plugin checkout <pinned-sha>
test "$(git -C ./plugin rev-parse HEAD)" = "<pinned-sha>" || exit 1

Check the resolved HEAD, not the ref you asked for; the Gemini CLI variant of Plugin4Shell slipped through exactly because checkout FETCH_HEAD can resolve to a branch named FETCH_HEAD. Prefer git fetch origin <sha> && git checkout --detach <sha> over cloning the default branch at all.

Better still, pin to a content hash of the plugin tree (or a signed release artefact) rather than a git ref, so the host’s branch rules stop mattering.

Step 4 — Choose hosts and marketplaces deliberately

GitHub rejects 40-hex branch names; Bitbucket and self-hosted git allow them. If you must use a git-ref pin, restrict marketplaces to GitHub-hosted repositories.
Run your own marketplace for anything used by more than a handful of people: a fork of each approved plugin, in an org you control, with branch protection. Community marketplaces are discovery, not distribution.
Allow-list per repository. Keep a checked-in list of permitted plugins/skills (name + source + pin) and have the agent’s project config reference only those.

Step 5 — Review skills like code, because they are

A “skill” is usually a markdown file plus scripts. Review both:

Instructions: look for directives that exfiltrate (send the contents of ~/.ssh), disable safeguards, or fetch remote instructions at run time.
Scripts: any network call, any curl | sh, any credential file read.
Frequency: re-review on every pin change, not just first install. The Plugin4Shell rug-pull happens after the benign version was approved.

Step 6 — Contain the blast radius

Assume a plugin will eventually go bad and design so it does not matter much:

Run agents in a container, VM or the vendor’s cloud sandbox (Codex cloud, Claude Code cloud sessions, Copilot’s sandbox, Antigravity’s managed environments). Local execution is convenient and unbounded.
Scoped git identity: a dedicated deploy key or fine-grained token per repo; never a personal access token with org-wide scope.
Short-lived cloud credentials via OIDC or a credential broker; no static keys in the agent’s environment.
No access to password managers, cloud consoles or production data from the agent’s user account.
Egress allow-list where you can: registries, your git host, the model API, nothing else.
Browser MCP servers in a separate profile with no banking, admin or password-manager sessions — prompt injection from web pages against a session-holding agent is unsolved.

Step 7 — Protect the plugins you publish

Both Plugin4Shell paths begin with an attacker controlling a plugin’s upstream repository. If you maintain one:

2FA on every maintainer, branch protection on the default branch, and signed commits or tags for releases.
Do not let the repo go stale. RepoJacking and SkillJacking target abandoned or renamed repositories; archive explicitly if you stop maintaining.
Publish release artefacts with hashes so marketplaces can pin content, not refs.

Step 8 — Monitor and rehearse

Log every plugin install and update (agent, plugin, source, resolved commit) centrally.
Alert on a pin change that did not come from your review process.
Rehearse revocation: can you remove a plugin from every developer machine and CI image in an hour? If not, that is the next project.

A one-page checklist

Agent patched (Claude Code ≥ 2.1.179, Codex ≥ 0.146.0; Copilot plugins frozen; Gemini CLI retired).
Plugin auto-update off or reviewed on privileged machines.
Pins verified after checkout (rev-parse HEAD equals pin), or content-hash pins.
GitHub-hosted or self-run marketplaces only; per-repo allow-list.
Skills reviewed on every pin change.
Agents sandboxed with scoped, short-lived credentials and egress limits.
Your own plugin repos: 2FA, branch protection, signed releases.
Central logging, pin-change alerts, tested revocation.

For the vulnerability that prompted this list, see What Is Plugin4Shell?.