Vet an Agent Skill Before Installing It with Gold Open Source

To vet an agent skill before you install it, start at gold.safeguard.sh/skills: find the skill by name, confirm who publishes it, and follow the link to its canonical source folder. Then compare the copy you were handed against that source and audit every file in it the way Anthropic's own enterprise guide describes, because the Gold directory tells you where a skill comes from, not what its scripts will do on your machine. Gold Open Source is free, needs no login, and is generally available (GA).

That split is the whole method. Gold answers the identity question quickly and for free. Your review answers the behaviour question. The rest of this post walks through both, one step at a time, using only what the live Gold pages and Anthropic's documentation show today.

Key takeaways

• Gold Open Source (GA, free, no login) has an Agent Skills directory at gold.safeguard.sh/skills. It lists official skills from Anthropic's skills repository and a community skill collection, with a search box and a filter by source.
• Each skill page shows the skill's name, its author, its description and a link to the exact folder in the source repository. It does not show a scan verdict, a version, a license field or a risk score for the skill.
• Anthropic's documentation says to use skills only from trusted sources and to audit any other skill thoroughly. Its enterprise guide gives a risk tier table and a review checklist; this post turns both into a worksheet.
• A skill's frontmatter can pre-approve tools and its body can run shell commands before Claude sees it. Check allowed-tools and any ! command lines before a skill lands in a repository your team opens.
• For the packages a skill's scripts depend on, Gold's package pages show versions, known vulnerabilities, license and OpenSSF Scorecard health. Safeguard's software composition analysis (SCA, GA) keeps watching those dependencies once the skill lives in a repository you connect, policy gates (GA) can Block, Warn or Notify on what they find, and autonomous remediation (GA) can open the upgrade pull request, though it ships switched off with every category set to Manual.
• Safeguard's platform also treats agent skill definitions as AI assets it can scan alongside models and agent configurations (model and agent scanning, GA). The Safeguard CLI (GA) and the Safeguard connector for Claude (GA), added from Claude's connector directory, let you query your own findings while you review.

What an agent skill is, in Anthropic's own words

Anthropic's Agent Skills overview describes a skill as a modular capability that packages instructions, metadata and optional resources such as scripts and templates, which Claude uses automatically when relevant. Every skill is a directory with a SKILL.md file at its root. That file starts with YAML frontmatter that has two required fields, name and description, and a body of instructions underneath.

The overview spells out the field rules. The name can be at most 64 characters, uses only lowercase letters, numbers and hyphens, and cannot contain the reserved words "anthropic" or "claude". The description must be non-empty, can be at most 1,024 characters, and must say both what the skill does and when Claude should use it. Neither field may contain XML tags.

Progressive disclosure, and why it matters for review

Anthropic loads a skill in three stages. Level 1 is the metadata: the name and description are loaded at startup into the system prompt, and the description is what Claude matches a request against to decide whether to trigger the skill. Level 2 is the body of SKILL.md, which Claude reads from the filesystem only when the skill triggers. Level 3 is everything else bundled in the folder, such as reference files and scripts, which Claude reads or runs as needed.

For a reviewer this has a practical consequence. The short description you see in a listing is the only part that is always in context, and it decides when the skill fires. The parts that do the work, the body and the scripts, are loaded later and are the parts a casual glance at a listing never shows you. A vetting process that stops at the description has checked the least risky part of the skill.

Where skills run, and what they can reach

The overview lists different runtime limits per surface, and they change how much a bad skill could do:

• Claude API. Skills run in a sandboxed container with no network access and no runtime package installation. Only pre-installed packages are available.
• claude.ai. Network access varies with user and admin settings: full, partial or none.
• Claude Code. Skills have the same network access as any other program on the user's computer.

Skills also do not sync between surfaces. A skill uploaded to claude.ai must be uploaded separately to the API, a skill uploaded through the API is not available on claude.ai, and Claude Code skills are filesystem based and separate from both. Sharing differs too: the overview describes API skills as workspace wide, Claude Code skills as personal or per project (or shared through plugins), and claude.ai custom skills as individual. Anthropic's Help Center article on using skills in Claude adds that organization owners can upload skills to provision them organization wide, so check which description matches your plan before you design an approval flow around it.

The open specification at agentskills.io defines the same folder shape (SKILL.md plus optional scripts/, references/ and assets/) and adds optional fields, including license, compatibility, metadata and an experimental allowed-tools field.

The problem: a skill is software with instructions attached

Anthropic is direct about the risk. The overview's security section says to use skills only from trusted sources, meaning ones you created yourself or obtained from Anthropic, and to "exercise extreme caution" with anything else. It explains why: a skill gives Claude new capabilities through instructions and code, so a malicious skill can direct Claude to call tools or run code in ways that do not match its stated purpose. Depending on the access Claude has, that can mean data exfiltration or unauthorized system access.

Anthropic's engineering post that introduced Agent Skills gives the same advice and points reviewers at two things in particular: code dependencies and bundled resources such as images or scripts, and any instruction that tells Claude to connect to untrusted network sources.

Three properties make skills harder to review than a package

The instructions are executable intent. A package does what its code does. A skill also tells a capable agent what to do, in natural language, with whatever tools that agent holds. Anthropic's enterprise guide lists "instruction manipulation" (directives to ignore safety rules, hide actions from users or behave differently on certain inputs) as a high concern on its own, before any script is involved.

Frontmatter can change permissions. In Claude Code, the skills documentation describes an allowed-tools field that lets Claude use the listed tools without asking during the turn that invokes the skill. The same page notes that workspace trust does not gate this field, that Claude Code applies a project skill's allowed-tools even in a non-interactive run in a folder you have never trusted, and that a skill can grant itself broad tool access. Its advice is to review the allowed-tools of skills checked into a repository before you run Claude Code there.

A skill can run commands before Claude reads it. Claude Code supports dynamic context injection: a line written as ! followed by a command in backticks runs the shell command and replaces the line with its output before the skill content is sent to Claude. The docs show it used to inline a pull request diff. It is useful, and it also means the act of invoking a skill can execute something on your machine. Claude Code has a disableSkillShellExecution setting that turns this off for skills from user, project, plugin and additional directory sources, and it does not run those commands for skills synced from a claude.ai account.

What the standards say

None of the major frameworks has a clause written for agent skills yet, but the general requirements apply directly:

• OWASP Top 10 for LLM Applications 2025, LLM03 Supply Chain. The OWASP entry treats third-party components used by LLM applications as supply chain risk, including outdated or deprecated components and weak provenance. A skill is a third-party component that an LLM application loads and acts on.
• OWASP Top 10 for Agentic Applications for 2026. Published by the OWASP GenAI Security Project on 9 December 2025, the agentic list covers risks for agents that plan, act and make decisions across workflows. Skills extend exactly those agents.
• NIST SP 800-218, the Secure Software Development Framework (SSDF) 1.1. The SSDF is written for software producers and recommends practices that reduce vulnerabilities in released software, including how third-party components are acquired and maintained. If your team ships agents or agent configurations to others, the skills inside them are components under that framework.

The common thread is simple: know where each component comes from, review it before use, pin what you reviewed, and keep watching it after you adopt it. The steps below follow that order.

What the Gold Open Source skills directory shows today

This section describes the live pages as fetched on 25 October 2026. Gold changes, so check the page itself before you rely on a detail.

The directory page

gold.safeguard.sh/skills is titled "Agent Skills" and describes itself as capabilities that extend AI coding agents, "from official Anthropic Agent Skills to notable community skills." It has:

• A search box with the hint "Search skills, e.g. debugging, pdf, brainstorming". You can search by name or by the capability you want.
• A source filter with three options: All sources, anthropic/skills and obra/superpowers. The first is Anthropic's public skills repository. The second is a community collection of development workflow skills.
• A card per skill showing the skill's name, the first part of its description and an author label. Anthropic skills carry the label "Anthropic"; the community skills carry "Superpowers (obra)".

A few cards do not show a readable description, only a stray character where the text should be. For those, read the description straight from the source folder in step 4 rather than relying on the card.

The Anthropic entries include the document skills (docx, pdf, pptx, xlsx), design and art skills, mcp-builder, skill-creator, webapp-testing and a template-skill whose description is the placeholder "Replace with description of the skill and when Claude should use it." The community entries cover development habits such as brainstorming, systematic debugging, test-driven development, writing and executing plans, requesting and receiving code review, and using git worktrees.

A skill's detail page

Open any card and you reach a page such as gold.safeguard.sh/skills/anthropic-pdf. It shows:

1. A breadcrumb (Home, Agent Skills, then the skill).
2. The label "AI Agent Skill", the skill name and "by" the author, for example "by Anthropic" or "by Superpowers (obra)".
3. Share links.
4. The full description, which is the text of the skill's description field.
5. The source link: the path to the skill's folder in its repository, for example github.com/anthropics/skills/tree/main/skills/pdf or github.com/obra/superpowers/tree/main/skills/systematic-debugging.
6. A "More ... skills" list of the other skills from the same source.

The page's structured data repeats the same link as the canonical sameAs address for the skill. The credits page names the two sources behind the directory: Anthropic's Agent Skills ("Official Agent Skills behind the skills directory") and the Superpowers collection, credited as open source community skills.

What the skill pages do not show

Be precise about this, because it shapes the rest of the workflow. As of this fetch, a Gold skill page does not show:

• a security scan result or verdict for the skill,
• a version, commit or release of the skill,
• a license for the skill,
• the skill's frontmatter beyond the description (no allowed-tools, no disable-model-invocation),
• the list of files or scripts inside the skill folder,
• a read API endpoint for skills. The developers page documents free read-only endpoints for packages and vulnerabilities, not skills.

So Gold's skills directory is a curated index with a verified pointer to the canonical source. That is genuinely useful: most risky skill installs start with a copy of unknown origin, and knowing what the real thing is called, who publishes it and where it lives cuts that risk at the first step. The behavioural review is still yours, and the steps below make it fast.

Step by step: vet a skill with Gold Open Source

The flow below assumes someone on your team wants to add a skill to Claude Code, to a claude.ai account or to an API workspace. It works the same way for a skill attached to a plugin.

1. Write down exactly what you were given

Before you search anything, record the starting point: where the skill came from (a link, a zip, a repository, a chat message), the folder name, and the name and description from its SKILL.md. If the copy came as a zip, unpack it into a new, empty folder that nothing else uses, and do not run anything inside it.

Compute a checksum of the whole folder now so you can prove later that what you reviewed is what you deployed. Anthropic's enterprise guide recommends exactly that: compute checksums of reviewed skills and verify them at deployment time.

# from the parent of the unpacked skill folder
find ./incoming-skill -type f -print0 | sort -z | xargs -0 shasum -a 256 > incoming-skill.sha256
shasum -a 256 incoming-skill.sha256

2. Search Gold for the skill

Go to gold.safeguard.sh/skills and search for the skill's name. If the name is generic, search for the capability instead (for example "pdf" or "debugging"). Use the source filter to narrow the list to anthropic/skills or obra/superpowers.

There are three possible outcomes:

• Found, same name, same source. Continue to step 3.
• Found under a similar name. Treat the copy you hold as unknown until you have compared it file by file with the canonical one. A lookalike name is a reason for more scrutiny, not less.
• Not found. Gold's directory covers two sources today. A skill that is not listed is not condemned by that, but you have lost the shortcut: treat it as a skill from an untrusted or unknown source and do the full audit in steps 5 to 8, which is what Anthropic's documentation asks for anyway.

3. Read the detail page and compare the description

Open the skill's page and compare its description, character for character where it matters, with the description in the SKILL.md you hold. Because the description is what Claude matches requests against, a changed description changes when the skill fires. A copy whose description has grown new trigger phrases ("use this whenever the user mentions credentials", for example) deserves a hard look at why.

Check the author label too. "by Anthropic" on a Gold page means the entry points into Anthropic's skills repository. That is the "obtained from Anthropic" case in Anthropic's own trust guidance, but only for a copy that matches the source.

4. Follow the source link and compare files

Click the source link on the Gold page. It opens the skill's folder in the canonical repository. Compare that folder with your copy:

# clone the canonical repository into a fresh folder, then compare
git clone --depth 1 https://github.com/anthropics/skills.git canonical-skills
diff -r canonical-skills/skills/pdf ./incoming-skill

An empty diff means your copy matches the source at the commit you cloned. Record that commit hash next to your checksum. Any difference, however small, means you are reviewing a modified skill, and the review in step 6 has to cover the changed files in full.

If your copy is already identical to the canonical folder, prefer installing from the canonical source rather than from the copy you were sent. That way your provenance record is the repository and commit, not a file that passed through a chat thread.

5. Check the license

Gold's skill pages do not carry a license, so read it from the source. Anthropic's skills repository says many of its skills are open source under Apache 2.0, while the document creation skills (the docx, pdf, pptx and xlsx folders) are source-available rather than open source and are shared as a reference. The repository also carries a disclaimer that the skills are provided for demonstration and educational purposes, that Claude's own behaviour may differ, and that you should test skills thoroughly in your own environment before relying on them for critical tasks.

For community skills, read the license file at the root of that repository. The open specification lets a skill declare a license field in its own frontmatter; if the skill you hold has one, check that it agrees with the repository.

Record the result. If your organization has rules about source-available material, this is the step where they apply.

6. Read every file against Anthropic's risk tiers

This is the core of the review. Anthropic's Skills for enterprise guide gives a risk tier table. Work through each row for the skill in front of you:

Then run the guide's review checklist. In short: read all skill content including every referenced markdown file and bundled resource; run scripts in a sandbox and confirm their output matches the description; look for adversarial instructions; search scripts and instructions for network patterns (http, requests.get, urllib, curl, fetch); confirm there are no hardcoded credentials; list every bash command, file operation and tool reference; confirm that any external URLs point to the domains you expect; and look for instructions that read sensitive data and then write, send or encode it for external transmission, including through Claude's replies.

A quick way to get the first pass of that list is a plain search over the folder. It finds candidates for you to read, not verdicts:

grep -rn -E "https?://|curl|wget|fetch\(|requests\.|urllib|socket|base64" ./incoming-skill
grep -rn -E "\.\./|~/|/etc/|\.ssh|\.aws|\.env" ./incoming-skill
grep -rn -E "^allowed-tools|disable-model-invocation|^\s*!\`|\`\`\`!" ./incoming-skill

Pay special attention to combined risk, which Anthropic's checklist calls out: a skill that reads files and also has network access is a bigger concern than either capability alone.

7. Check the Claude Code controls in the frontmatter and body

If the skill will run in Claude Code, add three checks that come straight from the Claude Code skills page:

• allowed-tools. Note every tool the skill pre-approves. The docs say this field grants permission for the listed tools during the invoking turn and does not restrict the other tools, which remain callable under your normal permission settings. Decide whether each grant is needed. If your organization prefers to withhold this field from repository skills entirely, the docs point to managed permission rules for that.
• disable-model-invocation. Skills with side effects, such as a deploy skill, can be set so that only a person can invoke them. If a skill performs actions you would not want triggered by a passing phrase, expect to see this set.
• Dynamic context injection. Search for lines that start with ! and a backticked command, and for fenced blocks opened with three backticks and an exclamation mark. Each one runs a shell command when the skill is invoked. Decide whether to allow it, or set disableSkillShellExecution to true in settings for the sources you do not control.

Where the skill will live matters as well. The Claude Code docs list enterprise (managed settings), personal (~/.claude/skills/), project (.claude/skills/ in a repository), nested, additional directory, plugin and claude.ai account locations, each with a different reach. A skill committed to a project folder reaches everyone who opens that repository, so it deserves the strictest review.

8. Look up what the skill's scripts depend on

Scripts bring dependencies. In Claude Code, skills can reach the network and install packages; on the API, skills can use only pre-installed packages. Either way, the libraries a script imports are part of what you are about to run.

List the imports and any packages the instructions tell Claude to install, then look each one up on Gold Open Source. A Gold package page, such as the one for lodash, shows:

• the current version and the install command for it,
• the count of known vulnerabilities and whether high or critical ones are present,
• the license, when the registry metadata identifies one,
• an OpenSSF Scorecard health grade with the individual checks behind it, such as Maintained, Code Review, Security Policy, Dependency Update Tool, Fuzzing and Pinned Dependencies, and the date it was scored,
• when the package was last indexed.

The free read API on the developers page returns the same package data as JSON, which is handy when a skill pulls in several libraries:

curl -s "https://gold.safeguard.sh/api/packages?search=lodash&ecosystem=npm"
curl -s "https://gold.safeguard.sh/api/packages/lodash/vulnerabilities"

The first call returns matching packages with their current version, a count of known vulnerabilities and the license field. The second returns the known vulnerabilities recorded for one package, as a list that is empty when none are recorded. Neither call executes anything from the skill, which is the point: you can check every library a script imports before a single line of that script runs.

Not every package is in the directory. When a lookup returns nothing, the package is not cleared or condemned by that; check its advisories directly and treat it as part of the dependency review in step 10. Where Gold does list a known vulnerability, the vulnerability page gives affected and fixed versions, which tells you what version the skill's instructions should pin. The same package check is covered in more depth in vet an open source package before you adopt it.

9. Approve, pin and record

When the review is complete, record the decision in one place. Anthropic's enterprise guide recommends documenting each skill in an internal registry with its purpose, owner and version, storing skill folders in Git for history and pull request review, and requiring separation of duties so that a skill's author is not its reviewer.

A record that comes straight out of steps 1 to 8 looks like this. The Gold fields are the real values from the live page for Anthropic's pdf skill; the review fields are the ones your team fills in:

skill: pdf
gold_page: https://gold.safeguard.sh/skills/anthropic-pdf
gold_author: Anthropic
canonical_source: github.com/anthropics/skills/tree/main/skills/pdf
source_commit: "<commit hash you cloned>"
folder_sha256: "<value from step 1>"
diff_against_canonical: none
license: source-available (repository README); reviewed by legal
risk_indicators:
  code_execution: yes (bundled scripts read; run in sandbox)
  network_access: reviewed
  mcp_references: none
  allowed_tools: none
  dynamic_context_injection: none
dependencies_checked_on_gold: yes
surface: Claude Code, project skill
owner: platform-team
reviewer: appsec (not the author)
decision: approved
review_date: 2026-10-25

On the Claude API, pin the version you reviewed. The enterprise guide warns that if you omit the version, requests use the latest one, so a new version uploaded by anyone in the workspace immediately changes what production agents run. It recommends treating every update as a new deployment that needs a full security review, and keeping the previous version as a fallback.

10. Keep watching after you install

A reviewed skill can change in two ways: the skill itself is updated, or something it depends on changes. Anthropic's overview makes the second point explicitly: even trustworthy skills can be compromised if their external dependencies change over time.

For the skill itself, re-run steps 3 to 6 whenever the canonical source moves and you want the update. Your checksum from step 1 tells you whether the copy deployed is still the copy you approved.

For the dependencies, put the reviewed skill folders in a Git repository, as Anthropic recommends, and connect that repository to Safeguard like any other. Safeguard's SCA (GA) then tracks the dependency manifests in it, and new vulnerabilities in those packages show up with EPSS and CISA KEV context in the same place as the rest of your estate. A policy gate (GA) on that repository can Block, Warn or Notify when a skill update brings in a dependency that breaks your rules, and anyone who needs to ship anyway goes through an exception that someone approves. If you use Claude, add the Safeguard connector (GA) from Claude's connector directory and ask it for the vulnerabilities on that project while you review the next update. The connector directory post covers the install.

How deep to review: match the effort to what the skill can do

Not every skill needs a sandbox run and a second reviewer. The ten steps above are the full path. In practice, the shape of the skill folder tells you how much of it you need, and Anthropic's risk tiers give you the cut points. Steps 1 to 4 always apply, because identity and provenance are cheap to check and expensive to get wrong.

Two rules keep this honest. First, a skill moves to the highest row any of its files reaches; one script makes the whole folder a code execution review. Second, an update is a new review. Anthropic's enterprise guide treats every update as a new deployment, so a skill that was instructions only last month and now ships a script goes back through the full path.

Where the Safeguard platform fits

Gold Open Source is the free, public front door. The paid platform covers what happens after you decide to use a skill:

• Model and agent scanning (GA). Safeguard's offering treats AI assets as first-class objects it scans: models pulled from Hugging Face or supplied directly, agent configurations and their tool access, and agent skill definitions. This sits alongside agent identity (GA), which tracks which agent holds what access. It does not replace the human review above; it keeps skills inside the same inventory as the rest of your AI assets.
• SCA and vulnerability management (GA). Once skills live in a repository, their manifests are scanned like any other project, with EPSS and KEV prioritization and policy gates.
• Autonomous remediation (GA, ships switched off). When a dependency used by your skill scripts has a fixed version, Safeguard can open the upgrade pull request. Every remediation category starts set to Manual, so nothing changes until your team turns it on.
• The Safeguard CLI (GA). Running safeguard opens an interactive terminal where /scan . scans the current folder. Since CLI v11.10.0 the CLI asks before any command that changes something; read-only commands run without a prompt in the default mode. The CLI demo at the end of this post shows a session.

One naming note to avoid confusion: the Safeguard app also has its own in-app Skills (GA), which are reusable system prompts with an optional list of allowed MCP tools, used for agentic search inside Safeguard. Those are Safeguard features you define in your tenant. The Gold skills directory is a public index of third-party agent skills. They share a word, not a function.

Decision table: what Gold tells you, and what you still own

What Safeguard does not do

Be clear about the limits before you plan around this workflow:

1. Gold does not issue a verdict on agent skills. Skill pages carry identity and source, not a scan result, risk score or approval. Do not read a skill's presence in the directory as clearance to install it.
2. Gold covers two sources today. The directory lists Anthropic's skills repository and one community collection. Skills from marketplaces, plugins, internal teams or individual authors are not there, and you will audit those without the identity shortcut.
3. Gold does not track skill versions. Skill pages link to the main branch of the source folder. They do not show which commit you reviewed or warn you when the folder changes. Your checksum and commit record do that.
4. Safeguard does not change how Claude loads or runs skills. Permission prompts, allowed-tools grants, disableSkillShellExecution, managed settings, and the network limits per surface are Anthropic's controls. Configure them in Claude and Claude Code.
5. Safeguard does not replace Anthropic's scanning where you have it. Anthropic's enterprise guide describes skill content scanning that Claude Enterprise organizations can turn on for custom skills uploaded in claude.ai and Claude Cowork. It does not cover skills uploaded through the Skills API or the Claude Console. Use it where it applies; it complements the review rather than replacing it, in Anthropic's own words.
6. The package lookups cover dependencies, not instructions. Gold package pages and Safeguard SCA tell you about the libraries a script uses. They do not read a skill's natural language instructions for adversarial intent. That part of the review is human work.
7. Not every package is indexed. Some libraries a skill imports will not have a Gold package page. A missing page is not a finding either way.

Common mistakes

Trusting the listing card. The card shows a shortened description. The parts that act, the body and the scripts, load only when the skill fires. Read the folder, not the card.

Installing the copy instead of the source. If your copy matches the canonical folder, install from the canonical repository and commit. A file passed through chat has no provenance.

Treating "by Anthropic" as a version guarantee. Anthropic's repository carries a disclaimer that its skills are for demonstration and education and that Claude's own behaviour may differ. Test them in your environment like anything else.

Skipping allowed-tools because the skill is "just markdown". In Claude Code a project skill can pre-approve tools for the turn that invokes it, even in a folder you have not trusted. Markdown with a permissions block is configuration.

Missing the ! lines. Dynamic context injection runs a command when the skill is invoked, before Claude reads the content. Search for it explicitly.

Reviewing once and forgetting. On the API, an unpinned skill follows the latest version anyone in the workspace uploads. In Git, a pull from upstream can change a reviewed folder. Pin, checksum and re-review.

Ignoring combined risk. A skill that reads local files is one thing; a skill that reads local files and can reach the network is another. Anthropic's checklist calls the combination out. So should your worksheet.

Letting the author approve their own skill. Anthropic's enterprise guide recommends separation of duties. Build it into the record.

FAQ

Is Gold Open Source free for checking agent skills?

Yes. Gold Open Source is free and needs no login. The skills directory, the skill detail pages, the package pages and the read API for packages and vulnerabilities are all public.

Does Gold give a safety verdict for agent skills?

No. The skill pages do not show a scan result, a verdict or a risk score. Use them to confirm identity and source, then complete the review described in Anthropic's enterprise guide. If you run Claude Enterprise, Anthropic's own skill content scanning covers custom skills uploaded in claude.ai and Cowork.

Which skills are listed on gold.safeguard.sh/skills?

Official skills from Anthropic's public skills repository and skills from the community Superpowers collection. The source filter on the page lets you show one or the other. The list changes, so search the page rather than relying on a copy.

How do I know a skill I was sent is the official one?

Find it on Gold, follow the source link to the canonical folder, clone that repository and diff the folder against your copy. Record the commit hash and a checksum of the folder. If anything differs, review the changed files in full.

What license do Anthropic's skills use?

According to Anthropic's skills repository, many skills there are open source under Apache 2.0, while the document creation skills are source-available rather than open source. Check the repository for the skill you want, since Gold's skill pages do not show a license.

What should I check in a skill's frontmatter?

The name and description against Anthropic's field rules, any license field, and for Claude Code the allowed-tools grants and whether disable-model-invocation is set for skills with side effects. Then search the body for dynamic context injection lines that run shell commands.

Can a skill run code without Claude being asked to?

In Claude Code, dynamic context injection runs a shell command when the skill is invoked and inlines the output before Claude sees the content. Skills can also bundle scripts that Claude runs as part of the instructions. You can disable the injection behaviour with the disableSkillShellExecution setting.

Do skills have network access?

It depends on the surface. Anthropic's overview says API skills have no network access and cannot install packages at runtime, claude.ai skills have full, partial or no network access depending on settings, and Claude Code skills have the same network access as any program on your computer.

How does Safeguard help after a skill is installed?

Keep reviewed skill folders in a repository connected to Safeguard. SCA tracks their dependency manifests and new vulnerabilities with EPSS and KEV context, autonomous remediation (switched off until you enable it) can open upgrade pull requests, and the platform's model and agent scanning keeps skill definitions in your AI asset inventory.

Is the Gold skills directory the same as Skills inside the Safeguard app?

No. In-app Skills are reusable prompts with an optional list of allowed MCP tools that you define in your Safeguard tenant. The Gold directory is a public index of third-party agent skills for Claude and other agents.

Related reading

• Agent Skills explained: SKILL.md format, progressive disclosure and how to vet third-party skills
• Vetting third-party agent skill marketplaces
• Are AI coding agent plugins and skills safe to install?
• Securing MCP servers and agent skills in the enterprise
• Use Gold Open Source in your workflow
• Claude Code skills vs CLAUDE.md: what loads when

Vetting a skill often surfaces an outdated or vulnerable library in its scripts, and the right response is to move that dependency to a fixed version rather than drop a useful skill. The block below is how Safeguard handles that for any open source dependency, including the ones your agent skills bring with them.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, and asks it to fix the lodash CVE in a repository: the CLI reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan .. The same session works on a folder of reviewed skills: scan it, and if a script's dependency has a fixed version, let the CLI propose the upgrade while you keep the approval.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to Safeguard with OAuth and chooses which tools Claude can use. In Claude, add Safeguard from the connector directory rather than configuring a custom server; Safeguard is listed there as a community connector. Once connected, you can ask Claude for the vulnerabilities in the project that holds your approved skills while you review the next update, using your own Safeguard data.

Click through it at your own pace, or open it full screen.

Start with the free directory at gold.safeguard.sh/skills. When you want the platform side, download Safeguard and read the Safeguard docs.

Quick check

Sources

• Gold Open Source: Agent Skills directory
• Gold Open Source: pdf skill page
• Gold Open Source: Systematic Debugging skill page
• Gold Open Source: skill-creator skill page
• Gold Open Source home
• Gold Open Source: credits and data sources
• Gold Open Source: developers, API and badges
• Gold Open Source: packages directory
• Gold Open Source: lodash package page
• Safeguard documentation
• Safeguard download page
• Anthropic: Agent Skills overview
• Anthropic: Skills for enterprise
• Anthropic: Skill authoring best practices
• Claude Code: Skills
• Claude Help Center: Using skills in Claude
• Anthropic Engineering: Equipping agents for the real world with Agent Skills
• Anthropic skills repository
• Agent Skills specification
• OWASP Top 10 for LLM Applications 2025: LLM03 Supply Chain
• OWASP Top 10 for Agentic Applications for 2026
• NIST SP 800-218, Secure Software Development Framework 1.1

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.