How should security teams vet extensions and plugins for coding agents?

The risk is the update, not the install#

Cursor confirmed that build 2.1.313 of the Claude Code extension was malicious, and said the incident affected at most 5,000 users. Anthropic released 2.1.314.

The malicious build tried to add an attacker-controlled SSH key to authorized_keys, enable the local SSH service and open a reverse SSH tunnel. That's a remote way into a developer laptop.

It carried a name developers already trusted. A review done when the extension was first approved would have passed. The bad build showed up later, as an update.

MCP servers follow the same pattern. The attacker behind a Postmark MCP server package built trust over 15 versions, then added a backdoor in version 1.0.16. Koi Security said it was downloaded about 1,500 times in a week.

An extension runs as the developer. Whatever that user can reach (SSH keys, cloud credentials, the source tree), the extension can reach too.

What to do before anything installs#

Start with the boring controls. They catch most of it.

• Allow-list sources and publishers. Decide which marketplaces and registries you accept. Default to none, then add.
• Pin versions. Don't let a marketplace push a new build to your fleet on its own schedule. Re-review before you move the pin.
• Mirror what you approve. An internal registry you control beats a public one you can only watch.
• Review what it can do, not the star count. Check what the extension can run, where it can connect, and who can publish to it.
• Name an owner. Every approved extension gets a person who answers when it changes.

What Claude Code's built-in controls do#

Claude Code has real plugin controls. Per Anthropic's docs, strictKnownMarketplaces is an allowlist of marketplace sources, and both the allow and block lists apply before anything downloads and again at session start. disableSideloadFlags rejects --plugin-dir, which the allowlist alone doesn't block.

For visibility, claude_code.plugin_installed records each install and claude_code.plugin_loaded records each enabled plugin at session start. Send those to the place your team already looks.

Know the limits:

• The allowlist matches marketplace sources. It doesn't restrict individual entries inside an allowed marketplace.
• It governs Claude Code plugins. IDE extensions in Cursor or VS Code, and MCP servers set up outside it, need their own controls. The 2.1.313 build was an IDE extension.
• It decides which sources are trusted. It can't tell you whether a new build from a trusted source is still clean.

Other agents ship their own toggles, with different names and different gaps. If you run several agents, plan on reconciling several policies.

Inventory the fleet#

You can't vet what you can't list. Pull installed extensions, plugins and MCP servers from every laptop, per agent and per IDE, through the MDM you already run. Record name, publisher, version and install date.

Diff it weekly against your approved list. Anything unlisted, or on an unapproved version, is a ticket.

When an advisory lands, you want to answer "who has 2.1.313?" in minutes, not days.

Why install-time vetting misses tampered updates#

A pinned version protects you from a surprise update. It doesn't protect you from a version that was bad when you pinned it, or from a publisher account taken over before you approved it.

Signing helps with provenance. A signature tells you who shipped the build, not what the build does.

A fixed release replaces the extension. Don't assume it undoes what the bad one already did: treat any machine that ran the bad version as compromised and investigate it.

Where Harden fits#

Harden Agentic Integrity Foundation (AIF) runs on the developer laptop, outside the agent, at the agent's pre-execution hook. Every command, file edit and push the agent attempts is checked against the session's intent before it runs. Decisions are made locally, in about 28 ms, and nothing leaves the machine.

That covers the case where a bad plugin or MCP server steers the agent. A write to ~/.ssh/authorized_keys, or a secret headed for a network call, has nothing to do with the task the developer gave. Harden sees that action at the hook and can block it or ask a human, whichever plugin or tool prompted it.

Now the limits. AIF only sees what goes through the agent's hook, so it won't see an extension running its own code in its own process, and it doesn't contain a process that's already malicious. It's a layer on top of allow-lists, pinning and least privilege, not a replacement for them.

It starts watch-only, so you can see what agents and their tools do before you enforce. See securing agents on developer laptops, the security review before approving Claude Code and AIF's trust page.