Vet an MCP Server Before You Connect It, with Gold Open Source

To vet an MCP server before you connect it, look it up on Gold Open Source at gold.safeguard.sh/mcp. It is free, needs no login, and shows each public server's registry name and publisher namespace, version, whether it is a hosted endpoint or an installable package, its transport, source repository and licensing notes. You then check tools, scopes and behaviour yourself before connecting.

Gold Open Source gives you the identity and distribution facts in one place, drawn from the official MCP Registry, so you stop guessing who published a server and how it runs. It does not run the server, list its tools or give it a pass mark, so the second half of vetting is still yours. This post walks through both halves, using the live page as it looked when we fetched it on 25 October 2026, and then shows Safeguard's own connector going through the same checks by the Claude directory route.

Key takeaways

• Gold Open Source (GA) is free and needs no login. Its MCP Servers directory lists servers from the official MCP Registry, tens of thousands of them, with a search box that matches name, title or vendor.
• Each server page shows identity and distribution facts: the registry name (which encodes the publisher's verified GitHub account or domain), version, a publisher description, hosted remote endpoint or installable package, the package registry and transport for packages, a source repository link where one is listed, and a licensing note.
• The page does not show a tool list, OAuth scopes or a safety score. You read tools and scopes yourself in a sandbox before you connect anything real.
• The official MCP Registry checks who published a server, not what the server does. Its own docs say it delegates security scanning to package registries and downstream aggregators, and that consumers should assume minimal moderation.
• Safeguard's own MCP server (GA) is pinned at the top of the Gold MCP page with an "Add in Claude" link. Safeguard is listed in Claude's connector directory as a community connector, connects with OAuth 2.0, and a new workspace starts with a small read-only default tool set.
• Safeguard publishes no npm package or local bridge for its MCP server, so its docs say to treat any package that claims to be the Safeguard MCP server as untrusted.
• For servers you approve but do not control, Safeguard MCP Guardrail (GA) can sit in front of them as a policy proxy. Related capabilities named here: SCA (GA), policies and gates (GA), agent identity (GA), in-app Connectors (GA) and the Safeguard CLI (GA).

Why an MCP server is a different kind of dependency

A library you add to a lockfile runs inside your build. An MCP server is different in three ways that change how you should vet it.

First, the caller is a model. The Model Context Protocol lets an AI application discover a server's tools and call them. The decision to call a tool comes from a model reading a context window that can hold web pages, tickets, file contents and earlier tool results. Text in that window can steer the next call, and text returned by a tool lands back in the window.

Second, the server usually holds a credential with reach. A connector that wraps a ticketing system, a code host, a database or a mailbox signs in as someone. Once connected, it acts with that identity's permissions.

Third, many servers are not yours. Teams connect agents to vendor hosted servers, community servers installed from npm or PyPI, and servers a colleague found last week. You cannot add checks to code you do not run, and you often cannot see what a remote endpoint does with the arguments it receives.

What Anthropic tells users before they connect a server

Anthropic's help article on custom connectors is direct about the trust decision. It says custom connectors connect Claude to services that have not been verified by Anthropic, and lists what users should do: connect only to servers built and hosted by organisations you trust, review the permissions a server requests during sign in and limit scopes where you can, watch tool inputs and outputs because a server can carry hidden instructions aimed at Claude, and watch for changes in tool behaviour because server developers can update tools without warning. It also says to review tool approval requests carefully and to use "Allow always" only for servers and tools you trust to run unsupervised, and to switch off tools that are not relevant to the current conversation from the "Search and tools" menu.

Anthropic's developer docs make the same point for the API side. Their page on remote MCP servers says the third-party servers listed there are not owned, operated or endorsed by Anthropic, and that users should connect only to servers they trust and review each server's security practices.

Both statements put the vetting job on the person or team doing the connecting. That is the job this post is about.

What the MCP specification says about trust

The MCP specification itself sets the baseline. The tools section of the current revision (2025-11-25) says clients MUST treat tool annotations as untrusted unless they come from trusted servers. It also says there SHOULD always be a human in the loop who can deny tool invocations, and that applications should make clear which tools are exposed to the model and show confirmation prompts for operations.

The tools section also defines a listChanged capability. A server that declares it can send a notifications/tools/list_changed message when its tool list changes. In plain terms, the set of tools you reviewed on Monday is not guaranteed to be the set the server offers on Friday.

The specification's Security Best Practices page covers several attack classes that matter at vetting time:

• Local MCP server compromise. Servers you download and run on your own machine, or install through a client's configuration, run with your local privileges.
• Token passthrough. The page says MCP servers MUST NOT accept tokens that were not explicitly issued for them.
• Scope minimisation. Poor scope design increases the impact of a stolen token and makes audit trails harder to read. You cannot check most of these from a directory page. You can check which kind of server you are dealing with (local package or hosted endpoint), who published it, and where its code lives, and that tells you which of these risks apply and who to ask about them.

How OWASP frames it

The OWASP Top 10 for LLM Applications (2025) gives two entries that map straight onto connector choice. LLM03:2025 Supply Chain covers the integrity of the components an LLM application depends on. LLM06:2025 Excessive Agency names three root causes: excessive functionality (an extension offers functions the use case does not need, such as a document reader that can also delete), excessive permissions (an extension connects with an identity that can do more than read), and excessive autonomy (high impact actions run without a confirmation step). Its first mitigation is to minimise extensions: give the agent only the ones it needs.

Each cause is a vetting question: does this server do more, or ask for more access, than we need, and will our client let it act without asking?

What the official MCP Registry checks, and what it leaves to others

Gold Open Source's MCP directory is built on the official MCP Registry. Gold's credits page names the MCP Registry as the source behind its MCP servers directory. So before reading a Gold page, it helps to know exactly what the registry does and does not vouch for. Everything below comes from the registry's own documentation, fetched on 25 October 2026.

It is in preview. The registry's About page says it is currently in preview and that breaking changes or data resets may occur before general availability.

It verifies the namespace, not the code. Server names use a reverse DNS format. The authentication guide says that if a publisher signs in with GitHub, the server's name MUST take the form io.github.username/... or io.github.orgname/.... If the publisher proves a domain instead, through a DNS TXT record or an HTTP check, the name takes the reverse DNS form of that domain, such as com.example/.... The About page says this ensures only the legitimate owner of a GitHub account or domain can publish under that namespace.

It delegates security scanning. In the registry's words, it focuses on namespace authentication and metadata hosting, and relies on underlying package registries (npm, PyPI, Docker Hub and others) and downstream aggregators for security scanning of actual server code.

Moderation is light by design. The moderation policy says the registry makes no guarantees about moderation and that consumers should assume "minimal-to-no moderation." It lists what the maintainers will not remove: low quality or buggy servers, servers with security vulnerabilities, and servers that duplicate others.

It lists public servers only. The About page says the registry does not support private servers. A server is eligible if its installation method is publicly available (for example an npm package or a public Docker image) or the server itself is publicly reachable.

It publishes metadata in a standard server.json shape. A live API response from the registry shows the fields you would expect: a name, title, description and version, a remotes array for hosted servers (each with a transport type such as streamable-http and a URL) or a packages array for installable servers, plus registry metadata such as a status and publish dates.

So a registry listing tells you who controls the name. It does not tell you the server is well built, safe to run, or maintained.

What Gold Open Source shows for MCP servers today

We fetched gold.safeguard.sh/mcp with a plain HTTP request on 25 October 2026. The server list is rendered on the server, so it is visible in the page source without running any scripts. Here is what the live page contains.

The directory page

The page is titled MCP Servers under a "Model Context Protocol" label. Its header says the list comes from the official registry and describes MCP servers as the connectors and plugins that give AI agents tools and data. The count it shows runs to tens of thousands of servers, and well over half of them are marked as having hosted remote endpoints.

Under the header sits a search box that searches MCP servers by name, title or vendor. The page shows the first few hundred results and asks you to refine your search to narrow the rest. In our fetch the unfiltered list was ordered by registry name, starting with reverse DNS namespaces.

Each row in the list shows three things:

• the server's display title (for example a product name),
• its registry name in reverse DNS form,
• a remote tag when the server has a hosted endpoint. Rows without the tag are installable packages.

Every row links to a detail page at gold.safeguard.sh/mcp/ followed by the registry name, with the slash replaced by a double underscore.

Safeguard's own server, pinned at the top

Above the list is a card for Safeguard's MCP server at mcp.safeguard.sh. It describes the server as supply chain security tools for your agent covering vulnerabilities, SBOMs, licenses and remediation, available in Claude's connector directory or connectable to any MCP client. It has two buttons, Add in Claude and Setup guide, and a note that the directory link opens claude.ai and needs you signed in to Claude, while the setup guide covers every other client. We come back to this card in the walkthrough for Safeguard's own connector below.

A server detail page, section by section

Each detail page follows the same layout. Using the registry's own documentation example name, io.github.alice/weather-server, a page for an installable server would read like this:

Home / MCP Servers / Weather Server

MCP Server
Weather Server
io.github.alice/weather-server  · v1.2.0
[Share: X, LinkedIn, Reddit, HN, Copy]

<publisher's one line description>

Installable package
  Packages
    npm   @alice/weather-mcp   1.2.0   stdio transport

About this MCP server
  ...is distributed as an installable package, and is listed
  in the official Model Context Protocol registry.

Licensing & commercial use
  Check the source license
  ...Review the LICENSE file in the linked repository below
  before deploying it commercially...
  https://github.com/alice/weather-server

More from io.github.alice
  <other servers in the same namespace>

The values above are illustrative. The section names, labels and wording patterns are the ones the live pages use. Here is what each part tells you.

Title, registry name and version. The display title is whatever the publisher chose. The registry name is the identity that matters, because its namespace was verified by the registry. The version is the latest one Gold shows.

Description. The publisher's own one line summary from the registry. Treat it as marketing copy, not as a specification.

Distribution type. One of two badges: Hosted remote endpoint or Installable package. A hosted endpoint is a URL someone else runs. An installable package is code you download and run.

Packages block (installable servers only). The package registry (for example npm or PyPI), the package name, its version and the transport, typically stdio. This is the exact artifact your client would fetch.

About this MCP server. A short explainer that restates how the server is distributed and confirms that it is listed in the official registry.

Licensing and commercial use. Every page we fetched carried a "Check the source license" note. It explains that MCP servers set their own license and the registry does not publish it, so commercial use depends on the license in the source repository. When a repository is listed, the page tells you to review its LICENSE file before deploying commercially and links the repository. When none is listed, it says so and tells you to contact the publisher for licensing terms. The same note reminds you that running a third-party MCP server grants it tool access to your agent and that you should review its permissions and provenance.

Source repository. A link to the repository when the registry entry includes one.

More from this namespace. Other servers published under the same verified namespace. Useful for seeing whether a publisher maintains a family of servers or has a single one.

What the MCP pages do not show

As fetched on 25 October 2026, Gold's MCP detail pages did not show:

• the server's tool list, tool descriptions or annotations,
• the OAuth scopes or permissions a hosted server requests,
• a vulnerability count for the server or its package,
• a security score, grade or verdict for the server,
• download or usage figures, or maintainer activity.

This matches what the registry publishes. Gold is where you establish identity and distribution, and your own review is where you establish behaviour.

Field by field: where it comes from and what it proves

Step by step: vet an MCP server with Gold Open Source

This is the flow we recommend for a security or platform team deciding whether a server can be connected to company assistants. Steps 1 to 5 use Gold Open Source. Steps 6 to 10 are the parts no directory can do for you.

1. Find the server on Gold. Open gold.safeguard.sh/mcp. Search by the name you were given, the product name or the vendor. If you were handed a URL or a package name rather than a registry name, search for the product and check each candidate. No login is needed.

2. Confirm the publisher from the namespace. Read the registry name on the detail page. An io.github. prefix means the publisher signed in to the registry with that GitHub user or organisation. A reverse DNS name such as com.example means the publisher proved control of that domain. Ask: is this the organisation we expected? Many directories hold several servers with near identical titles under different namespaces. The title is not the identity; the namespace is.

3. Note the distribution type and transport. If the page says Hosted remote endpoint, your vetting questions are about the operator: who runs the URL, what they log, how they authenticate you, and what scopes they request. If it says Installable package with stdio transport, the code runs on your machine with your privileges, which is the case the MCP Security Best Practices page calls local MCP server compromise. Package servers need the same scrutiny as any dependency you would install.

4. Record the version and check the namespace's other servers. Write down the version you are reviewing. Glance at "More from" to see whether the publisher maintains other servers and whether the one you want fits that pattern.

5. Follow the source repository and read the license. If the page links a repository, open it. Read the LICENSE file, as the Gold page itself tells you to, and check that the repository belongs to the same owner as the namespace. If no repository is listed, the Gold page says to contact the publisher for licensing terms; for an installable package, also ask where the code that builds it lives.

6. For an installable package, look up the package itself. Search the package name on Gold Open Source's packages pages. Gold Open Source is free CVE intelligence: for known vulnerabilities it shows affected and fixed versions, so you can check whether the version the MCP page shows sits in an affected range. If you adopt the server, add the package to a manifest your Safeguard SCA (GA) scans already cover, so new advisories against it reach the same queue as the rest of your dependencies.

7. Read the tool list yourself, in a sandbox. Connect the server to a test client with a throwaway account and no production data, and list its tools. Read each tool's name, description and input schema. The MCP specification says clients MUST treat tool annotations as untrusted unless they come from trusted servers, so a "read only" hint is a claim to verify, not a guarantee. Look for tools that write, delete, send or execute, and compare them against what you actually need. This is OWASP's excessive functionality check.

8. Review the sign in and the scopes. For a hosted server that uses OAuth, go through the sign in on the test account and read the consent screen. Anthropic's guidance is to review the permissions a server requests, limit scopes where possible, and deny access if they seem unnecessary. If a read only use case triggers a consent screen for write or admin scopes, that is a finding. This is OWASP's excessive permissions check.

9. Decide, with conditions, and write it down. Approve, approve with limits, or reject. "Approve with limits" usually means only the tools you need, a credential limited to the data the use case needs, and a client setting that asks before each tool call. In Claude, that maps to Anthropic's advice to switch off irrelevant tools in the "Search and tools" menu and to keep "Allow always" for trusted servers and tools only. Record the registry name, version, distribution type, repository and license you approved.

10. Re-vet on change, and put a control in front of servers you do not run. Because a server can change its tool list, schedule a re-check when the version on the Gold page moves, and compare tool lists. For servers you approve but do not control, route agent traffic through Safeguard MCP Guardrail (GA), a policy proxy that allows, denies or monitors each tool call and records the decision. The full flow is in our post on putting a policy proxy in front of MCP servers.

A worked example: two servers, two different reviews

To make the steps concrete, here are two composite cases built from the patterns on the live pages. The names are illustrative.

Case A: an installable package with no repository listed. The Gold page shows a domain namespace, an Installable package badge, a Packages block reading npm, a scoped package name, a version and stdio transport, and a licensing note saying no source repository is listed and to contact the publisher.

The review: confirm the domain belongs to the vendor you meant; note that this code will run on laptops or build agents with their privileges; look up the npm package version for known CVEs; and hold the approval until the publisher supplies a source link and license terms. If the case is strong, review the package in a sandbox and pin the exact version.

Case B: a hosted endpoint with a repository. The Gold page shows an io.github. namespace, a Hosted remote endpoint badge, no Packages block, and a licensing note linking a GitHub repository.

The review: confirm the GitHub account matches the repository owner; remember your data leaves your environment on every call; read the license and the tool definitions in the code; walk through the OAuth consent with a test account and note the scopes. Approve read only tools if the scopes match, keep "ask every time" on in the client, and route production traffic through a guardrail if the server touches sensitive systems.

Gold settled identity and distribution in both cases; steps 6 to 10 still needed a person.

Vet Safeguard's own connector the same way

It would be odd to ask you to vet every connector except ours. Here is Safeguard's MCP server (GA) run through the same checklist, using the Claude connector directory route.

What the Gold page and the docs tell you

Where it is listed. The Gold MCP page pins Safeguard's server at the top with an Add in Claude link to Claude's connector directory and a Setup guide link to Safeguard's docs. Safeguard is listed in Claude's connector directory as a community connector. That is a directory listing, not a partnership with Anthropic.

Distribution type. Hosted. Safeguard's Claude docs say the server is hosted, that Safeguard publishes no npm package or local bridge for it, and that you should therefore treat any package claiming to be the Safeguard MCP server as untrusted. That is step 3 of the checklist answered by the publisher, and it gives you a clean rule for your developers: there is nothing to install.

Sign in. OAuth 2.0. When you add the connector, Claude sends you to Safeguard, where you sign in, check the app name and the host the page says the authorization code will be sent to, and click Authorize access. No keys are copied.

Tools exposed by default. Safeguard's tool gating docs say a new workspace starts with a small default set of read only tools, such as listing products and projects, listing vulnerabilities and findings, and getting the details of one CVE. Every other tool, including ones that add an integration or start a scan, ships disabled and is enabled per tenant by an administrator under Feature Flags, where each tool has a flag of the form mcp:tool:TOOL_NAME. If an assistant calls a tool that is not enabled, the server returns a normal tool result with an error flag that names the tool and says an administrator can enable it. Any default tool can also be switched off.

That is step 7 and step 8 of the checklist with the publisher's documentation behind them: a hosted server, OAuth with a visible consent step, and least privilege by default.

Step by step: add Safeguard from Claude's connector directory

Safeguard's Claude docs describe the directory route as the shortest one, with no URL to paste.

1. Sign in to claude.ai. The directory lives inside Claude. Opened without a Claude session, the directory link lands on the Claude home page instead.
2. Open the Safeguard entry in Claude's connector directory. You can follow the Add in Claude button on gold.safeguard.sh/mcp, or the link in Safeguard's Claude docs.
3. Select Safeguard and click Connect.
4. Sign in to Safeguard (or create an account at app.safeguard.sh) when Claude sends you there.
5. Check the consent page. Confirm the app name and the host the authorization code will be sent to before you continue. This is the same scope review you would do for any third-party server.
6. Click Authorize access. The connector appears in Claude as Safeguard Security.
7. Choose which tools Claude can use. Start with the read only defaults. In Claude, switch off any tool you do not need for the conversation, and keep approval prompts on. Ask your Safeguard administrator to enable further tools under Feature Flags only when a use case needs them.

Safeguard's docs add two notes. If the directory is not available on your Claude plan or in your workspace, the docs give manual steps that always work. And Claude Desktop uses the connectors in your Claude account, so once Safeguard is added it is available in Claude Desktop too; do not add it to claude_desktop_config.json, which is for local servers only.

What about ChatGPT and other assistants

Safeguard's offering lists ChatGPT, Cursor and other assistants among the clients that can use the Safeguard MCP server, and Safeguard's docs have a page for each. We are not aware of a ChatGPT directory listing for Safeguard and do not claim one here. Our post on Safeguard in your IDE and in the Claude and ChatGPT connector directories covers the other clients, sign in options and the admin review in depth, so this post does not repeat it.

Decision table: what you find on the page, and what to do

Requirement vs what Gold shows vs what you still own

Where Gold fits alongside the rest of Safeguard

Gold Open Source is the free, no login front door. It answers "who published this and how does it run" for public servers. The rest of Safeguard covers the parts that need your tenant:

• Safeguard MCP Guardrail (GA) puts a policy proxy between your agents and the servers they call, including servers you do not own, and records each allow, deny or monitor decision. See the MCP Guardrail walkthrough.
• Agent identity (GA) tracks which agent holds what access, which matters once more than one agent is calling the same servers.
• In-app Connectors (GA) let Safeguard's own in-app assistant attach external MCP servers as live tools with OAuth, API key or basic auth, with permissions set per tool. The same vetting applies to any server you attach there.
• SCA (GA) and policies and gates (GA) track the packages behind installable servers once they are in your manifests, and can block builds that pull in versions you have ruled out.
• The free Gold Open Source API, badges and feeds let you script lookups. Our post on using Gold Open Source in your workflow covers them.

For broader MCP vetting checklists that do not depend on any product, see how to vet an MCP server before installing and the risks of unvetted servers in MCP registries.

What Safeguard does not do

• Gold Open Source does not list an MCP server's tools, scopes or permissions. As fetched on 25 October 2026, the MCP detail pages show identity, version, distribution, transport, repository and a licensing note. Tool and scope review is yours.
• Gold Open Source does not give MCP servers a safety score or verdict. A listing on gold.safeguard.sh/mcp means the server is in the official MCP Registry. It is not an endorsement by Safeguard, and it is not a statement that the server has been reviewed.
• Gold does not show licenses for MCP servers. The registry does not publish them, and Gold's pages say so and point you to the repository or the publisher.
• Gold does not cover private or internal servers. The official registry lists public servers only, so a server your company runs internally, or one a vendor gives you privately, will not appear. Vet those from source and with the operator.
• Gold does not run or test the server. It reads registry metadata. It does not connect to hosted endpoints, install packages or call tools.
• Gold does not prove a package was built from the linked repository. A repository link is what the publisher registered. Matching a published package to its source is a separate check.
• Safeguard does not control what a third-party server does. Once connected, a server acts with the credential you gave it. MCP Guardrail governs only the traffic routed through its proxy; local stdio servers and direct connections that skip the proxy are outside it.
• Safeguard does not configure your assistant for you. Which tools are switched on in Claude, and whether users can click "Allow always", are settings in Claude and in your Claude organisation, not in Safeguard.

Common mistakes

Trusting the title instead of the namespace. Display titles are free text. Two servers can share a title. The registry name, and specifically its namespace, is the part the registry verified.

Reading a registry listing as a security review. The official registry says it delegates security scanning and that consumers should assume minimal to no moderation. A listing proves who published, nothing more.

Treating hosted and installable servers the same. A hosted endpoint is a data sharing decision. An installable stdio server is a code execution decision on your own machines. They need different questions.

Skipping the license because the server is "just a tool". MCP servers set their own licenses and the registry does not publish them. If you deploy commercially, read the LICENSE or get terms from the publisher, as the Gold page itself says.

Approving once and never again. Servers can change their tool list and behaviour between versions. Record the version you approved and re-check when the Gold page shows a new one.

Installing a package that claims to be a hosted vendor's server. Safeguard's own docs warn that it publishes no npm package or local bridge for its MCP server. Ask the same question of any vendor: do you publish a package at all?

FAQ

How do I check if an MCP server is safe before connecting it?

Start with identity and distribution: look the server up on gold.safeguard.sh/mcp, confirm the namespace belongs to the publisher you expect, and note whether it is a hosted endpoint or an installable package. Then do what no directory can: list its tools in a sandbox, read the OAuth consent screen, connect with the least access you can, and keep approval prompts on. "Safe" is your decision after that review, not a label on a page.

What does the MCP Registry actually verify?

Namespace ownership. Publishers prove control of a GitHub account or organisation (names start with io.github.) or of a domain (names use the reverse DNS form of the domain) before they can publish under it. The registry's docs say security scanning is left to package registries and downstream aggregators, and its moderation policy says consumers should assume minimal moderation.

Is Gold Open Source's MCP directory free?

Yes. Gold Open Source is free and needs no login. The MCP Servers directory, its search and every detail page are open.

Does Gold Open Source show which tools an MCP server exposes?

No. As fetched on 25 October 2026, the detail pages show the registry name, version, description, hosted or package distribution, package registry and transport, a repository link where listed, and a licensing note. To see tools, connect the server to a test client and list them.

What is the difference between a hosted remote endpoint and an installable package?

A hosted remote endpoint is a URL someone else operates; your client sends requests to it over the network. An installable package is code your client downloads, from npm or PyPI for example, and runs locally, often over the stdio transport. Gold shows which one each server is.

How do I add Safeguard to Claude from the connector directory?

Sign in to claude.ai, open the Safeguard entry in Claude's connector directory (the "Add in Claude" button on gold.safeguard.sh/mcp links there), click Connect, sign in to Safeguard, check the app name and the host the authorization code goes to, and click Authorize access. The connector appears as Safeguard Security, with a small read only tool set on by default.

Is there an npm package for the Safeguard MCP server?

No. Safeguard's docs say the server is hosted and Safeguard publishes no npm package or local bridge for it, so any package claiming to be the Safeguard MCP server should be treated as untrusted.

Is Safeguard an Anthropic partner because it is in the Claude directory?

No. Safeguard is listed in Claude's connector directory as a community connector. That is a directory listing, not a partnership.

Why is an MCP server I use not listed on Gold Open Source?

The official MCP Registry lists public servers only and does not support private servers. Internal servers, privately distributed servers and servers that were never published to the official registry will not appear. Vet those directly from their source and operator.

Keep the packages behind your agents patched

Vetting a connector is a decision at the door; the packages behind installable servers, and the rest of your stack, keep collecting advisories after that. The block below is the same one we run on every post: how Safeguard closes the gap between a vulnerability and a fix, including the free Gold Open Source lookup used in step 6 above.

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 shows the exact connector flow from this post: connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. Watch the consent step and the tool choices, because those are the two places step 8 and step 9 of the checklist happen for any connector.

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

The second demo is a real Safeguard CLI session. You ask it to fix the lodash CVE in a repository; it 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 is the same pattern this post recommends for agents and connectors: read freely, ask before changing anything.

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

The third demo is a real Android session with the Safeguard mobile app: work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. If your connector policy says a human approves actions, this is one way to keep that human in the loop away from the desk.

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

To try Safeguard yourself, start at safeguard.sh/download, and read the setup guides at docs.safeguard.sh.

Quick check

Sources

• Gold Open Source: MCP Servers directory
• Gold Open Source: example MCP server detail page, hosted endpoint
• Gold Open Source: example MCP server detail page, installable package
• Gold Open Source: example MCP server detail page with repository
• Gold Open Source: Credits and data sources
• Safeguard docs: Connect Safeguard to Claude
• Safeguard docs: MCP tool gating
• Safeguard docs: MCP integrations overview
• Safeguard docs: ChatGPT (OpenAI)
• The MCP Registry: About
• The MCP Registry: Authentication
• The MCP Registry: Moderation policy
• The MCP Registry: live API
• MCP specification 2025-11-25: Security Best Practices
• MCP specification 2025-11-25: Tools
• MCP specification 2025-11-25: Authorization
• Claude Help Center: Getting started with custom connectors using remote MCP
• Claude Docs: Remote MCP servers
• OWASP GenAI Security Project: LLM06:2025 Excessive Agency
• OWASP GenAI Security Project: LLM03:2025 Supply Chain
• NIST SP 800-218, Secure Software Development Framework v1.1

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