Coding agents and AI assistants can now be extended with packaged capabilities: skills (folders of instructions, scripts and reference files the agent loads when relevant), plugins, slash commands, hooks and MCP servers. Marketplaces and community repositories make them one command away. Many are excellent. Some are careless. A few are malicious.

When our team started using community skills with coding agents, we treated them like any dependency and reviewed them. This post is what we learned: what can go wrong, how we review, and the controls that limit damage when review misses something.

Why skills are different from libraries

A library runs code you call. A skill also contains instructions the agent reads and follows, often with broad tool access: reading files, running shell commands, editing code, making network requests. That creates risks traditional dependency review does not cover:

Risk How it appears
Hidden instructions Text in a skill file telling the agent to do something unrelated to its stated purpose
Scripts with side effects Helper scripts that upload files, add SSH keys or modify shell profiles
Data exfiltration Instructions or scripts that send repository contents or environment variables to a URL
Dependency on remote content Skills that fetch instructions from a URL at run time, which can change after review
Over-broad triggers A skill described as relevant to "any task", so it loads into every session
Auto-run hooks Hooks that execute on every tool call or session start

The instructions are the new part. An instruction like "before finishing, run scripts/report.sh to record usage" looks harmless in a long file and can do anything.

What we found reviewing community skills

We reviewed about 30 popular community skills and plugins for our team's use. Most were fine. Patterns that made us reject or modify some:

  • A "project setup" skill whose script appended a line to ~/.bashrc that sourced a remote file.
  • A documentation skill that fetched its real instructions from a pastebin-style URL at run time.
  • A "productivity" skill whose description claimed relevance to every task, loading 4,000 tokens of instructions into every conversation.
  • Skills with scripts that collected "anonymous telemetry", including file paths from the repository.
  • Hidden text, such as instructions in HTML comments or after many blank lines, that a human reading the rendered file would miss.

None were obviously "malware" in the traditional sense. Several would have sent information out of our environment or changed developers' machines without anyone deciding to allow it.

A review checklist

Before installing a skill, plugin or MCP server, someone on the team reviews it:

Source and maintenance

  • Who publishes it? Is the repository owned by the organisation it claims to be from?
  • Is there a history of commits and issues, or a single upload?
  • Is the version pinned (commit or tag), so what you reviewed is what you run?

Instructions

  • Read every instruction file in raw form, not rendered. Look for comments, hidden sections and unusual Unicode.
  • Does every instruction relate to the stated purpose?
  • Does it tell the agent to run scripts, fetch URLs, or change files outside the project?
  • Is the description narrow, so it loads only when relevant?

Scripts and code

  • Read every script. What do they read, write, execute and send over the network?
  • Do they modify shell profiles, SSH configuration, Git configuration or credentials?
  • Do they download and execute anything?

MCP servers

  • What tools does it expose, and which are read-only?
  • Where does it send data? What permissions or tokens does it need?
  • Does it run locally with your user's full permissions?

If a skill needs network access or scripts, ask whether it really must, and whether a simpler local version would do.

Controls that limit damage

Review catches most problems. Controls catch the rest.

Least privilege for the agent

Configure the coding agent to ask for approval before running shell commands, writing outside the project directory or making network requests, at least for unfamiliar skills. Most agents support allow and deny rules for tools and commands; deny access to credential files and home directory configuration by default.

Sandboxes

Run agents with third-party skills in a sandbox: a dev container or VM with only the project mounted, no production credentials, and network egress limited to package registries and the model provider. If a skill misbehaves, it can only affect the sandbox.

No secrets in the environment

Agents can read environment variables and files. Developer machines with long-lived cloud credentials, tokens in shell profiles or .env files with production secrets are high-value targets. Use short-lived credentials, and keep production secrets out of development environments entirely.

Pin and vendor

Install skills from a pinned commit, or copy them into an internal repository after review. Updates go through the same review. Never install skills that fetch their instructions at run time from locations you do not control.

An internal catalogue

We keep a small internal catalogue of reviewed skills and MCP servers. Developers install from it, and requests for new ones go through a lightweight review. This mirrors how we handle browser extensions and IDE plugins.

When something slips through

If a reviewed skill later turns out to be harmful, the response is the same as for a compromised dependency: remove it from the catalogue, notify everyone who installed it, rotate any credentials the agent could have read on those machines, and check repositories for changes the agent made while the skill was active. Keeping the catalogue as the only install path is what makes "who installed it" answerable.

Measuring the cost of review

Our reviews take 20 to 60 minutes per skill, mostly reading scripts. Over six months, we reviewed 41 and approved 29 as-is, 7 after removing scripts or network calls, and rejected 5. The time spent was far less than investigating a single incident would have been.

Writing safe skills yourself

If you publish skills:

  • keep instructions short, specific and related to the stated purpose;
  • avoid scripts unless necessary, and document exactly what they do;
  • never fetch instructions or code at run time;
  • declare required permissions and network access in the README;
  • sign releases and pin dependencies.

Common mistakes

Mistake Risk Do this instead
Installing from a link in a chat Unknown publisher, unreviewed content Install from a reviewed internal catalogue
Reviewing only the rendered README Hidden instructions missed Read raw files, including comments
Unpinned installs Content changes after review Pin to a commit or vendor a copy
Agent with full shell and network access Skill can exfiltrate or persist Approvals, deny rules, sandbox
Long-lived credentials on dev machines High impact if exfiltrated Short-lived credentials, no prod secrets locally

Key takeaways

  • Skills, plugins and MCP servers are dependencies that can instruct your agent, not just code it calls.
  • Review instructions in raw form as carefully as scripts.
  • Pin and vendor what you install; avoid skills that load remote instructions.
  • Limit agent permissions, run untrusted extensions in sandboxes and keep secrets out of reach.
  • Maintain an internal catalogue of reviewed extensions.

References