Agent Skills Library

Security · Decision guide

When not to use a skill

A skill is useful when it packages a repeatable, trusted workflow. It is not automatically safer or better than giving an agent the right primary documentation and a well-scoped request.

Last reviewed September 3, 2026

Shai-Hulud worm and AI software engineering risks: a compromised npm package can run install scripts, steal secrets, and propagate to other repositories and packages
Shai-Hulud illustrates why a skill that installs dependencies, handles credentials, or reaches cloud services deserves a trust-boundary review before adoption.

The Shai-Hulud campaign was a coordinated npm supply-chain compromise: malicious install-time code stole developer credentials and used that access to publish infected versions of additional packages. Skills are not npm packages, but the incident is a useful warning: a skill can still widen the path from instructions to dependencies, credentials, and external services.

01

Start with the trust boundary

Installing a third-party skill means trusting more than its prose. The instructions can direct an agent to run scripts, install dependencies, call services, read files, or move data. A polished description does not prove that those behaviors are necessary, current, or safe.

Use a skill when the extra layer adds reviewed, repeatable value. Skip it when it mainly adds another party, another dependency, or broader access than the task requires.

02

Case one

Data movement and cloud API access

A third-party skill that uploads, downloads, exports, or otherwise transfers data expands the trust boundary. Even when the behavior is described as a convenience, it may expose internal data, credentials, prompts, or outputs to an endpoint your organization has not approved.

Default decision

Do not adopt the skill until the destination, data fields, credentials, retention, logging, and failure behavior are understood and approved.

The same workflow can be appropriate as an internal skill built and maintained inside the enterprise. For example, an internal skill can standardize Agent-assisted requests to approved cloud APIs: it can constrain endpoints and parameters, use enterprise-managed authentication, apply least privilege, record activity, and require confirmation for consequential changes.

“Internal” is not a free pass. It is valuable because ownership, review, credentials, access policy, monitoring, and incident response can all be placed under the same enterprise controls as the systems being accessed.

03

Case two

Primary documentation is often the safer shortcut

For a product-specific question or a one-time implementation, point the agent to the provider's current documentation before installing a third-party skill. This reduces the chance that stale instructions or someone else's preferred architecture will be mistaken for a product requirement.

While evaluating Replit, I found third-party skills that suggested CI integration. Replit's own documentation describes its native project, workflow, and publishing paths. Starting with that primary source makes it easier to distinguish a required Replit workflow from optional infrastructure a third party happens to prefer.

Default decision

If current provider documentation is enough for the agent to complete and verify the task, use the documentation. Create or install a skill only when a recurring workflow needs additional tested instructions, controls, or organization-specific context.

04

A quick decision test

  • Repetition: Will this workflow recur often enough to justify maintaining a skill?
  • Authority: Is the skill more authoritative than the provider's current documentation for this task?
  • Access: Does it request files, credentials, network access, or permissions the task does not clearly need?
  • Data: Can you name every destination and the exact data that may leave the environment?
  • Verification: Are there observable checks that prove the workflow did the intended thing and nothing broader?
  • Ownership: Who reviews updates, responds to findings, and removes the skill when it is no longer safe or useful?

05

Scan, then still make a judgment

Security scanners can surface prompt injection, exfiltration, dangerous code, permission mismatches, vulnerable dependencies, and description-behavior gaps. They are useful gates, not certificates. A clean scan does not establish that a skill is necessary, well designed, or suitable for your organization.

The safest skill is sometimes the one you do not install.

Sources and further reading

← Back to the resource library